Zig 新 ELF 链接器进主线：部分真实项目已能试毫秒级增量重建

Zig 主分支的新 ELF 链接器，这次跨过的不是一个漂亮指标，而是一个更实际的门槛。

5 月 30 日，Zig 开发者 Matthew Lugg 在官方 devlog 中提到：最新 PR 合入后，这个在 Zig 0.16.0 首次亮相、但仍默认关闭的 ELF 链接器，已经能构建启用 LLVM 和 LLD 库的自举 Zig 编译器。

这个细节很关键。

早期的新链接器，更像是给 Zig-only 代码准备的试验场。现在它能碰外部库、C 源码、LLVM/LLD 这种更重的依赖，说明它开始接近真实工程，而不是只跑示例项目。

我更在意的是它对增量编译体验的影响。对跟主分支的 Zig 开发者来说，这已经不是“看个热闹”的功能；在 x86_64 Linux 上，部分项目可以实际打开试一试。

但边界也要说清。它没有默认启用，也不能把 x86_64 Linux 的进展外推到所有平台。更不能说所有 Zig 项目都能毫秒级重建。

它跨过的门槛：从 Zig-only 到真实依赖

Zig 0.16.0 里，新 ELF 链接器已经出现，但位置很保守：默认关闭，需要 -fnew-linker 才能启用。

原因也不难理解。一个链接器能跑通简单代码，和能服务真实项目，是两回事。真实项目会拉外部库，会混 C 源码，会碰 libc，也可能依赖 LLVM 这种大型组件。

这次最新 PR 后，变化在这里：新链接器已经能构建启用 LLVM/LLD 的自举 Zig 编译器，并且在 x86_64 Linux 上，支持含外部库、C 源码等场景的快速增量重建。

可以把前后状态压成一张表：

这张表里最重要的不是“能不能快”。

最重要的是能力边界变了。系统语言项目很少永远待在纯语言小岛上。只要一进入实际工程，链接外部库和 C 代码就是常态。

所以我的判断是：新 ELF 链接器已经从早期实验品，进入部分真实项目可试用阶段。但它还没拿到“放心替换默认链接路径”的资格。

毫秒级重建，改变的是开发者的动作

Devlog 里给了两个数字。

Andrew Kelley 的 Tetris 克隆项目，小改动后的单次重建约 30ms。Zig 编译器自身在 --watch 增量模式下，首次构建约 36 秒，后续增量重建约 228–288ms。

这两个数字要小心读。

它们不等于“所有 Zig 项目都会 30ms 重建”。更准确地说，在 x86_64 Linux、主分支、启用新 ELF 链接器和增量模式，并且项目形态合适时，一批代码库可能把重建等待压到几十到几百毫秒。

对开发者来说，这不是跑分游戏，而是动作会变。

如果一次改动后要等数秒，人会自然攒一批改动再编译。反馈慢，调试节奏就会断。等到反馈缩到几十或几百毫秒，写代码、看报错、加打印、再改一行，才更接近交互式循环。

最相关的两类人可以这样处理：

• 跟 Zig 主分支的个人开发者，可以在 x86_64 Linux 上用 -fnew-linker 配合 -fincremental --watch 试自己的项目，重点看小改动后的重建时间和链接错误。
• 正在评估 Zig 工具链的团队，不适合因为这条进展就迁移生产构建；更合理的动作是把它列入 0.17.0 前后的验证项，拿内部项目跑一轮兼容性和调试流程。

这里还有一个路线差异。

C++、Rust 等系统语言生态里，大家常用 lld、mold、sccache 或各自的增量编译能力去减少等待。Zig 的思路更偏“把构建、编译、链接体验收进自家工具链”。路线更重，收益也更集中：如果打通，开发者少配一层东西，体验会更一致。

但这也意味着问题会更集中地暴露在 Zig 自己身上。链接器不是边缘模块，它一旦出错，影响的是构建链路的末端。

现在能试，但别把它当稳定答案

现在最该保守看的，是 DWARF。

新 ELF 链接器目前还不能为 Zig 代码生成 DWARF 调试信息。对依赖打印调试的人，快速重建已经能带来收益；但对需要断点、栈回溯、变量查看的调试流程，这个缺口很快会变成硬限制。

这也是我不建议把它包装成“可全面替换”的原因。

一个工具链功能能不能日常使用，不只看它能不能构建成功，还要看失败时能不能定位问题。编译快当然重要，但调试信息缺失，会把一部分节省下来的时间又拿回去。

接下来要看三个变量，条件很明确：

回到开头那个事实：能构建启用 LLVM/LLD 的自举 Zig 编译器，确实不是小进展。

它说明 Zig 新 ELF 链接器已经开始碰真实工程的硬骨头。只是工具链这件事，向来不是“能跑一次”就算过关。

现在的结论可以更短一点：主分支用户可以试，生产构建要等；想要毫秒级体验，可以动手测，但不要跳过调试和平台边界。