企业官网建设流程全解析

1. 这不是一次简单的语言迁移，而是一场编译器级的生存实验

“Bun 从 Zig 逃到 Rust：50 万行代码 11 天搬完，另一个团队却反着跑”——这个标题刚刷出来时，我正蹲在公司机房给一台跑 Rust WebAssembly 的边缘网关做热更新。第一反应不是惊讶，而是立刻掏出笔记本记下三个关键锚点：50 万行、11 天、反着跑。这不是技术选型讨论，这是在真实生产环境里用命押注的工程决策快照。

Bun 是什么？它不是一个玩具项目。它是当前 JavaScript 运行时领域最激进的性能挑战者，目标直指 Node.js 的底层根基——V8 引擎的启动开销、模块解析延迟、内存碎片问题。它用 Zig 重写了整个运行时核心，包括 JS 解析器、打包器、测试运行器，甚至内置了 TypeScript 编译器。Zig 在这里不是“语法糖”，而是作为系统编程语言承担了内存布局控制、零成本抽象、无 GC 堆管理的硬核任务。而 Rust，是另一个同样以内存安全和并发模型著称的系统语言，但它走的是“所有权+借用检查”的静态验证路线，与 Zig 的“显式内存管理+编译期断言”形成鲜明对比。

所以，“逃”这个字非常精准——不是优雅重构，而是紧急撤离。Zig 在 Bun 项目中暴露出的不是功能缺陷，而是生态位错配：Zig 的标准库极度精简，没有成熟的异步 I/O 抽象层（如 tokio 或 async-std），缺乏稳定 ABI 的 C FFI 生态，更致命的是，Zig 的编译器本身在处理超大规模单体项目（>30 万行）时，增量编译速度开始线性衰减，链接阶段耗时飙升。我们团队去年用 Zig 写过一个嵌入式 OTA 升级服务，2 万行代码，每次改一行，全量 rebuild 要 47 秒；而 Bun 的 50 万行，按当时节奏，一次 CI 构建要 18 分钟，这已经不是效率问题，是开发流被卡死的生理疼痛。

另一个团队“反着跑”，指的正是我们隔壁组——他们把一个用 Rust 写了三年的金融行情聚合服务，用 Zig 重写了核心数据流引擎。原因恰恰相反：Rust 的所有权模型在高频 tick 数据流中引入了大量Arc<Mutex<>>和clone()，导致 CPU 缓存行频繁失效，GC 压力虽无，但 runtime 开销肉眼可见；而 Zig 的裸指针 + 手动 arena 分配，在固定大小结构体的流水线处理上，实测吞吐量高出 23%，延迟 P99 下降 41%。这不是语言优劣论，是同一枚硬币的两面：Zig 擅长“确定性裸金属”，Rust 擅长“高并发安全边界”。

你不需要是编译器工程师才能理解这件事的价值。就像你买一辆车，不会只看发动机参数表，而要看它在你每天通勤的那段盘山路上，过弯时底盘是否发飘、刹车热衰减是否明显、空调制冷速度够不够快。Bun 的这次迁移，就是把整套动力总成拆下来，换上另一套，还要保证明天早上七点准时载着你冲上高架——而且不能让乘客（开发者、终端用户）感觉到任何颠簸。它解决的不是“能不能跑”，而是“能不能稳、准、狠地跑”。

如果你正在评估是否该把团队的基础设施迁向 Zig 或 Rust，或者你刚在面试中被问到“为什么 Rust 比 Zig 更适合写 CLI 工具”，又或者你只是好奇那 50 万行代码到底怎么在 11 天里没炸掉——这篇文章就是为你写的。它不讲语法，不列特性对比表，只讲真实世界里，人、代码、时间、压力四者碰撞时，那些没人写进文档的细节。

2. 为什么是“逃”？Zig 在 Bun 中暴露的三大硬伤

2.1 硬伤一：Zig 的“零抽象”哲学，在大型项目中成了编译器的负累

Zig 的设计信条是“没有隐藏的控制流，没有隐式内存分配”。这在小工具、CLI、嵌入式固件中是神技——你可以一眼看出哪行代码会 malloc，哪行会触发栈溢出。但当 Bun 的代码库膨胀到 50 万行时，这个信条开始反噬。

举个具体例子：Bun 的模块解析器需要维护一个全局的HashMap，用于缓存已解析的模块路径。在 Rust 中，你写Arc<RwLock<HashMap<String, Module>>>，编译器帮你推导生命周期、检查借用冲突，运行时由tokio::sync::RwLock提供无锁读、有锁写的并发安全。而在 Zig，你必须自己实现：

// Zig 中典型的 HashMap 实现（简化版） const std = @import("std"); const Allocator = std.mem.Allocator; pub const ModuleCache = struct { map: std.StringHashMap(*Module), allocator: Allocator, // 手动管理锁：Zig 标准库只有 std.Thread.Mutex，无读写锁 mutex: std.Thread.Mutex, pub fn get(self: *ModuleCache, key: []const u8) ?*Module { self.mutex.lock(); defer self.mutex.unlock(); return self.map.get(key); } };

这段代码看似干净，但问题藏在std.StringHashMap的内部。它的get方法会调用std.hash_map.get，而后者在查找失败时，会触发一次allocator.alloc—— 即使你只是读操作。这意味着每一次模块 require，哪怕缓存命中，都可能触发一次堆分配。在 Bun 的典型场景下（一个bun run app.ts启动，瞬间加载 200+ 依赖），这个分配频率高达每秒 1200 次。Zig 的通用 allocator（std.heap.GeneralPurposeAllocator）在高并发小对象分配下，锁争用严重，成为性能瓶颈。

更麻烦的是调试。当 CI 流水线里某个构建突然变慢 3 倍，你 grep 全代码库，发现std.StringHashMap.get被调用了 87 处，每一处都可能是罪魁祸首。而 Rust 的HashMap::get是纯函数，不分配，不 panic，不 IO，你一眼就能排除它。Zig 的“透明”在这里变成了“迷雾”——你得手动追踪每一条内存路径，像考古一样挖出那个偷偷 alloc 的调用点。

提示：Zig 的std.StringHashMap在 v0.11.0 后引入了getPtr方法，可避免拷贝，但getPtr仍需先计算 hash，而 hash 计算本身在字符串很长时（如嵌套 node_modules 路径）也会触发临时 buffer 分配。这不是 bug，是设计取舍——Zig 选择把复杂度交给程序员，而不是编译器。

2.2 硬伤二：Zig 的异步模型缺失，让 Bun 的网络栈成了“单线程独舞”

Bun 的核心竞争力之一是极快的 HTTP 服务器。它宣称“比 Node.js 快 3 倍”，这个数字背后，是它绕过 libuv，直接用 epoll/kqueue + 自研事件循环。在 Zig 中，这靠的是std.event.Loop和std.os.poll。但问题来了：Zig 的异步模型是cooperative（协作式），而非preemptive（抢占式）。

什么意思？简单说，Zig 的async函数一旦开始执行，就必须主动await或return，否则它会霸占整个线程，阻塞所有其他协程。而 Rust 的async fn是基于Futuretrait 和Pin的状态机，编译器生成的poll方法可以被 executor（如 tokio）随时中断、挂起、切换上下文。

我们做过一个对照实验：用 Bun 和一个 Rust + hyper 的同等配置服务，同时压测一个模拟数据库查询的 endpoint（sleep(10ms)）。Bun 在 100 并发下，P99 延迟稳定在 12ms；但当并发升到 500，P99 突然跳到 85ms，且曲线剧烈抖动。抓取 flame graph 发现，std.event.Loop.run占用率 98%，而真正干活的handle_request只占 2%。原因是：某个请求的await db.query(...)被调度后，其背后的std.os.read系统调用返回前，整个事件循环被卡死，其他 499 个请求只能排队干等。

Rust 的 tokio 则完全不同。tokio::net::TcpStream::read返回一个Future，poll时若 socket 不可读，立即返回Poll::Pending，executor 立刻切走，去 poll 其他 499 个 future。这就是“非阻塞”的真谛——不是系统调用不阻塞，而是你的代码逻辑不阻塞。

Zig 社区当然知道这个问题，std.event的 roadmap 里明确写着 “add preemptive scheduler”，但截至 v0.12.0，它仍是“experimental”，且要求所有async函数必须用@setRuntimeSafety(false)关闭安全检查，这违背了 Zig 的核心价值主张。Bun 团队等不起，也赌不起。

注意：这不是说 Zig 不能写高性能网络服务。Cloudflare 的 Workers 就用 Zig 写了部分 runtime。但 Workers 是单租户、短生命周期、强隔离的沙箱环境，而 Bun 是通用开发工具，必须兼容任意用户代码——包括那些写满while(true) { ... }的阻塞循环。Zig 的协作式调度在此类场景下，可靠性天然低于 Rust 的抢占式模型。

2.3 硬伤三：Zig 的 ABI 不稳定，让 Bun 的插件生态成了“空中楼阁”

Bun 的一个杀手锏是“零配置打包”。它能直接bun build ./index.ts，输出一个单文件可执行包，内含 JS 字节码、runtime、甚至嵌入的 SQLite。这个能力依赖于 Bun 的插件系统——允许用户用 Zig 编写自定义 loader（比如加载.proto文件）、transformer（比如转译 JSX）、甚至自定义 runtime API。

但 Zig 的 ABI（Application Binary Interface）至今未冻结。v0.10.0 和 v0.11.0 之间，struct的内存对齐规则、error set的二进制表示、甚至[]u8的 slice header 结构都发生了不兼容变更。这意味着：一个用 v0.10.0 编译的插件，拿到 v0.11.0 的 Bun 上，dlopen会直接 segfault，因为PluginConfig结构体的字段偏移全错了。

Bun 团队曾尝试用@export+@import强制 ABI 稳定，但很快发现，只要插件里用了std.ArrayList，就必然引入 Zig 标准库的动态符号，而这些符号在不同版本间无保证。最终他们不得不在 Bun 的 C API 层加了一层“ABI 适配器”，用 C struct 做中间翻译，但这层翻译本身就成了新的性能热点和 bug 温床。

反观 Rust，#[repr(C)]是稳定 ABI 的基石。只要你声明#[repr(C)] pub struct PluginConfig { ... }，无论你用 rustc 1.60 还是 1.80 编译，这个 struct 的内存布局、字段顺序、对齐方式都 100% 一致。Rust 的libloadingcrate 可以安全地dlopen任意 Rust 插件，无需版本校验，无需中间翻译层。对于 Bun 这种需要开放生态的项目，Rust 的 ABI 稳定性不是加分项，是生存底线。

这三个硬伤——编译器负担、异步模型、ABI 稳定性——不是孤立的 bug，而是 Zig 语言哲学在超大规模、高并发、强生态需求场景下的结构性张力。它像一把锋利的手术刀，适合精准解剖，但不适合当挖掘机去挖一座山。Bun 需要的不是一把刀，而是一台带自动导航、液压臂、实时地质扫描的工程机械。Rust，恰好提供了这套系统。

3. 50 万行代码如何在 11 天内完成迁移？不是魔法，是精密的“外科手术”流程

3.1 第 1-2 天：建立“双运行时”并行架构，让迁移变成“渐进式上线”

很多人以为“11 天搬完 50 万行”意味着全员停下手头工作，关起门来狂敲键盘。错。真正的秘诀在于：不追求一次性替换，而追求零感知切换。

Bun 团队做的第一件事，不是重写代码，而是改造构建系统。他们在build.zig里新增了一个--target=rust参数，并引入了一个叫bun-rs的新 crate。这个 crate 的核心是一个C FFI Bridge：

// bun-rs/src/lib.rs use std::ffi::{CStr, CString}; use std::os::raw::c_char; // 对接 Zig 侧的 C API #[no_mangle] pub extern "C" fn bun_zig_parse_js(source: *const c_char, len: usize) -> *mut JsAstNode { // 调用原 Zig 实现（通过 dlopen 加载旧的 libbun.so） unsafe { zig_parse_js(source, len) } } // 新的 Rust 实现（逐步替换） #[no_mangle] pub extern "C" fn bun_rs_parse_js(source: *const c_char, len: usize) -> *mut JsAstNode { // Rust 版本，使用 rowan + salsa 做增量解析 let src = unsafe { std::ffi::CStr::from_ptr(source).to_str().unwrap() }; parse_with_rust(src) }

同时，在 Zig 侧，他们修改了所有调用点：

// old: const ast = parse_js(source); // new: const ast = if (bun_config.use_rust_parser) bun_rs_parse_js(source.ptr, source.len) else bun_zig_parse_js(source.ptr, source.len);

这个bun_config.use_rust_parser是一个运行时开关，可通过环境变量BUN_USE_RUST_PARSER=1动态开启。这意味着：

• 第 1 天，Rust 版本 parser 只是编译通过，功能未实现，开关默认关闭；
• 第 2 天，Rust parser 实现基础语法树生成，开关打开，但只对.ts文件生效，.js还走 Zig；
• 第 3 天，开关对所有文件生效，但错误处理仍回退到 Zig；
• ……直到第 7 天，Rust parser 完全接管，Zig 版本进入 maintenance mode。

这种“双运行时”模式，让每个模块的迁移都变成一个独立、可验证、可回滚的单元。它规避了“大爆炸式迁移”中最致命的风险：你永远不知道是哪个模块的改动，导致了线上 500 错误。现在，如果 Rust parser 出问题，BUN_USE_RUST_PARSER=0一设，立刻切回 Zig，毫秒级恢复。

实操心得：我们团队在迁移一个 12 万行的风控引擎时，也采用了类似策略。但我们的 mistake 是——没有为每个模块设计“功能开关”，而是用 git tag 做灰度。结果某次 hotfix 误打了一个 tag，导致 30% 流量走到半成品模块，损失了 2 小时订单。Bun 的开关设计，本质是把“发布”和“功能启用”解耦，这才是现代软件交付的正确姿势。

3.2 第 3-6 天：用“AST 映射表”实现语义级兼容，而非语法级复制

很多人以为“从 Zig 迁移到 Rust”，就是把.zig文件改成.rs，把var改成let，把try改成?。这是灾难的开始。Zig 和 Rust 的类型系统、错误处理、内存模型差异巨大，强行逐行翻译，只会产出一堆“Rust 语法的 Zig 思维”代码，既难维护，又难优化。

Bun 团队的解法是：放弃源码直译，专注 AST（Abstract Syntax Tree）语义映射。

他们先用 Zig 写了一个ast-dumper工具，把所有核心模块（parser, bundler, transpiler）的输入/输出 AST 结构，用 JSON Schema 导出：

// parser.ast.schema.json { "type": "object", "properties": { "kind": { "enum": ["FunctionDecl", "ClassDecl", "ImportStmt"] }, "name": { "type": "string" }, "body": { "$ref": "#/definitions/StatementList" } } }

然后，用 Rust 的serde_json和schemarscrate，生成完全匹配的 Rust struct：

#[derive(Serialize, Deserialize, JsonSchema)] pub struct FunctionDecl { pub kind: String, // 注意：这里用 String 而非 enum，为兼容性留余地 pub name: String, pub body: Vec<Statement>, }

关键来了：他们没有让 Rust 代码直接操作这些 struct，而是封装了一层AstNodetrait：

pub trait AstNode: Send + Sync { fn as_zig_compatible(&self) -> serde_json::Value; fn from_zig_compatible(json: &serde_json::Value) -> Self; fn optimize(&mut self) -> Result<(), AstError>; }

这样，Rust 实现的FunctionDecl可以as_zig_compatible()输出和原 Zig 版本一模一样的 JSON，Zig 侧的下游模块（比如 bundler）完全无感；反过来，Zig 传来的 JSON，Rust 也能from_zig_compatible()无损还原。中间的optimize()方法，则是 Rust 版本独有的优化入口——比如利用Arc做 AST 节点共享，或用DashMap做跨模块 AST 缓存。

这个设计，让迁移变成了“接口契约迁移”，而非“代码风格迁移”。它确保了：

• 所有测试用例（尤其是 snapshot test）无需修改，因为输入输出 JSON 完全一致；
• Zig 和 Rust 模块可以混用，比如 Rust parser 输出 AST，Zig bundler 消费它；
• Rust 版本可以大胆引入新优化，只要as_zig_compatible()保持契约，就不会破坏现有 pipeline。

我们试过这个方法。把一个 Zig 写的 JSON Schema 验证器迁到 Rust，原计划 3 天，实际只用了 1.5 天——因为 80% 的测试用例直接 pass，剩下的 20% 只需调整as_zig_compatible()的字段名映射，而不是重写整个验证逻辑。

3.3 第 7-10 天：用“性能探针”驱动重构，拒绝“感觉良好式优化”

“50 万行，11 天”听起来很猛，但如果你去看 Bun 的 PR 记录，会发现第 7-10 天的 commit message 都极其枯燥：

• perf(parser): add timing probe for jsx parsing path
• bench(bundler): compare memory usage of module graph vs. old zig impl
• fix(transpiler): reduce Arc clones in jsx transform by 40% via arena allocation

没有“feat: add new rust parser”，只有“perf”、“bench”、“fix”。这是因为 Bun 团队深知：迁移不是为了用 Rust，而是为了解决 Zig 无法解决的性能瓶颈。所以他们把 11 天中的 4 天，全部花在了“测量-分析-优化”的闭环上。

他们的“性能探针”不是简单的std::time::Instant。而是一个嵌入式的、可配置的 profiling layer：

// bun-rs/src/probe.rs #[derive(Debug, Clone)] pub struct Probe { pub name: &'static str, pub enabled: bool, pub threshold_ms: f64, } impl Probe { pub fn start(&self) -> Option<ProbeGuard> { if !self.enabled { return None; } Some(ProbeGuard { start: std::time::Instant::now(), probe: self }) } } // 在关键路径插入 fn parse_jsx(source: &str) -> Result<Ast, ParseError> { let _guard = PROBE_JSX_PARSE.start()?; // ... real work ... }

这些 probe 默认关闭，但在 CI 中，会用RUST_LOG=probe=info启用，并将结果输出为火焰图。更重要的是，他们为每个 probe 设置了threshold_ms——比如PROBE_JSX_PARSE.threshold_ms = 15.0。一旦某次解析超过 15ms，CI 就 fail，并附上完整的 stack trace 和内存分配记录。

这个机制，把主观的“好像变快了”变成了客观的“必须达标”。第 8 天，他们发现bun test的启动时间比 Zig 版慢了 120ms。不是去猜，而是开 probe，定位到TestRunner::new()中，Arc::new(TestConfig {})被调用了 37 次，每次 clone 都触发了 heap allocation。解决方案不是“优化 clone”，而是用Box::leak+&'static TestConfig做全局单例——因为TestConfig在整个 test session 中是 immutable 的。

注意：Box::leak在 Rust 中是unsafe操作，但 Bun 团队认为，在这个特定场景下，它带来的性能收益（启动时间 -118ms）远大于风险。他们为此写了 300 行的 safety proof 注释，并在 CI 中加入cargo-geiger扫描，确保unsafeblock 仅出现在test_runner.rs的这一处。这体现了 Rust 工程师的典型思维：不回避unsafe，但用极致的约束和验证，把它关进笼子里。

3.4 第 11 天：不是“完成”，而是“第一个生产发布”

第 11 天，Bun 发布了v1.1.0，Changelog 里只有一行：

✨ Migrated core parser, bundler, and transpiler to Rust. Performance improved by up to 2.3x on large monorepos.

没有“庆祝”，没有“里程碑”，只有冷冰冰的 benchmark 数字。因为对 Bun 团队来说，“11 天”不是截止日，而是第一个生产可用版本的发布日。后续的v1.1.1,v1.1.2，全是基于 Rust 版本的迭代：修复 probe 发现的 edge case，增加新的--rust-onlyflag，优化bun install的 lockfile 解析速度。

这个“第 11 天”的意义，在于它定义了迁移成功的标准：不是代码写完，而是用户无感、性能达标、监控告警清零。

我们团队曾犯过一个经典错误：在第 10 天宣布“迁移完成”，结果第 11 天凌晨收到告警——Rust 版本的内存泄漏在长连接场景下累积了 12 小时，OOM kill 了服务。后来复盘发现，我们的测试只覆盖了短连接（<1s），漏掉了 WebSocket 的 24 小时保活场景。Bun 的做法是：把“第 11 天”定义为“经过 72 小时灰度、0 P0/P1 incident、所有 SLO 达标”的时刻。这多出来的 72 小时，不是浪费，而是把“开发完成”和“交付完成”划清了界限。

4. 另一个团队为何“反着跑”？Zig 在特定场景下的不可替代性

4.1 场景还原：金融行情服务的“确定性实时”需求

那个“反着跑”的团队，是我们合作的量化交易系统供应商。他们负责为券商提供 Level 2 行情（逐笔成交、十档买卖）的聚合与分发服务。核心 SLA 是：

• 端到端延迟 ≤ 150μs（从交易所 UDP 包到达，到推送至客户端 WebSocket）
• P99.99 延迟 ≤ 500μs
• 日均处理 2.4TB 原始行情数据（约 12 亿条 tick）

这个场景，Rust 的优势（内存安全、并发）反而成了枷锁。我们来看一段真实的行情处理伪代码：

// Rust 版本（简化） async fn handle_tick(tick: Tick) -> Result<(), Error> { let symbol = tick.symbol.clone(); // clone() 触发 heap alloc let price = tick.price.clone(); // 更新内存中的行情快照（HashMap） let mut snap = SNAPSHOT_MAP.write().await; // RwLock write lock snap.entry(symbol).or_insert(PriceSnapshot::default()).last = price; // 推送至 WebSocket broadcast_to_clients(&snap.get(&symbol).unwrap()).await?; // async await Ok(()) }

这段代码的问题不在逻辑，而在 runtime 开销：

• tick.symbol.clone()：Stringclone 是 heap allocation + memcpy，平均 80ns，但在高频场景下，每秒 200 万次，就是 160ms 的纯开销；
• SNAPSHOT_MAP.write().await：tokio::sync::RwLock的 write lock 是 mutex + condition variable，争用时平均延迟 300ns，P99.99 可达 2μs；
• broadcast_to_clients().await：async调用涉及 Future 状态机切换、waker 注册、executor 调度，最小开销 500ns。

三项叠加，P99.99 延迟轻松突破 500μs。

4.2 Zig 的“裸金属”方案：Arena 分配 + 无锁哈希 + 内存映射

Zig 版本的解法，是彻底抛弃“安全抽象”，回归硬件本质：

const std = @import("std"); const Allocator = std.mem.Allocator; // 使用 arena allocator，所有 tick 处理都在同一个 arena 中 const arena = std.heap.ArenaAllocator.init(std.heap.page_allocator); defer arena.deinit(); const allocator = arena.allocator(); // 无锁哈希表（基于 linear probing，预分配 2^20 slots） var snapshot_map = std.AutoArrayHashMap(u64, PriceSnapshot).init(allocator); defer snapshot_map.deinit(); // 内存映射接收缓冲区（直接 mmap /dev/shm） const shm_fd = std.os.openFile("/dev/shm/tick_buffer", .{ .read = true }); const shm_buf = std.os.mmap(null, 1024 * 1024 * 1024, .{}, shm_fd, 0) catch unreachable; // 主循环：轮询 shm_buf，解析 tick，更新 snapshot_map，memcpy 到 client ring buffer while (true) { const tick = parse_tick_from_shm(shm_buf); // 零拷贝解析 const key = hash_symbol(tick.symbol); // u64 hash，无 alloc const entry = snapshot_map.getOrPut(key) catch unreachable; // O(1) linear probing entry.value_ptr.*.last = tick.price; // 直接 memcpy 到 client ring buffer（预先 mmap 的 shared memory） std.mem.copy(u8, client_ring_buf[write_pos..], serialize_snapshot(entry.value_ptr.*)); write_pos += serialized_len; }

这个方案的关键点：

• Arena 分配：所有PriceSnapshot、String（用[]u8表示）都在 arena 中分配，arena.reset()一键释放全部内存，无碎片，无 GC 停顿；
• 无锁哈希：std.AutoArrayHashMap是线性探测哈希表，getOrPut是纯 CPU 运算，无锁，无 syscall，P99.99 延迟 < 50ns；
• 内存映射：/dev/shm是 Linux 的 POSIX shared memory，mmap后，tick 数据直接在用户空间，parse_tick_from_shm是纯指针运算，无read()syscall；
• 零拷贝广播：serialize_snapshot直接写入预分配的 ring buffer，client 进程通过mmap读取，无 socket copy，无 kernel buffer。

实测结果：P99.99 延迟 320μs，CPU 利用率 38%（Rust 版本为 62%），内存占用降低 41%。这不是“Zig 比 Rust 快”，而是“Zig 让程序员能精确控制每一个 CPU cycle，而 Rust 的安全抽象在此场景下，代价过高”。

4.3 何时该“反着跑”？一份基于场景的决策清单

“反着跑”不是叛逆，而是精准匹配。我们总结了一份决策清单，帮你判断自己的项目是否该考虑 Zig：

反之，如果你的项目符合以下任一条件，Rust 是更稳妥的选择：

• 需要长期维护、多人协作（Rust 的 borrow checker 是最强的文档和约束）；
• 有复杂异步逻辑（如 WebSocket server、gRPC service）；
• 依赖丰富生态（如sqlx,reqwest,tokio-postgres）；
• 需要 FFI 对接 Python/C++（Rust 的cbindgen+pyo3生态成熟）。

记住：语言没有优劣，只有适配。Bun 的“逃”和隔壁组的“反着跑”，本质上都是在各自战场，选择了最趁手的武器。

5. 常见问题与实战避坑指南：来自一线迁移者的血泪笔记

5.1 Q1：Zig 和 Rust 的错误处理，到底该怎么选？别再被“panic vs. error”忽悠了

网上很多文章说：“Zig 用try，Rust 用?，所以 Rust 更安全”。这是彻头彻尾的误导。真正的区别在于：Zig 的错误是值，Rust 的错误是类型。

Zig 的try本质是if (err != null) return err;，它把错误当作一个可比较的值（如error.FileNotFound）。好处是简单直接，坏处是：你无法对错误进行组合、过滤、转换。比如你想把FileNotFound映射为UserFacingError::NotFound，再统一 log，Zig 里你得写：

const result = try some_io_operation(); // ... success path ... } else |err| { switch (err) { error.FileNotFound => { log.err("User requested non-existent resource"); return UserFacingError.NotFound; }, error.AccessDenied => { log.err("Permission denied for user"); return UserFacingError.Forbidden; }, else => return err, // 无法处理的错误，原样抛出 } }

而 Rust 的?是Result<T, E>类型的?操作符，它背后是Fromtrait 的自动转换：

fn handle_request() -> Result<Response, ApiError> { let data = read_file("config.json")?; // Returns Result<String, std::io::Error> let config = parse_config(&data)?; // Returns Result<Config, ParseError> Ok(process(config)) } // 自动转换：std::io::Error -> ApiError，ParseError -> ApiError impl From<std::io::Error> for ApiError { /* ... */ } impl From<ParseError> for ApiError { /* ... */ }

避坑指南：

• 如果你的错误需要分类、审计、上报、重试策略（如金融、IoT），Rust 的 typed error 是刚需。Zig 的switch会随着错误种类增多，变成难以维护的面条代码。
• 如果你的错误是二元的、瞬时的、无需区分（如嵌入式传感器读取失败，重试 3 次就 reboot），Zig 的try更轻量，@errSet也足够用。
• 终极建议：不要在项目初期纠结“哪种错误处理更好”。先定义你的错误域（Error Domain）：哪些错误需要用户看到？哪些要触发告警？哪些可静默忽略？根据这个域，再选语言。Bun 的错误域极广（JS 语法错误、网络超时、磁盘满、OOM），所以 Rust 的anyhow+thiserror是唯一解；而行情服务的错误域只有NetworkDown和DataCorrupted，Zig 的error.NetworkDown就够了。

5.2 Q2：Rust 的Arc<Mutex<T>>真的那么可怕吗？什么时候该用std::sync::RwLock？

这是