【Go与Rust抉择：本质不是拼性能，而是错误处理时机的选择】

快速阅读：这并非关于性能的争论，而是一场关于“何时将错误交给编译器”的选择。Go 追求的是极简的开发效率与生态成熟度，而 Rust 则通过将运行时风险（如 nil 指针、数据竞争）编码进类型系统，换取了极高的生产环境稳定性。

很多人觉得从 Go 迁移到 Rust 是为了追求那点性能增益，其实这完全误解了迁移的本质。如果只是为了快那么一点，大可不必。真正的分水岭在于：你希望在开发阶段解决问题，还是在凌晨三点处理线上报警。

Go 的逻辑很直白，它把复杂性留给开发者，把简单留给工具链。它的标准库像一个极其稳固的底座，几乎涵盖了后端所需的一切。但这种简单是有代价的，比如到处可见的 `nil` 隐患，以及那种依赖开发者自觉才能完成的错误处理。你得靠 linter、靠代码评审、靠 `-race` 这种运行时检测来维持秩序。这就像是在高速公路上靠交警（工具链）来维持秩序，虽然有效，但总有疏漏。

Rust 则完全不同。它把所有的“规矩”都写进了编译器。如果你试图在没有锁的情况下共享变量，或者忽略了一个可能为空的返回值，编译器会直接拒绝工作。它不是在刁难你，它是在把原本属于运行时的“概率性崩溃”，转化成了编译时的“确定性错误”。这种把风险从运行时（Runtime）拉回到编译时（Compile time）的逻辑，才是它最核心的价值。

当然，这种安全性不是免费的。代价是陡峭的学习曲线和那令人头疼的编译速度。在 Rust 里，你得和 Borrow Checker 斗智斗勇，得理解什么是所有权。这就像是把交警换成了自动驾驶系统，虽然你开车累了，但系统保证了你不会冲出护栏。

有网友提到，在 LLM 时代，Rust 的严谨性反而成了优势，因为编译器提供的精准反馈能让 AI 更容易写出正确的代码。也有人担心，过重的依赖树和复杂的异步模型会拖慢迭代速度。

其实这没必要非黑即白。如果你的业务是那种对延迟极其敏感、或者对可靠性要求近乎苛刻的基础设施，Rust 是不二之选。但如果只是写个简单的 CRUD 业务，或者团队追求极致的交付速度，Go 依然是那个最务实的伙伴。

到底该选哪个？这取决于你愿意把成本花在“写代码”上，还是花在“修代码”上。

corrode.dev/learn/migration-guides/go-to-rust/