说白了兼容简单, 但是性能保证即便用AI也需要时间。最近 Bun 那边动静挺大——底层从 Zig 换成 Rust而且这事儿 AI 还帮了不少忙。看到这个新闻脑子里第一个冒出来的想法就是“既然 AI 都能写代码了让它把 Node.js 的 API 全抄过来不就行了现在 Node 兼容性不是还有 10% 没搞定吗AI 搞定它不是分分钟”乍一听好像挺有道理的对吧。但你仔细想想就会发现这剩下的 10%反而是最难啃的硬骨头。那些至今没兼容的 Node.js API咱先摆事实。Bun 官方文档加上社区反馈下面这些 API 现在还都没法完全跑通或者行为上对不上模块 / API现在啥情况卡在哪儿http 客户端请求体只支持整块塞进去不支持流式发送流式背压那套逻辑是 V8 libuv 攒出来的JSC 那边机制不一样https 的 Agent 配置部分选项跑出来效果对不上Agent 复用 Socket 的逻辑跟 Bun 的异步 I/O 调度打架perf_hooksAPI 有但没过 Node 官方测试性能计时那套语义深度绑在引擎实现上V8 跟 JSC 路子不同async_hookscreateHook 这些核心 API 还没实现调用会警告想完全模拟 V8 的异步追踪就得大改引擎性能也扛不住module.register没实现Bun 推自己的 Bun.plugin这个优先级低原生模块Native Addons像 bcrypt、canvas 这类基本跑不起来这些模块是按 V8 的二进制编出来的JSC 用不了repl整个模块没动Bun 自己的 REPL 更强没必要抄顺手聊一下 REPL 是啥上表里的 repl 可能有人不太熟。简单讲REPL 就是读一句、跑一句那种交互式命令行——你打开终端输 node看到个提示符那就是 REPL 了。Node.js 不仅自己带命令行 REPL还暴露了一个 repl 核心模块让你能在代码里自己起一个。下面这种用法就是例子// 创建一个自定义 REPL并注入一个变量constreplrequire(repl);constrrepl.start(my-app );r.context.greetingHello from Bun!;// 运行后在 REPL 里可以直接使用 greeting 变量// my-app greeting// Hello from Bun!这个模块能改历史记录、加自动补全、定制输出格式什么的。一些框架比如 NestJS 那个交互式脚手架会拿它来在运行时临时开个调试口。那 Bun 咋就不实现它呢其实原因挺直接的。Bun 自己就有个更猛的 REPL直接输 bun 就进原生支持 TypeScript、JSX、Top-level await连 npm 包都能自动补全。再说 Node 那个 repl 模块内部挺复杂牵涉一堆终端控制和事件循环适配搬到 JSC 上重写不划算。况且真正常用 REPL 的人基本就是开个终端敲一敲几乎没人会在自己代码里 new 一个 REPL 实例出来。所以这事儿不是做不到是不值得做。AI 倒是能帮你把 repl 模块的源码翻译成 Rust但它不会替你做这个判断——Bun 团队心里清楚得很自己有个更好的方案这功能优先级就排到后面去了。这种取舍AI 替不了。AI 到底搞不定啥你可能会想“那既然有差异就想办法兼容呗AI 写代码这么猛差哪儿补哪儿不就行了”这话听着挺对但问题在于AI 能翻译代码没法适配行为。下面拿两个具体例子说说。例子一流式请求里的背压Node.js 的 http 客户端发大文件的时候常这么写fs.createReadStream().pipe(request)。底下走的是 V8 libuv 的背压机制——TCP 缓冲区满了就自动暂停读缓冲区空出来再发drain事件接着读。想在 JSC 上把这一套原样复刻得做这些事自己模拟 libuv 的写缓冲区水位线判断让 JSC 的异步 I/O 跟 JS 层的drain事件触发时机对上处理stream.write()返回 false 之后的等待逻辑。那 AI 能干啥它确实能把 Node.js 的_write实现翻译成 Rust 代码。但翻译完跑起来背压行为跟 V8 是不是一模一样AI 验证不了啊——它不知道 JSC 的事件循环啥时候处理 I/O 回调也不知道微任务队列、定时器精度的差异会怎么影响流控。Bun 现在的选择就是先不搞流式发送干脆把整个请求体缓冲起来。这是个工程上的取舍——真去模拟流式成本高得离谱还会拖累平时那些小请求。这种值不值得的事儿AI 拍不了板。例子二async_hooks 的异步追踪Node.js 的 async_hooks 能追踪每个异步资源从创建到销毁的全过程做类似 CLS连续本地存储那种东西就靠它。这套 API 完全是挂在 V8 内部对 Promise、setTimeout、nextTick 的钩子机制上的。要在 JSC 上弄出一样的语义来得在 JSC 的每个异步操作入口和出口都插回调异步 ID 的生成规则、传播路径得跟 V8 严丝合缝还得控制住性能开销Node 自己开了这个都会明显变慢。AI 能给你写一个看起来能跑的createHook但 ID 传播顺序在复杂场景下比如好几个 Promise 链套着 setImmediate跟 Node 一不一样它保证不了它也不知道 JSC 对 Promise 的优化策略微任务调度那些跟 V8 有啥差别钩子触发时机容易错位。Bun 一直拖着没实现 async_hooks.createHook不是写不出来——是写一个行为对得上、性能扛得住的版本AI 还真搞不定。这得靠真正懂两个引擎内部实现的工程师一行一行去抠。那 AI 到底干了啥话说回来AI 也没那么废。在 Bun 的开发里AI 确实有出力它能根据 Node 的行为描述批量生成边界测试用例让工程师拿来跟 Bun 的实现对比也能把 Node 的 TypeScript 类型定义转成 Bun 那边的格式像 Buffer 里面某些无状态的方法AI 写起来挺快。但 “哪些 API 值得兼容”、“性能跟正确性怎么取舍”、“引擎层的差异咋修”——这些事儿还是得人来定。总结一下要是 Node.js 和 Bun 跑在同一个引擎上AI 几乎能把所有 API 一键迁过来。但现实不是这样啊——它俩跑在两套虚拟机上设计哲学、内部机制全都不一样。把 V8 的 API 硬搬到 JSC 上那不叫翻译叫重新设计。重新设计这事儿得先搞明白两边的差异再做取舍最后还得反复验证——偏偏这些是 AI 最不擅长的。所以要是你问AI 是不是早晚都能搞定——要是搞定是说写一个看起来能跑的版本AI 已经能了。要是搞定是说行为完全对得上、性能不缩水、长期能维护AI 还差得远。这也是 Bun 那 10% 没兼容的 API 一直存在的原因。好消息是对绝大多数人来说Bun 已经够用了通过率超 90%Express、Fastify 这些框架无缝跑。剩下那 10% 的硬骨头还是得工程师们一块一块啃——AI 是帮手不是替身。