回归 Zig 四个月：我喜欢什么、还不喜欢什么

编者按：以下据 Anna Liberty（gracefulliberty.com）2026年10月27日署名文章《Four Months of Zig》编译整理，保留第一人称与原文结构；对比 Rust 的评价、项目进度与社区经历均为作者自述，不另加编辑结论。

差不多四个月前，我在离开几年之后又回到了 Zig。这段时间里，我用 Zig 写了一些软件，也重新 offline、线上参与社区。我想分享这段经历：目前喜欢 Zig 的地方，以及还不喜欢的地方。途中会对照 Rust——那是我之前的主力语言。

项目

我在 Zig 里开的第一个项目是 snurl：面向 smallnet（Gemini、Finger、Gopher、Spartan 等）的交互库。目标是给 smallnet 做一个类似 curl 的替代，测试与模糊测试要求类似，但规模更小。我尽量在合适范围内遵循 TigerStyle。

很早就撞上：模糊测试其实还不能用。上一篇帖子里我对 fuzzing 很兴奋，却没意识到功能尚未完成。以 Zig 目前状态，这不奇怪，但还是失望——尤其 zig init 生成的 main.zig 里还演示了 fuzzer。

之后我又写了两个尚未发布的小程序：一个最小可用的 TUI 打字竞速；一个用 raylib 的 n-body 模拟，带恒星演化。

Zig Day

这几个月最兴奋的，是参加本地 Zig Day。我在 Lobsters 上看到 8 月 20 日西雅图 Zig Day，得知本地有活动就很开心；看到 Andrew Kelley 也会到场，更兴奋。

Zig Day 是本地聚会：对 Zig 感兴趣的人一起写项目、聊天。我打算继续做 snurl，朋友 Evin Yulo 也来了。因报名太多，活动从 Bellevue 图书馆改到 Bothell 图书馆——语言作者现身，容量很容易爆。

我喜欢这种由本地组织办会的形式，社区更互联。当天和别人聊各自项目，也和 evin 一起在 snurl 上推进：他开始把 Zig 标准库 TLS 做成可选后端。我还和 Andrew Kelley 简短聊过。希望内置 fuzzing 尽快修好。Ryan Hendrickson 另有一篇更详细的当日记录。以后西雅图的 Zig Day 我还会去，也许会先去波特兰赶一场。

我喜欢的部分

anyzig

我喜欢 anyzig。不同项目要在 zig master 与 0.16.0 之间切换，它让这事可行。缺点是：没有 build.zig.zon 的目录会出问题，依赖 zig 命令的工具只能在项目目录里跑，我的一次性脚本自动格式化会因此挂掉。或许可以给那种情况一个默认 Zig 版本。

IO 与分配器

我知道有人烦，但我喜欢 Zig 必须把 IO 和 allocator 显式传进函数。

分配器方面：和多数语言默认全局分配、或像 Odin 用隐式 context 不同，Zig 让你为不同代码段换 arena、通用分配器或 FixedBufferAllocator。是否分配、传错分配器都更难糊弄。相对 Rust 里隐蔽、耗尽就 panic 的分配，也更好推理；Rust 在补显式分配，但那是后来叠上去的特性，不是从根上长出来的。

IO 参数更新，却更强。几乎凡是碰操作系统的函数都要带 IO（有例外）。移植到新系统，很大程度上就是移植 IO。测试时塞进测试用 IO，就能改输入流、让写入失败等。和分配一样，一眼能看出程序是否有副作用。Zig 常走「一个大特性覆盖多种用例」，而不是堆一百个小功能。

Comptime、构建系统与依赖文化

我喜欢 comptime：元编程与预计算合在一处。构建系统也很强——Uber 等公司甚至拿它构建非 Zig 软件。我能把代码生成一类工具无缝嵌进构建，Cargo 对这类事更容易抱怨。

依赖文化也好：主基调是能不加就不加；要加时，常用 translate-c 接成熟库，或 vendor 后审计。我多数 Zig 程序大约一两个直接依赖、零间接依赖。Rust 里再小的项目也常有几个直接依赖加几十个间接依赖。反射、随机数、错误处理、JSON 等在 Zig 语言或标准库里更齐，不必处处依赖 serde、syn。

错误处理与增量编译

Zig 默认推你正确处理错误：最懒的写法是 try，并在返回类型加 !。相对之下，Rust 更容易在原型阶段塞 panic，再一直留到生产。? 虽快，但 Result<Type, Box<dyn Error>> 很长；anyhow 又要加依赖。

Zig 核心团队在增量编译上做得很好。zig build --watch -fincremental 会监视改动，只改需要改的部分到链接。工作流上我可以一边存盘一边看反馈。Rust 小项目增量编译十秒以上也不稀奇，刚好够分心又不够干别的事。Zig 愿意为大改进接受破坏性变更；Rust 要守兼容，空间更小。目前增量编译仅支持 x86_64 的 Linux 与 macOS。

还不喜欢 / 还想要的

和多数用户一样，我希望标准库更稳。我知道那是 1.0 前靠后的任务，但生态不断被破坏很烦；我理解这是 0.17.0 拖了很久的原因之一。Andrew Kelley 在 Zig Day 说他比谁都想看到 1.0，我信，所以我耐心等。这是我部分项目仍用 Rust 的原因：有些场景需要稳定语言与生态。但稳定性不是一切，很多场景 Zig 的好处压过不稳定。

我还希望编译器在生命周期上多帮一点：例如在 debug 模式让返回局部变量失败（内置 lint，或函数返回后使该内存在语义上失效），好让新手快速避开。相关地，编译器目前仍接受将来会失效的写法——变量寿命按整个作用域而不是块，栈上缓冲从块里返回切片今天能跑、将来可能静默坏掉。

文档偏少：够起步，往后常要靠稀疏 doc comment 猜意图，示例也少。我和朋友到现在也没把标准库 TLS 在 snurl 里配通，缓冲区该怎么设搞不清。知识散落在网上；融入社区的人能成，没那么融入就难。好处是逼人进社区（我还是 Matrix 房间管理员），但完全可以既有社区又有像样文档。

我也想在 comptime 解析 JSON：有个项目把静态 JSON 打进二进制，本可编译期变成结构体集合，但标准库 JSON 解析器要 allocator，而 comptime 没有可用分配器，只好运行时解析。据说会有不依赖分配器的 JSON 解析；更一般的场景以前 FixedBufferAllocator 能在 comptime 用过，也许可以再回来。

引导构建方面：用 WASM blob + 解释器替代 C++ 编译器很有意思，但源码树里仍有编译好的二进制 blob，恶意注入理论上仍可能；Debian 等发行版也因此难合规打包。我曾因 Debian 装不了 Zig，给某个项目改选别的语言。完全从源码引导目前还做不到；稳定之后另写一个实现会更容易，但赶 1.0 之前核心团队不愿管这个追逐游戏。

接下来

我会继续用 Zig。方向让我兴奋，也想继续待在社区里。到目前为止，没有别的语言我更偏爱——即便有缺点。它刚好稳到发布之间不必大改，仍会是我多数项目的首选。其中一个是 ReTangled：以前用 Rust，我受够了巨大依赖树，想吃透 Zig 构建系统。

我也想更多直接给 Zig 做贡献。学生时间有限、贡献者已经很多、文档又差，会很难，但我想回馈、产生影响、成为更好的工程师。幸好改进贡献者上手似乎是 Andrew Kelley 接下来的重点之一。

西雅图之后的 Zig Day 我也会在，如果你想来一起写 Zig，欢迎碰面。

说明：正文为当事人署名文章的中文编译，保留第一人称与原结构；技术判断、项目状态与社区经历均为作者自述，不以本稿作语言选型建议。联系方式见原文，此处不转载。

来源

原作者：Anna Liberty
原文标题：Four Months of Zig
发布平台：gracefulliberty.com / Articles
发布日期：2026年10月27日
原文链接：https://gracefulliberty.com/articles/four-months-of-zig/
查询日：2026-10-28

#Zig #经验分享 #Rust对比 #编程语言 #AnnaLiberty