这新闻出来挺有意思，很多老哥觉得是情怀回顾，其实细看很有嚼头。在Node.js生态里摸爬滚打这些年，我更倾向把它看作现代开源协作的契约重构。DOS那套模块化设计和清晰的I/O接口，意外成了早期API契约的原始范本。现在大家总被各种闭源驱动和黑盒SDK折腾，其实当年那些透明的中断调用机制早就点明了关键：可验证的契约才是生态健康的底座。这就像debug，边界定义得越干净，排查成本越低。开源从来不是简单把代码推上repo，文档是契约，测试是公证，历史沉淀就是共识。我们在npm里装依赖，本质上也是在签一份责任共担的协议工程。微软把底层逻辑摊开，反而能倒逼现在的开源项目把隐式约定显式化。平时维护核心模块，大家习惯怎么约束上下游的调用边界？

嗯嗯，看到你提到“中断调用机制是可验证契约的原始范本”，我立刻想起去年在伦敦帮一家 fintech 做 legacy 系统迁移时踩的坑——他们还在用一段 2003 年的汇编 glue code 调 DOS 设备驱动，结果发现那几行 int 0x13 的注释里写着：“此处必须保证 DL=drive number, AH=0x02, 否则 BIOS 不认；返回值 CF=1 即失败，AX=0x0000 是唯一成功态”。
加油呀
当时我们团队笑称：这比 TypeScript 的 interface 还 strict，而且 runtime 验证零延迟 😅
嗯嗯
你说得特别准：契约不在文档里，而在调用瞬间的确定性。Node.js 生态里很多“约定俗成”的行为（比如 stream.pause() 是否自动 flush、transform 的 _flush 回调是否允许 async）恰恰缺了这种原子级契约。npm install 本质确实是签协议，但问题是——我们连协议正文都常靠 guesswork 补全（比如翻 17 个 GitHub issue 才拼出一个 callback 的 error 传递逻辑）。

补充一个小观察：DOS 的契约之所以“可验证”，是因为它天然受限于硬件边界（寄存器宽度、中断向量表长度、实模式内存分段），而现代 JS 模块的边界却常被动态 require、monkey patch、甚至 webpack definePlugin 悄悄抹平。微软开源 DOS，未必是怀旧，更像是把一块“契约硬度标尺”放回桌面——提醒我们：当抽象层越来越厚，真正的韧性反而来自底层那些不容协商的接口语义。

对了，你提“测试是公证”，让我想起 LSE 教授讲过的一个比喻：单元测试不是保险单，是法庭笔录。每次 assert.equal() 都是在记录“此刻双方对契约的理解一致”。
抱抱
你们团队现在用什么方式显式约束模块边界？比如 JSDoc @throws 注解 + 自动校验？还是更激进地用 Deno 的权限模型倒逼接口收敛？
（悄悄说：我上周刚给公司内部 CLI 工具加了 --dry-run + schema validation，结果发现 30% 的插件根本没处理 undefined 输入…）