本文永久链接 – https://tonybai.com/2025/05/10/rust-dependencies-scare-me

大家好，我是Tony Bai。

在现代软件开发中，高效的包管理系统和繁荣的开源生态极大地加速了我们的开发进程。Rust语言的Cargo及其crates.io生态便是其中的佼佼者，为开发者带来了前所未有的便捷。然而，这种便捷性是否也伴随着一些潜在的“代价”？

近期，一位名叫Vincent的国外Rust开发者在其博客文章《Rust Dependencies scare Me》中，就真诚地抒发了他对Rust依赖管理的深切忧虑。这篇博文在Hacker News等社区引发了热烈讨论，其指出的问题——从依赖的维护性到惊人的代码体积——或许也值得我们每一位使用现代包管理系统的开发者深思。

今天，我们就来一起解读Vincent的这篇文章，看看他遇到了哪些具体问题，并结合社区的智慧与我们的经验，探讨这些现象背后的启示。

Cargo的魅力：作者眼中的“美好一面”

在这位开发者看来，Cargo无疑是Rust生态的巨大优势。他强调，Cargo极大地提升了生产力，开发者无需像使用CMake(多用于C++项目)那样手动管理和链接文件。这使得在不同架构和操作系统（如他的M1 MacBook和Debian桌面）之间切换变得异常顺畅。

他坦言，在大部分情况下，Cargo让他几乎可以不必过多思考包管理本身，从而能更专注于核心代码的编写。这种“无感”的便捷体验，与上世纪80年代开发者需要为节省软盘空间而精打细算地“手动挑选和集成库代码”形成了鲜明对比，无疑是现代包管理系统追求的目标，也是Rust吸引开发者的重要原因之一。

当便捷遭遇“意外”：dotenv引发的警惕

然而，文章作者也指出，正是这种“不用思考”的便捷，可能让人变得“草率”。

他在一个生产项目中使用了许多Rust开发者都用过的dotenv库（用于加载.env文件）。项目平稳运行数周后，他偶然发现一则Rust安全通告指出，他所使用的dotenv版本已无人维护，并推荐了替代方案dotenvy。

这个小插曲让他开始反思：这个依赖真的必不可少吗？他尝试后发现，仅仅35行代码便实现了他所需的核心功能。他由此提出一个普遍性的问题：当依赖项（尤其是那些看似“微不足道”的）不再维护或出现安全漏洞时，我们该如何应对？那些我们真正“需要”的复杂依赖，又隐藏着哪些风险？这不仅仅是功能问题，更关乎依赖的信任链和维护者的责任。

百万行代码的“冲击波”：一个“小项目”的真实体积

Vincent的忧虑不止于此。他以一个自认为“微不足道”的Web服务项目为例——该项目使用广受好评的异步运行时tokio和Web框架axum，主要功能是处理请求、解压文件和记录日志。

当他尝试使用cargo vendor将所有依赖项本地化时，并用代码行数统计工具tokei进行分析，结果令他大吃一惊：总代码行数高达360万行！而他自己编写的业务代码仅有约1000行。

他将此与Linux内核的2780万行代码进行对比，发现他这个“小项目”的依赖代码量已接近后者的七分之一。他不禁发问：如何审计如此庞大的代码量？我们引入的重量级依赖，其绝大部分功能是否是我们项目真正需要的？

Vincent的经历并非个案。Hacker News社区的讨论中，有开发者（如kion）指出，现代软件开发中‘库叠库’的现象十分普遍，每一层依赖可能只用到其功能的冰山一角，但最终却可能导致简单的应用膨胀到数百MB。更有甚者（如jiggawatts）通过计算发现，仅三层依赖的层层叠加，就可能导致最终应用中88%的代码是“死代码”或从未被真实业务逻辑触及的“幽灵代码”。

Rust依赖困境的“求解”：作者的困惑与社区的多元声音

面对如此庞大的依赖代码和潜在风险，该博主坦诚自己“没有答案”。他提及了社区中一些常见的讨论方向，例如扩展标准库的利弊、开发者自身的责任以及业界大厂的实践等。

Hacker News社区的讨论进一步丰富了这些思考：

• 编译时优化是否足够？ 许多评论提到了链接时优化（LTO）、Tree Shaking等技术在剔除未使用代码方面的作用。Rust基于LLVM的优化确实能在这方面做出贡献。然而，正如一些评论者指出的，这些优化并非“银弹”，对于动态分发或包含大量可选编译特性的复杂依赖，完美剥离未使用部分仍充满挑战。
• 更细粒度的依赖控制： Rust的features机制为选择性编译提供了可能，但社区也在探索更根本的解决方案。有开发者甚至提出了“超细粒度符号和依赖”的设想，即每个语言构造都声明其精确依赖，按需构建最小代码集，尽管这在实现上极具颠覆性。
• 工具链的局限与期望： Vincent指出Cargo目前难以精确追踪最终编译产物包含的代码。社区也期待更强大的工具来分析依赖树、识别冗余、评估安全风险。

最终，文章作者将问题抛给了社区：我们应该怎么办？

我们的启示：从Rust的“依赖之忧”看现代软件供应链

Vincent的博文真实地反映了现代软件开发中普遍存在的“依赖困境”——我们享受着开源生态带来的便利，但也面临着供应链安全、代码膨胀、维护性等一系列挑战。

从他的分享和社区的热烈讨论中，我们可以得到以下几点启示：

1. 审慎评估依赖，警惕“依赖膨胀”的陷阱，拥抱适度“复制”： “不要为了碟醋包饺子”。在引入任何依赖前，都应评估其必要性、维护状态、社区活跃度以及潜在的安全风险。正如Go社区所倡导的“A little copying is better than a little dependency. (一点复制代码胜过一点点依赖)”，有时为了避免引入一个庞大或不稳定的依赖，适度复制代码，或者自己实现一个轻量级的核心功能，可能是更明智的选择。Go语言设计者之一的 Rob Pike 在其著名的演讲《On Bloat》中也曾深刻地警示过软件膨胀的危害，其中就包括了因过度或不必要依赖导致的复杂性增加和性能下降。Pike强调，真正的简洁和高效往往来自于对问题本质的深刻理解和对引入外部因素的克制。

2. 理解依赖的“冰山效应”与供应链安全——真实的威胁就在身边： 一个看似简单的库，背后可能隐藏着庞大的间接依赖。我们需要关注整个依赖树的健康状况。更重要的是，正如Hacker News上一些开发者强调的，依赖的真正“恐惧”更多在于供应链安全和代码的可审查性。当我们的项目依赖数百万行来自互联网的未知代码时，如何确保没有恶意代码或严重漏洞被悄然引入？这绝非危言耸听！就在最近，Socket威胁研究团队便披露了三个恶意的Go模块 (github.com/truthfulpharm/prototransform, github.com/blankloggia/go-mcp, github.com/steelpoor/tlsproxy)。这些模块通过命名空间混淆或伪装诱导开发者引入，其内部包含高度混淆的恶意代码，在特定条件（目前主要针对Linux系统）下会下载并执行毁灭性的“磁盘擦除”脚本 (done.sh)，直接向主磁盘写入零，导致数据被完全清零且无法恢复！这个案例血淋淋地提醒我们，供应链安全是每一个开发者都必须严肃对待的现实威胁。 这需要我们对信任链和维护者责任有更清醒的认识。

3. 寻求更精细的控制与工具支持： 无论是语言特性（如Go的build tags、Rust的features）、包管理工具（如更智能的tree shaking），还是库本身的模块化设计，都应朝着让开发者能更精细控制最终产物的方向努力。同时，自动化工具在依赖分析、漏洞扫描、许可证合规等方面扮演着越来越重要的角色。

4. 标准库与生态的平衡： Go语言的“大标准库”策略在一定程度上缓解了对外部依赖的过度渴求，但也带来了标准库自身迭代和灵活性的挑战。Rust选择了更小的标准库和更繁荣的社区生态。Hacker News上的讨论也反映了这种分歧：一部分开发者期望Rust能拥有更丰富的标准库，以减少对外部“寻寻觅觅”的困扰；而另一部分则担心这会扼杀生态活力，导致标准库“僵化”。这两种模式各有其历史成因和现实取舍，值得我们持续观察和学习，或许未来会出现一种更优的“官方认证扩展库”或“元库”的形态。

讨论：你如何看待现代软件的“依赖管理”？

这篇文章所转述的思考与社区的热议无疑为我们敲响了警钟。你在日常开发中（无论是Rust、Go还是其他语言），是否也曾遇到过类似的依赖管理难题？你认为当前包管理生态面临的最大挑战是什么？又有哪些值得推广的最佳实践或工具？

非常欢迎在评论区留下你的宝贵见解和经验分享！

• 原文链接：https://vincents.dev/blog/rust-dependencies-scare-me
• Socket.dev发现恶意Go模块：https://socket.dev/blog/wget-to-wipeout-malicious-go-modules-fetch-destructive-payload

面对复杂的依赖与潜藏的风险，如何系统性提升你的Go安全意识与底层掌控力？

近期Go恶意模块的“磁盘擦除”事件，再次凸显了深入理解依赖、掌握底层机制、构建安全软件的重要性。如果你渴望系统性地学习Go语言的深层原理（包括编译、链接、运行时），提升对第三方库的辨别与审计能力，并在实践中规避类似的安全“大坑”…

那么，我的 「Go & AI 精进营」知识星球 将是你不可或缺的伙伴！这里不仅有【Go原理课】、【Go进阶课】、【Go避坑课】助你洞悉语言本质，更有针对性的安全实践讨论和案例分析。我会亲自为你解答各种疑难问题，你还可以与众多对技术安全与底层有追求的Gopher们一同交流，共同构建更安全的Go生态。

立即扫码加入，为你的技术栈装上“安全防火墙”，在复杂的软件世界中行稳致远！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

本文永久链接 – https://tonybai.com/2025/04/29/hard-truths-before-switching-to-go

大家好，我是Tony Bai。

Go 语言近年来势头强劲，凭借其简洁、高效、出色的并发能力和工具链，吸引了大量开发者投身其中。甚至连TypeScript 团队也宣布将其编译器和工具集迁移到 Go，以提升性能。这无疑是对 Go 的巨大认可。

然而，正如一位拥有超过 15 年经验（主要使用 Java/Kotlin/TypeScript）、并在过去一年深度使用 Go 的开发者（以下简称“视频作者”）在其分享的油管视频中提到的那样，尽管 Go 非常出色，但光环之下并非没有阴影。在投入实际项目，特别是构建一些非同小可的东西之后，会发现 Go 的一些设计决策有利有弊，有些“简洁”的背后隐藏着需要注意的“真相”。

这位作者认为，计划学习或在下一个项目中使用 Go 的开发者，都应该了解这些潜在的“硬伤”或权衡。以下是他总结的、在转向 Go 之前你需要真正了解的五件事，主要转述自他的分享：

真相一：简洁的表象与表达力的代价

Go 最大的卖点之一是它的简洁性。表面上看，它确实如此。但视频作者认为，一旦你超越了教程的范畴，就会发现这种简洁很多时候是以牺牲表达力为代价的。

• 隐藏而非消除复杂性？
  • 比如，Go 有 while 循环的功能，却没有 while 关键字，你需要用 for 循环省略条件来实现。
  • 可见性（公有/私有）由首字母大小写决定，而非明确的 public/private 关键字。这虽然简洁，但在重构时容易忽略，更改大小写可能在没有编译器警告的情况下破坏 API。
  • 枚举（Enum）也没有原生支持，而是通过 const 和 iota 的变通方法实现。

在作者看来，Go 似乎不惜一切代价追求简单和极简的外观，有时这意味着隐藏了复杂性，而不是真正消除了它。

真相二：多返回值并非“一等公民”

从函数返回多个值是 Go 的一个特色，尤其在错误处理上，(value, error) 模式初看很优雅，没有异常、没有 try-catch。

但视频作者指出的根本问题是：Go 中的多返回值实际上不是元组 (Tuples) 或一等公民 (First-class values)。

• 你不能将它们整体存入一个变量。
• 你不能将它们放入切片 (Slice)。
• 你不能通过通道 (Channel) 发送它们。
• 你无法用泛型 (Generics) 对它们进行抽象。

这意味着，当需要处理一系列返回 (value, error) 的结果时（例如并发执行多个操作后收集），你被迫创建一个自定义的结构体 (struct) 类型来将这些值打包在一起。作者认为，这种为了传递数据而创建额外类型的做法，正是他当年想要逃离 Java 时所厌恶的不必要的样板代码 (boilerplate code)。

真相三：错误处理极其冗长

Go 的错误处理方式，特别是 if err != nil { return …, err } 的模式，是开发者初次接触 Go 时最常见的抱怨点之一。

视频作者坦言，在 Go 中管理错误是极其冗长 (extremely verbose) 的。

• 虽然 Go 官方称之为“显式错误处理”，并由 Rob Pike 等创造者辩护其提高了可读性、保持了控制流清晰，但与其他语言（如 Rust）提供的解决方案相比，确实显得繁琐。
• 社区曾尝试改进，甚至有过添加内置 try 机制的提案，但最终因担心破坏 Go 的简洁性而被否决。

真相四：拥抱组合，但需适应思维转变

Go 的创造者们反对像 Java 那样复杂的继承体系，认为继承容易导致脆弱、混乱的代码库。因此，Go 的官方哲学是避免继承，倾向于组合 (composition)。

• Go 中的嵌入 (Embedding) 看起来有点像继承，但作者强调它完全是另一回事。
• 这种方法确实在很多方面让 Go 代码更简单、更可预测，但它意味着来自传统面向对象编程 (OOP) 语言的开发者需要调整他们的思维方式。
• Go 并非试图成为部分 OOP 语言，而是提供了一种不同的代码组织方法，用清晰性和简洁性换取了继承的部分灵活性。

真相五：泛型设计，简洁性优先于灵活性

Go 最初没有泛型，这个决定限制了语言十多年。泛型最终在 2022 年 (Go 1.18) 引入，但其设计仍然体现了 Go 简洁性优于灵活性的哲学。

• Go 不支持函数或运算符重载 (overloading)。
• 其类型约束系统虽然对许多用例足够强大，但并未提供其他语言中 traits 或 type classes 的全部表达能力。

这依然符合 Go 优先考虑清晰度和可读性，而非极致表达能力的基本理念。

结语：睁大眼睛看Go

视频作者最后总结，如果你期望 Go 能提供像具有大量语法糖的高级语言那样的开发体验，你会感到失望。

但如果你在寻找一门快速、可靠、务实、不碍事且编译飞快的语言，Go可能就是最适合你的工具。

关键在于，要“睁大眼睛去看待它 (go in with your eyes open)”。因为，仅仅通过看视频或教程喜欢上一门语言，和在维护一个有真实用户、边缘情况的真实世界项目后仍然喜欢它，这两者之间可能存在巨大的差别。理解 Go 的这些设计选择和它所带来的权衡，对于做出明智的技术决策至关重要。

希望转述的这些来自一线开发者的“硬核”观察，能帮助大家更全面地认识 Go。

你对 Go 的这些特性有什么实际体验或看法？欢迎在评论区留言讨论！

视频地址：https://www.youtube.com/watch?v=UEU4SzBjqrc

系统学习，夯实基础

想要更系统、更深入地理解 Go 语言，从基础语法、并发编程到设计哲学和工程实践，全面掌握这门高效的语言吗？欢迎订阅我在极客时间的专栏 《Go 语言第一课》。那里有更结构化的知识体系和详尽的讲解，助你打下坚实的 Go 语言基础，从容应对真实世界的挑战。

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。