Zig 架构进化:包管理功能从编译器迁移到构建系统

Zig 语言将所有包管理功能从编译器可执行文件移出,转移到构建系统(maker 进程)中。这一架构变更使二进制缩小 4%、增强了可修补性和安全性,并为构建服务器协议铺平了道路。
2026 年 6 月 30 日,Zig 创建者 Andrew Kelley 宣布了一项架构变更:将所有包管理功能从编译器可执行文件中移出,转移到构建系统(maker 进程)中。这是一个几乎无破坏性的变更,但对开发体验和性能都有显著提升。
迁移了什么
以下子命令从编译器移到了 maker 进程:zig build、zig fetch、zig init、zig libc。
同时,原本内置于编译器二进制文件中的功能改为以源码形式随构建系统分发:包获取逻辑、HTTP 客户端、TLS 及加密功能、Git 协议、xz/gzip/zstd/flate/zip 压缩支持、build.zig.zon 文件解析。
进程树的演变
变更前:
zig build (编译器 + 包管理器)
├─ configurer (用户的 build.zig 逻辑)
└─ maker (构建系统)
变更后:
zig build (仅编译器)
└─ maker (构建系统 + 包管理器)
└─ configurer (用户的 build.zig 逻辑)

图1:Zig 构建系统进程树迁移——maker 从兄弟变父进程
关键变化:maker 从 configurer 的兄弟进程变成了父进程。这意味着配置需要重新运行时,maker 进程可以继续存活,无需退出——这在 zig build --watch 场景下至关重要。
为什么迁移
三个主要原因驱动了这次架构调整:
- 构建服务器协议(Build Server Protocol):为了解除 ZLS 的阻塞,需要暴露构建服务器协议。旧架构下
--build-runner覆盖标志的破坏性变更导致了问题。 zig build --watch的问题:旧架构下,检测到build.zig变更时 maker 必须退出以便重新执行包管理逻辑。新架构避免了这一尴尬情况。- 架构合理性:既然已经有了独立的 maker 和 configurer 进程分离,包管理逻辑放在构建系统中更为自然。
对开发者的好处
- 可修补性增强:包管理功能以源码形式分发,无需重新编译编译器即可打补丁
- 安全性提升:maker 以
ReleaseSafe模式编译,网络操作时启用安全检查 - 性能优化:加密功能可利用宿主机的特殊 CPU 指令,包括通常不会依赖的罕见指令
- 二进制缩小:从 14.1 MiB 缩减至 13.5 MiB(缩减约 4%)
- 长时间运行构建更稳定:
--watch模式下配置变更不再需要 maker 重启
Zig 0.17.0 的发布阻塞项包括构建服务器协议 MVP、构建脚本自身路径依赖、--watch 检测构建脚本修改等。作者预计 8 月初完成,同时欢迎社区贡献。
关联推荐
- crustc:将 Rust 编译器整体翻译为 4600 万行 C 代码 — 另一种编译器架构探索
- GitHub Actions 全面拥抱 AI Agent — 构建/CI 系统的 AI 化
- Short Leash:一个资深开发者的 AI 编程方法论 — 编程方法论思考
评论 (0)
加载评论中…