本文永久链接 – https://tonybai.com/2025/09/19/the-tension-in-programmer-comments

大家好，我是Tony Bai。

做公众号/博客这些年，我收到了成千上万条来自程序员朋友的评论。绝大多数都充满了智慧、好奇和善意，正是这些交流，构成了我持续分享的最大动力。但与此同时，我也常常在评论区里，感受到一股强烈的、带有攻击性的无形之气。

比如，当我分享一篇关于Go在业务场景实践的文章时，总会有人跳出来，言简意赅地留下一句：“用Go写业务是不是很垃圾？”

又比如，当社区在探讨用Rust重构某个C++项目时，评论区可能会出现这样的“高论”：“用Rust重写C++代码，就是从一坨屎变成了另一坨屎。”

这些评论，往往脏字当头，不带任何论据，纯粹是情绪的宣泄。我思来想去，觉得用“戾气”或“喷子”来形容，似乎都不够精准。直到有一天，一个词蹦进了我的脑海——“煞气”。

这个词，源于传统文化，意指一种凶戾、非理性、具有破坏性的气场。它精准地捕捉了这类评论的本质：其目的并非交流思想，而是用情绪的冲击波，扼杀讨论，打击分享者的热情。正因如此，我之前公众号的自动精选评论和留言不得不改为手工精选，这不仅增加了工作量，还降低了评论展示的及时性。

今天，这篇文章不旨在批判，而是想和大家一起，深入地聊一聊程序员评论区里的这股“煞气”，尝试理解它从何而来，并探讨作为技术社区的一员，我们该如何面对它，如何保护我们共同的精神家园。

“煞气”的百态图鉴：你一定见过的几种典型“煞评”

这股“煞气”并非铁板一块，它以多种面目出现在我们的视野中，总有一种让你觉得似曾相识：

• “一言以蔽之”型
  这类评论堪称“断言大师”，从不屑于提供论据，仅用一句话便能给一门语言、一个框架甚至一个技术方向盖棺定论。

  • “Go就是不行。”
  • “WebAssembly没前途。”
  • “微服务就是个坑。”
    简洁，有力，不容置疑，仿佛掌握了宇宙的终极真理。

• “非黑即白”型（技术圣战）
  在他们眼中，技术选型不是基于场景和权衡，而是一场关乎信仰的“圣战”。语言、编辑器、操作系统……万物皆可站队，异端必须被消灭。

  • “用Rust重写C++就是从一坨屎变成另一坨屎。”
  • “Vim/Emacs之外皆异端！”
  • “还在用Windows/Mac开发？笑死。”

• “资格论”与“秀优越”型
  这类评论善于通过攻击对方的身份、资历或知识储备，来釜底抽薪式地否定其观点，从而建立自己的优越感。

  • “你连源码都没读过，凭什么评论？”
  • “这东西我十年前就玩过了，没什么新意。”
  • “等你写到百万行代码再来讨论架构吧。”

• “情绪投射”型
  这类评论者，往往将自己在工作中因某项技术受挫而产生的负面情绪，无差别地投射到所有相关的公开讨论中，把评论区当成了情绪的垃圾桶。

  • “我们项目刚被XXX坑惨了，这玩意儿就是个彻头彻尾的垃圾！”
  • “又在吹这门语言？我刚因为它的GC问题加了三天班！”

这些充满“煞气”的评论，像病毒一样侵蚀着技术社区的讨论氛围，让许多乐于分享的创作者心生寒意，也让许多渴望学习的新人望而却步。

溯源“煞气”：它们究竟从何而来？

要应对“煞气”，首先要理解它的来源。它并非简单的“素质问题”，背后往往有更深层次的、属于程序员群体的心理动因：

1. 高认知负荷与挫败感： 软件开发本质上是一项与复杂性搏斗的高难度、高挫败感的工作。代码不工作是常态，被需求反复折磨是日常。长期累积的压力和挫败感，需要一个宣泄的出口，而匿名的网络评论区便成了最廉价的选择。
2. 强身份认同与技术部落主义： 许多程序员倾向于将自我价值与所掌握的技术栈深度绑定。“我是Gopher”、“我是Rustacean”，这种身份认同感带来了归属感，但也催生了“部落主义”。攻击对立的技术，本质上是在捍卫自我身份和所属部落的“荣耀”。
3. 对“最优解”的执念与抽象能力的差异： 我们的工作是与逻辑打交道，追求严谨和正确，这使得许多程序员潜意识里相信存在一个放之四海而皆准的“最优解”。这种思维惯性，导致在面对需要权衡（Trade-off）的工程问题时，容易陷入“非黑即白”的二元对立，无法容忍不同场景下的不同选择。
4. 知识的诅咒： 一些资深开发者，已经忘记了自己初学时期的困惑和挣扎。他们对自己领域内“显而易见”的知识缺乏同理心，容易将新手的提问或不成熟的观点视为“愚蠢”，并报以轻蔑或不耐烦。
5. 网络匿名性的放大效应： 这是所有网络社区的通病。脱离了现实世界的社交约束，人们更容易释放出内心的攻击性。

化解“煞气”：我们每个人的社区修行

面对弥漫的“煞气”，无论是内容创作者还是普通读者，我们每个人都身处其中，既可能是受害者，也可能在不经意间成为助推者。与其抱怨环境，不如从自身做起，共同参与到社区的净化与建设中来。

给所有社区参与者的“修行建议”：

1. 评论前，区分“观点”与“情绪”： 在敲下键盘前，花一秒钟审视内心：我即将表达的，是基于逻辑和事实的技术观点，还是仅仅是想吐槽一下今天遇到的某个Bug或者糟糕的心情？有意识地分离这两者，是理性讨论的第一步。
2. 拥抱“建设性批评”的艺术： 如果你不同意某个观点，这非常正常，甚至是技术进步的源泉。但请尝试用建设性的方式来表达：
   • 提供论据： “我认为这个方案有风险，因为在XX场景下，它可能会导致YY问题。”
   • 提供替代方案： “相比A方案，我更推荐B方案，因为B在处理XX方面更有优势。”
   • 补充上下文： “这个观点在小型项目中可能适用，但在大规模分布式系统中，我们需要额外考虑……”
     这样的评论，远比一句简单的“你这是垃圾”有价值千万倍。
3. 常怀谦逊与同理心： 技术世界浩瀚无垠，我们每个人都只是其中渺小的一粟。承认自己知识的局限性，尊重不同技术在不同场景下的存在价值。我们今天所不屑的，可能正是我们昨天所困惑的；我们今天所熟稔的，可能是别人明天将要探索的新大陆。多一份同理心，少一份优越感。

小结：化“煞气”为“祥和之气”，共建更有价值的技术社区

回到开头的那些评论。Go写业务当然不是垃圾，Rust重写C++也绝非原地踏步。每一种技术选择背后，都有其复杂的工程背景和权衡考量。一个健康的技术社区，应该是一个能够容纳并理性探讨这些权衡的地方。

我们探讨“程序员的‘煞气’”，目标不是消灭所有反对的声音，健康的质疑和辩论是技术进步的基石。我们的目标，是希望将那些无意义的、纯粹消耗热情的情绪宣泄，转化为能够推动我们共同进步的思想碰撞。

这需要我们每一位社区参与者的共同努力：分享者多一份对人性的理解和对经验的珍视，评论者多一份理性和建设性的态度。

愿我们都能成为驱散“煞气”的光，让技术社区的每一次讨论，都离智慧更近一步。

想系统学习Go，构建扎实的知识体系？

我的新书《Go语言第一课》是你的首选。源自2.4万人好评的极客时间专栏，内容全面升级，同步至Go 1.24。首发期有专属五折优惠，不到40元即可入手，扫码即可拥有这本300页的Go语言入门宝典，即刻开启你的Go语言高效学习之旅！

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

本文永久链接 – https://tonybai.com/2025/09/13/package-managers-are-evil

大家好，我是Tony Bai。

“包管理器是万恶之源 (Package Managers are Evil)。”

这句石破天惊的论断，出自Odin语言的创造者Ginger Bill最近发表的一篇博文。在一个npm install、pip install、go get已经成为开发者肌肉记忆的时代，这无异于一篇挑战整个现代软件开发基石的“檄文”。

对于我们这些深度依赖go mod的Gopher来说，这无疑也是一次直击灵魂的拷问。我们早已习惯了Go Modules带来的便利——它解决了版本锁定、依赖传递和可复现构建等核心问题，被公认为Go生态走向成熟的里程碑。但我们是否在享受便利的同时，也正在“自动化我们的依赖地狱”？

Ginger Bill的这篇文章并非无的放矢的抱怨，而是一次对开发者文化、信任模型和软件工程第一性原理的深刻反思。让我们直面这次拷问，并以此为镜，重新审视我们与go mod的关系。

核心论点：包管理器是“依赖地狱的自动化”

首先，Ginger Bill做了一个关键的区分，他的矛头并非指向：

• 包（Packages）: 代码组织单元。
• 仓库（Repositories）: 发现和存储包的地方（如GitHub）。
• 构建系统（Build Systems）: 编译和链接代码的工具。

他精准地将炮火对准了包管理器（Package Managers）的核心功能：自动化地下载、解析和处理依赖关系。

他认为，这正是问题的根源所在。“依赖地狱”（Dependency Hell）是一个真实存在的、困扰着所有大型项目的难题——成千上万个你并不真正了解的传递依赖，版本冲突、潛在的bug、未知的安全漏洞，共同构成了一个巨大的泥潭。

而包管理器的作用，就是“将这个通往地狱的过程自动化了”。

他辛辣地指出：“不是所有能被自动化的东西，都应该被自动化，尤其是依赖地狱。”

他的核心观点是，npm install或go get这种一键式的便利，剥夺了开发者一个至关重要的环节：思考。

“当你必须手动下载和集成一个库时，你会开始思考：‘我也许并不需要这个’，或者‘我可以用别的方式来实现’。当需要更新时，手动操作会迫使你变得非常小心。”

这种被刻意放慢的、充满“摩擦力”的过程，迫使开发者去审视每一个引入的依赖，将其视为一个严肃的决策，而不是一次随意的命令行敲击。

Go的悖论：一个“幸免于难”的生态？

有趣的是，在Ginger Bill的批判中，Go被作为一个相对正面的例子提及。他观察到，即便Go拥有一个内置的包管理器，但大多数Go开发者似乎并不需要引入大量的第三方包。

“通往地狱的入口似乎又远又难走。”

为什么Go生态在一定程度上抵御了其他生态（如JavaScript）中那种失控的依赖爆炸？答案在于Go语言的设计哲学：“自带电池”（Batteries Included）。

Go拥有一个极其强大和全面的标准库。你想构建一个高性能的Web服务器？net/http就在那里。你需要处理JSON、加密、模板或者并发？标准库为你提供了一流的、经过实战检验的工具。你甚至可以在标准库里找到一个完整的Go编译器。

这种设计极大地降低了对外部微小、功能单一的“工具包”的依赖。当标准库就能满足80%的需求时，开发者自然不会像在其他生态中那样，为了实现一个最基本的功能（比如left-pad）就去引入一个外部依赖。

然而，这并不意味着Go开发者可以高枕无忧。go mod依然是一个强大的自动化工具，当我们开始引入大型框架（如Gin、GORM）或复杂的SDK时，我们同样面临着瞬间引入数十甚至上百个传递依赖的风险。

每一个依赖，都是你签下的一份“责任状”

文章中最深刻的观点之一，是对“依赖”一词含义的重新诠释。

“在现实生活中，当你有一个依赖时，你要对它负责。如果你的孩子或你的公司做错了事，你可能会因此进监狱。包依赖与此相去不远，但人们却在几乎没有任何验证的情况下就信任了它们。”

每一个go get下来的包，都是一份你自愿承担的负债。你不仅要为它的安全漏洞负责，还要为它的bug、为它未来可能停止维护的风险负责。

作者以他自己使用著名C库SDL2的痛苦经历为例。尽管SDL2被数百万人使用，但他的团队却不断踩到其中的bug，最终决定自己从头编写窗口和输入处理系统。“至少这是我们自己的代码，当出问题时我们可以依赖和修复它。”

“我不是在提倡一切都从头造轮子，” 作者澄清道，“我只是希望我们能认识到，每一个依赖都是一份负债。”

文化反思：程序员世界里的“盖尔曼遗忘效应”

为什么我们会如此轻易地信任来自互联网的随机代码？文章引用了ThePrimeagen的一个精彩论点：编程界的“盖尔曼遗忘效应”（Gell-Mann Amnesia Effect）。

这个效应描述了一种现象：当你在报纸上读到一篇关于你所精通领域的文章时（比如马术），你会发现其中充满了错误和误解。然后，你翻到下一页，读到一篇关于你不了解的领域（比如JavaScript）的文章，你又会理所当然地认为它是完全正确的。你瞬间忘记了刚刚才亲身验证过的、媒体的不可靠性。

程序员也存在同样的问题：

“你会发现工程师们一边说‘我的一些同事太可怕了’，一边又说‘嘿，让我从网上下载这个库，这肯定很棒’。他们看着自己公司三分之一的员工无法写出像样的代码，同时又选择信任他们下载的每一个开源包。”

我们对自己身边代码的质量持怀疑态度，却对那些由“开源大神”（他们可能和我们糟糕的同事是同一水平）编写的代码抱有不切实际的、过高的信任。

小结：给Gopher的启示——如何与go mod共存？

Ginger Bill的结论是激进的：如果可能，应该避免使用包管理器。对于大多数在团队中工作的Go开发者来说，这显然是不现实的。go mod是Go生态协作的基石，我们不可能回到手动管理依赖的蛮荒时代。

然而，这篇文章的价值不在于它的结论，而在于它提出的哲学框架。它像一面镜子，让我们反思我们与go mod的关系。我们可以从中提炼出几条适用于Gopher的行动指南：

1. 将go get视为一个严肃的架构决策：在引入任何新的依赖之前，进行尽职调查。检查它的代码质量、社区活跃度、issue列表和维护状态，虽然这会给你带来不小的额外工作量。
2. 永远优先选择标准库：在寻求外部解决方案之前，先问自己：“这个问题，std库里真的没有解决方案吗？” 往往答案是有的，只是需要你多花一点时间去挖掘。
3. 适当优先地拥抱代码生成，而非黑盒框架：在某些场景下，使用代码生成工具（如sqlc）可能比引入一个庞大的ORM框架（它会带来一整套复杂的依赖和抽象）更“简单”，因为它产出的是你可以直接阅读和控制的代码。
4. 定期审计你的依赖树：使用go mod graph和go list -m all来审视你的项目究竟依赖了什么。对于那些不再需要，或者有更好替代品的依赖，要勇于清理。别忘了Go Proverbs中的那一条：A little copying is better than a little dependency。

Go的“自带电池”哲学给了我们一个得天独厚的优势，让我们能更容易地践行“少即是多”的依赖管理原则。最好的包管理器，或许就是那个你用得最少的。 而go mod的真正强大之处，可能不在于它能多么轻易地帮我们添加依赖，而在于它通过一个强大的标准库，让我们在很多时候，根本无需想起它。

想系统学习Go，构建扎实的知识体系？

我的新书《Go语言第一课》是你的首选。源自2.4万人好评的极客时间专栏，内容全面升级，同步至Go 1.24。首发期有专属五折优惠，不到40元即可入手，扫码即可拥有这本300页的Go语言入门宝典，即刻开启你的Go语言高效学习之旅！

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