1. 从 Rust 转到 Zig 的第一感受为什么会有“换了一种思维方式”的错觉我写 Rust 差不多有四年从最早的rustup装工具链、被借用检查器按在地上摩擦到后来能比较顺手地用sqlx配 MySQL 连接池写后端服务再到用 Tauri 做桌面端、用gpui试水 Windows 上的原生 UI这一路踩的坑不算少。Rust 给我的感觉一直很明确它像一位极其严谨的搭档你写的每一行代码它都要反复确认“你真的想清楚了吗”。这种体验在写大型项目时是安全感但在写小工具、做原型、调硬件的时候有时候会变成一种负担。后来因为一个嵌入式的小项目我开始接触 Zig。标题里说的“What Zig felt like, coming from Rust”其实特别贴切——它不是简单的“换一门语言”而是换了一整套看待内存、编译、错误处理和工程组织的方式。我最初以为 Zig 只是“更简单的 C”但真正写下来才发现它和 Rust 的差异不在语法糖多少而在于两者对“程序员应该被怎样对待”这个问题的回答完全不同。这篇文章我想把这段迁移体验拆开讲清楚。如果你正在学 Rust或者已经用 Rust 写过async、用过sqlx连接池、折腾过ch32这类芯片的 Rust 开发同时对 Zig 有点好奇那这篇内容应该能帮你少走一些弯路。我会从设计思路、核心机制、实操对比、常见问题几个角度展开尽量把“为什么 Zig 让我有这种感觉”说明白而不是停留在“Zig 语法更少”这种表面结论上。先说结论性的感受Rust 把大量复杂度前移到了编译期用类型系统和所有权规则帮你消灭一整类 bugZig 则把复杂度后移到你对程序行为的理解上它给你更直接的掌控权但要求你自己清楚每一步在做什么。两者没有绝对优劣但切换时的那种“失重感”和“解放感”是真实存在的。2. 设计哲学差异Rust 的“安全优先”与 Zig 的“显式优先”2.1 Rust 的核心承诺编译期消灭内存安全问题Rust 最核心的卖点就是所有权、借用和生命周期。你写let s String::from(hello);之后把s传给一个函数编译器会告诉你“这个值被移动了后面不能再用”。这套机制在编译期就杜绝了悬垂指针、双重释放、数据竞争等一大类问题。配合ResultT, E和OptionT错误处理也被强制显式化你不能像 C 那样忽略返回值。这套设计的代价是学习曲线陡峭。我当初学 Rust 的时候光是理解“可变借用和不可变借用不能同时存在”就花了好几天。后来写async代码又遇到Send、Sync、Pin这些概念尤其是用tokio写异步服务时生命周期标注经常让人头大。但一旦跨过这个门槛你会发现自己对内存和并发的理解上了一个台阶。Rust 的另一个特点是生态成熟。cargo作为构建工具和包管理器体验非常统一sqlx这样的库能提供编译期 SQL 检查Tauri 让 Rust 写桌面应用变得可行甚至ch32这类 RISC-V 芯片也有 Rust 的 HAL 支持。你几乎不需要自己造轮子社区已经把大部分基础设施铺好了。2.2 Zig 的核心承诺不隐藏任何控制流和内存分配Zig 的设计哲学可以用一句话概括显式优于隐式简单优于抽象。它没有宏系统没有运算符重载没有隐藏的控制流没有垃圾回收也没有 Rust 那样的所有权机制。Zig 的defer和errdefer用来管理资源释放!和?用来处理错误allocator需要你显式传递。我第一次写 Zig 的时候最不习惯的就是“没有?自动传播错误”这件事。在 Rust 里你写let file File::open(x)?;就能把错误往上抛在 Zig 里你需要写try而且函数签名必须显式声明错误集比如!void或error{OutOfMemory}!void。一开始觉得啰嗦后来发现这种显式声明让调用者一眼就能看出这个函数可能返回哪些错误反而更清晰。Zig 的另一个特点是编译期执行comptime。它把“在编译期运行代码”做成了语言的一等公民你可以用comptime做泛型、做代码生成、做配置检查。这和 Rust 的过程宏、泛型、const fn是不同路线Rust 的泛型是类型系统层面的Zig 的comptime更像是“在编译期跑一段普通的 Zig 代码”。这种设计让 Zig 的元编程更直观但也意味着你需要自己控制编译期计算的复杂度。2.3 两种哲学带来的实际体验差异从 Rust 转到 Zig最明显的体验差异有三个第一编译速度。Rust 的编译速度一直是痛点尤其是大型项目加上泛型和过程宏之后cargo build可能要等几分钟。Zig 的编译速度通常快很多因为它的编译模型更简单没有复杂的 trait 解析和单态化膨胀。我在一个小型嵌入式项目上对比过同样的功能Zig 的增量编译几乎是秒级Rust 则需要十几秒。第二错误处理的直观程度。Rust 的Result和?很优雅但错误类型往往需要Boxdyn Error或者自定义enum写起来有模板代码。Zig 的错误集是轻量的你可以直接return error.OutOfMemory;调用方用catch处理。这种直接性在写底层代码时特别舒服。第三对内存分配的控制。Rust 的Box、Vec、String默认使用全局分配器你可以通过#[global_allocator]替换但日常写代码时很少感知到分配行为。Zig 则要求你把Allocator显式传给需要分配的函数比如std.ArrayList(u8).init(allocator)。这让你时刻清楚“这里会发生分配”在嵌入式和性能敏感场景下非常有价值。注意Zig 目前还没有 1.0 版本语言和标准库仍在快速变化。如果你打算在生产项目中使用需要接受 API 可能变动的风险。Rust 在这方面稳定得多有明确的 edition 机制和稳定的标准库。3. 核心机制对比所有权、错误处理、泛型与编译期3.1 内存管理所有权 vs 显式分配器Rust 的所有权系统是它最独特的机制。每个值有且只有一个所有者所有者离开作用域时值被释放。你可以通过借用T和mut T临时访问值但借用规则由编译器严格检查。这套机制在编译期就解决了内存安全问题不需要运行时垃圾回收。Zig 没有所有权概念。它更像 C你可以自由地传递指针内存的分配和释放完全由你控制。Zig 提供了defer来确保释放操作在作用域结束时执行比如const allocator std.heap.page_allocator; const buffer try allocator.alloc(u8, 1024); defer allocator.free(buffer);这段代码里defer保证了free一定会执行即使后面发生错误返回。这种模式在 Zig 里非常常见替代了 Rust 的 RAII资源获取即初始化。区别在于Rust 的 RAII 是自动的你不需要写deferZig 的defer是显式的你需要自己记得写。从 Rust 转过来我一开始经常忘记写defer导致内存泄漏。后来养成了习惯只要看到alloc下一行就写defer free。这种显式性有好处也有坏处好处是你完全清楚资源什么时候释放坏处是你必须时刻保持警惕编译器不会帮你检查。3.2 错误处理Result 与错误集Rust 用ResultT, E表示可能失败的操作用?运算符传播错误。错误类型可以是任何实现了std::error::Error的类型。这种设计很灵活但也导致错误类型在大型项目中容易变得复杂需要thiserror或anyhow这样的库来简化。Zig 的错误处理更简单函数要么返回正常值要么返回错误。错误用error关键字定义比如error.FileNotFound。函数签名用!T表示可能返回错误的T或者用error{A, B}!T明确列出可能的错误。调用时用try传播错误或者用catch处理。const std import(std); fn readFile(path: []const u8) ![]u8 { const file try std.fs.cwd().openFile(path, .{}); defer file.close(); const content try file.readToEndAlloc(std.heap.page_allocator, 1024 * 1024); return content; }这段代码里try会在出错时直接返回错误defer保证文件关闭。和 Rust 的?加 RAII 相比逻辑上很相似但 Zig 的错误集是类型系统的一部分调用者可以明确知道可能发生哪些错误。3.3 泛型与编译期comptime 的威力与代价Rust 的泛型基于 trait 约束编译时单态化生成具体代码。这套机制很强大但也会导致编译时间膨胀和错误信息复杂。比如你写一个泛型函数编译器报错时可能会展开一大堆 trait 约束让人难以定位问题。Zig 用comptime实现泛型。你可以把类型当作值传递在编译期执行代码fn max(comptime T: type, a: T, b: T) T { return if (a b) a else b; }这个max函数在编译期接受类型参数T生成对应类型的代码。comptime还可以用来做编译期计算、代码生成、配置检查。比如你可以用comptime在编译期验证数组长度、生成查找表、甚至实现简单的 DSL。这种设计的优势是直观你写的comptime代码就是普通的 Zig 代码只是它在编译期执行。劣势是编译期计算的复杂度需要你自己控制如果写得太复杂编译时间会显著增加而且错误信息可能不如 Rust 清晰。3.4 构建系统与包管理cargo 与 build.zigRust 的cargo是公认的优秀构建工具。它统一了依赖管理、构建、测试、文档生成、发布等流程。你只需要在Cargo.toml里声明依赖cargo build就会自动下载、编译、链接。cargo还支持工作空间、特性开关、条件编译等高级功能。Zig 的构建系统是build.zig它用 Zig 代码描述构建流程。这给了你极大的灵活性你可以用comptime生成构建配置可以自定义编译步骤可以跨平台交叉编译。但代价是你需要自己写构建脚本而不是像cargo那样开箱即用。const std import(std); pub fn build(b: *std.Build) void { const target b.standardTargetOptions(.{}); const optimize b.standardOptimizeOption(.{}); const exe b.addExecutable(.{ .name myapp, .root_source_file b.path(src/main.zig), .target target, .optimize optimize, }); b.installArtifact(exe); }这是一个最简单的build.zig。你可以看到它比Cargo.toml更底层但也更灵活。Zig 的包管理还在发展中目前没有像 crates.io 那样成熟的中央仓库依赖管理主要靠build.zig.zon和 Git 仓库。提示如果你习惯了cargo的便利刚转到 Zig 时可能会觉得构建系统很原始。但如果你需要交叉编译到嵌入式平台Zig 的构建系统反而更直接因为它内置了交叉编译支持不需要额外配置工具链。4. 实操对比用 Rust 和 Zig 分别写一个简单服务4.1 场景设定读取配置、连接数据库、输出结果为了更直观地对比我设计了一个小场景读取一个配置文件连接 MySQL 数据库查询一张表输出结果。这个场景在 Rust 里可以用sqlx加连接池实现在 Zig 里则需要用标准库或第三方库手动实现。先看 Rust 版本。用sqlx的话代码大概是这样use sqlx::mysql::MySqlPoolOptions; use std::fs; #[tokio::main] async fn main() - Result(), Boxdyn std::error::Error { let config fs::read_to_string(config.toml)?; let pool MySqlPoolOptions::new() .max_connections(5) .connect(mysql://user:passlocalhost/db).await?; let rows sqlx::query(SELECT id, name FROM users) .fetch_all(pool) .await?; for row in rows { let id: i32 row.get(id); let name: String row.get(name); println!({}: {}, id, name); } Ok(()) }这段代码很简洁?传播错误sqlx处理连接池和查询tokio提供异步运行时。你不需要关心底层 socket、协议解析、连接复用sqlx都帮你做好了。再看 Zig 版本。Zig 目前没有像sqlx这样成熟的 MySQL 库你可能需要用std.net手动实现 MySQL 协议或者找社区维护的库。假设我们用一个简化的例子只读取配置文件并输出const std import(std); pub fn main() !void { var gpa std.heap.GeneralPurposeAllocator(.{}){}; defer _ gpa.deinit(); const allocator gpa.allocator(); const file try std.fs.cwd().openFile(config.toml, .{}); defer file.close(); const content try file.readToEndAlloc(allocator, 1024 * 1024); defer allocator.free(content); const stdout std.io.getStdOut().writer(); try stdout.print(Config: {s}\n, .{content}); }这段代码里你需要手动管理分配器、打开文件、读取内容、释放内存。没有异步运行时没有连接池没有 ORM。一切都需要你自己控制。4.2 编译与运行体验对比Rust 的编译流程是cargo build依赖会自动下载。第一次编译可能比较慢因为要编译所有依赖。但后续增量编译会快很多。运行cargo run就能启动程序。Zig 的编译流程是zig build依赖需要手动配置。编译速度通常很快因为 Zig 编译器本身很快而且没有复杂的泛型单态化。运行zig build run启动程序。我在实际对比中发现对于小型项目Zig 的编译速度优势明显对于大型项目Rust 的生态优势更明显因为你可以直接复用成熟的库而不需要自己造轮子。4.3 跨平台与交叉编译Rust 支持跨平台但交叉编译需要配置目标工具链。比如你要编译到ch32这样的 RISC-V 芯片需要安装对应的 target配置链接器可能还需要cargo-binutils等工具。Rust 的嵌入式生态在发展中但配置起来有一定门槛。Zig 内置了交叉编译支持。你只需要指定-Dtargetriscv32-freestandingZig 就能生成对应平台的代码不需要额外安装工具链。这让 Zig 在嵌入式和跨平台场景下非常有吸引力。我试过用 Zig 编译到 Windows、Linux、macOS 和 RISC-V过程都很顺畅。注意Zig 的交叉编译虽然方便但标准库在不同平台上的支持程度不同。比如某些平台可能没有完整的文件系统支持你需要自己实现或使用freestanding模式。5. 常见问题与排查技巧从 Rust 转到 Zig 容易踩的坑5.1 忘记 defer 导致内存泄漏这是我最常犯的错误。在 Rust 里Drop会自动释放资源你不需要手动写释放代码。在 Zig 里你必须显式defer或手动释放。如果你分配了内存但忘记释放编译器不会报错程序会慢慢泄漏。排查方法养成习惯每次写alloc就立刻写defer free。如果分配和释放不在同一个作用域考虑用errdefer处理错误路径。Zig 的GeneralPurposeAllocator在deinit时会报告泄漏可以帮助你定位问题。5.2 错误集不匹配Zig 的函数签名会声明错误集。如果你在一个函数里调用了可能返回error.FileNotFound的函数但你的函数签名没有包含这个错误编译器会报错。这和 Rust 的?自动传播不同Zig 需要你显式声明或使用try。解决方法用!T让编译器推断错误集或者用error{A, B}!T明确列出。如果你不确定先用!T等稳定后再细化。5.3 comptime 计算过于复杂导致编译慢Zig 的comptime很强大但如果你在编译期做大量计算编译时间会显著增加。比如用comptime生成大数组、递归展开模板、做复杂字符串处理都可能让编译变慢。建议把编译期计算控制在合理范围内。如果发现编译变慢用compileLog检查编译期执行情况或者把部分计算移到运行时。5.4 标准库 API 变动Zig 还在快速迭代标准库 API 经常变动。你今天写的代码可能在下个版本就需要修改。比如std.ArrayList的初始化方式、std.fs的 API、std.io的读写接口都发生过变化。应对策略关注 Zig 的 release notes使用固定版本避免直接依赖 master 分支。如果用于生产建议锁定 Zig 版本等 API 稳定后再升级。5.5 异步编程的差异Rust 有成熟的async/await和tokio运行时写异步代码很方便。Zig 目前没有内置的异步运行时虽然语言层面有async关键字但标准库的支持还在发展中。如果你需要写高并发网络服务Zig 目前可能不如 Rust 方便。不过 Zig 的异步模型更底层你可以自己控制事件循环和调度。对于嵌入式或需要精细控制并发的场景这种灵活性反而有价值。问题类型Rust 表现Zig 表现建议内存泄漏编译器自动管理较少发生需手动 defer容易忘记每次 alloc 后立即写 defer错误传播?自动传播需try或显式声明错误集先用!T推断再细化编译速度大型项目较慢通常较快控制 comptime 复杂度标准库稳定性稳定有 edition快速变动锁定版本关注 release notes异步支持成熟tokio 生态发展中更底层高并发场景暂选 Rust6. 工具链与生态cargo、rustup 与 zig、build.zig 的日常使用6.1 安装与版本管理Rust 用rustup管理工具链可以轻松切换 stable、beta、nightly还能安装不同 target。rustup update更新工具链rustup target add添加交叉编译目标。这套工具非常成熟体验很好。Zig 的安装更简单下载压缩包解压把zig可执行文件放到 PATH 里。没有版本管理器你需要手动下载不同版本。不过 Zig 的单个可执行文件包含了编译器、标准库、构建系统不需要额外安装依赖。6.2 编辑器与 IDE 支持Rust 有rust-analyzer提供代码补全、跳转、重构、内联错误提示等功能体验接近 IDE。配合 VS Code 或 IntelliJ Rust开发效率很高。Zig 有zlsZig Language Server提供类似的补全和跳转功能但成熟度不如rust-analyzer。我在用 VS Code 写 Zig 时补全偶尔会失效需要重启zls。不过 Zig 的编译错误信息很清晰即使没有 IDE 也能快速定位问题。6.3 包管理与依赖Rust 的cargo配合 crates.io有海量第三方库。你可以用cargo add添加依赖cargo update更新版本cargo tree查看依赖树。sqlx、tauri、gpui这些库都能直接通过cargo使用。Zig 的包管理还在发展中。build.zig.zon可以声明依赖但中央仓库还不成熟。很多库需要手动从 Git 仓库拉取或者直接复制源码到项目中。这对于小型项目还好对于大型项目会增加维护成本。6.4 调试与性能分析Rust 有gdb、lldb支持cargo flamegraph可以做性能分析cargo bench做基准测试。生态工具很丰富。Zig 可以用gdb和lldb调试但工具链不如 Rust 丰富。Zig 的std.debug提供了基本的调试输出panic可以触发崩溃并打印堆栈。性能分析需要手动用perf或valgrind。提示如果你从 Rust 转到 Zig建议先从小项目开始熟悉 Zig 的构建系统和标准库。不要一上来就把大型 Rust 项目迁移到 Zig那样会同时面对语言差异和生态缺失的问题。7. 适用场景分析什么时候选 Rust什么时候选 Zig7.1 Rust 更适合的场景Rust 在以下场景优势明显大型后端服务tokio、axum、sqlx等库提供了完整的异步 Web 开发栈适合构建高并发、高可靠的服务。桌面应用Tauri 让 Rust 可以写跨平台桌面应用前端用 Web 技术后端用 Rust兼顾开发效率和性能。系统工具Rust 的内存安全特性适合写命令行工具、系统守护进程、网络代理等。需要成熟生态的项目如果你需要大量第三方库Rust 的 crates.io 是更好的选择。7.2 Zig 更适合的场景Zig 在以下场景更有优势嵌入式和裸机开发Zig 的交叉编译和显式内存管理非常适合资源受限的环境。ch32这类芯片用 Zig 开发可以减少工具链配置的麻烦。系统编程和底层库Zig 可以直接操作内存、调用 C 库、生成高效的机器码适合写操作系统、编译器、数据库等底层软件。需要精细控制内存和性能的场景Zig 的显式分配器让你完全掌控内存行为适合性能敏感的应用。学习和理解底层原理Zig 的简洁性让它成为学习系统编程的好选择。你不需要先理解所有权和生命周期就能写出可运行的程序。7.3 混合使用的可能性Rust 和 Zig 可以互相调用。Zig 可以编译成 C ABI 兼容的库Rust 可以通过 FFI 调用。反过来Rust 也可以导出 C ABI 函数给 Zig 使用。这种混合模式在需要兼顾生态和性能的场景下很有价值。我试过用 Rust 写上层业务逻辑用 Zig 写底层性能敏感的模块通过 C ABI 连接。这种架构结合了两者的优势但增加了构建复杂度。你需要同时管理cargo和build.zig确保 ABI 兼容。8. 个人体会从 Rust 到 Zig 的心态转变写了几个月 Zig 之后我最大的体会是Rust 让你相信编译器Zig 让你相信自己。在 Rust 里你写代码时会有一种“编译器在帮我检查”的安全感。在 Zig 里你更多是“我知道我在做什么”的掌控感。两者没有高下之分但适合不同的性格和项目需求。我一开始很不适应 Zig 的显式性觉得什么都得自己写太麻烦。但后来发现这种显式性在调试时特别有用你知道每一步发生了什么不需要猜测编译器在背后做了什么优化或转换。尤其是在嵌入式场景下Zig 的确定性让我更容易定位问题。另一个体会是Zig 的社区还在成长文档和示例不如 Rust 丰富。你经常需要读标准库源码来理解 API 用法。这虽然增加了学习成本但也让你更深入地理解语言本身。我在读std.ArrayList和std.HashMap的源码时学到了不少内存管理的技巧。最后分享一个小技巧如果你从 Rust 转到 Zig可以先从“用 Zig 重写一个 Rust 小工具”开始。不要追求功能完全一致而是关注 Zig 的写法怎么管理分配器、怎么处理错误、怎么组织构建脚本。写完之后对比两版代码你会对两种语言的设计取舍有更直观的理解。这个内容后续还可以这样扩展如果你对嵌入式开发感兴趣可以研究 Zig 在 RISC-V 和 ARM Cortex-M 上的支持如果你关注性能可以对比 Rust 和 Zig 在相同算法下的编译产物和运行效率如果你在做跨平台工具可以试试用 Zig 的交叉编译能力替代复杂的工具链配置。