在当今软件开发的复杂生态中，选择合适的依赖库是提升开发效率和软件质量的关键。然而，依赖并非象征着零成本的“免费功能”。许多开发者往往因为“节约时间”或者“重复造轮子”的恐惧而引入大量第三方依赖，却忽视了这些依赖背后的隐性成本。正如标题所言，NIH（不自己造轮子，Not Invented Here）原则远远比错误选择依赖的成本低得多。本文将深入分析依赖的实际成本、如何科学评估依赖以及避免陷入错误依赖的陷阱，使开发者能够做出明智的选择，从而节省时间、降低风险、提升项目稳定性与可维护性。首先，我们需要厘清依赖的真正含义。
依赖往往被看作节省开发时间的捷径，尤其是开源库和工具层出不穷，各类解决方案几乎能满足任何功能需求。但实际上，引入依赖意味着必须花费额外时间去学习、适配甚至维护这些外部代码。部分依赖庞大复杂，学习成本高于自身编写相同功能。此外，依赖版本的频繁更新和破坏性改动可能迫使开发团队不得不大幅重构自身代码，增加了技术债务的风险。部署和运行依赖的客户端环境也面临挑战。复杂的容器化或者打包工具链就源于需要保障依赖的环境一致性。
许多时候，开发者为了避免造轮子，反而制造了一个复杂的“依赖轮子”，并非本质上节省时间，而是将工作量转嫁到部署和运维环节。举例来说，金融数据库TigerBeetle采用了零依赖策略，仅依赖Zig工具链，将依赖风险降到最低。零依赖的设计理念不仅避免了供应链攻击的威胁，还大幅提升了性能和安全性，使得系统基础设施更加稳定和可靠。这揭示了核心系统在选择依赖时的苛刻标准：任何外部依赖的成本会在底层架构中不断放大，增加整体系统的不确定性和复杂度。工具选择上，TigerBeetle团队倾向于依赖小而标准化的工具箱，如Zig语言。虽然Zig可能不是适合所有场景的最佳选择，但它的简洁和一致性大幅降低了开发环境的复杂度，使团队能够专注于真正的问题解决，而非被各类复杂第三方工具拉扯。
那么如何科学评估一个依赖的价值呢？一个完善的框架需要考量五个方面的指标：普及性、稳定性、功能深度、易用性以及封装完整度。普及性衡量依赖是否广泛支持并在目标环境中预装，以避免部署的额外复杂性。稳定性关注依赖的破坏性改动的频率，频繁的API变动会极大影响维护成本。功能深度评估依赖替代方案的可行性及开发难度，功能越复杂，自己实现的代价越高。易用性关注依赖接口是否人性化、易于使用，是否减少开发者认知负担。封装完整度检验依赖的抽象是否“漏水”，即是否经常需要开发者关注底层实现细节，从而增加调试和维护难度。
遗憾的是，市场中许多依赖推广者往往只强调易用性，忽略了其他关键指标，导致开发者在实际使用中遭遇种种隐患。值得推荐的依赖类型包括POSIX系统调用、ECMA-48终端控制代码以及Web平台标准。POSIX调用稳定且功能深度巨大，几乎涵盖了所有主流类Unix系统的文件和进程操作。ECMA-48标准在绝大多数终端模拟器中得到默认支持且历史悠久，替代方案难以想象。Web平台标准凭借其极高的普及率和兼容性，成为现代前端开发无可替代的基础。这些依赖拥有极高的稳定性和普及率，成为开发中“合格的依赖”。
反观一些质量未知、更新频繁、生态不成熟的依赖库，容易引发安全隐患和维护地狱，实际成本远高于自行开发实现。考虑到依赖带来的风险，开发团队应系统化评估依赖代价，警惕“便利陷阱”。并非所有功能模块都需要依赖第三方库，适度“自己造轮子”，尤其是对于功能简单、业务关键度高的模块，往往更可靠且安全。更重要的是，整体开发文化应该倡导清晰透明的依赖管理流程，定期审查和淘汰不必要或危害性能稳定的依赖。这样能保障项目健康发展，避免因依赖版本失控或供应链攻击而造成重大损失。在复杂的现代软件系统中，没有绝对完美的依赖。
NIH原则并非否定所有依赖，而是提醒开发者理性思考：选择依赖应建立在充分权衡的基础上。错误的依赖成本会随着项目规模和生命周期不断放大，远远超过节省的开发时间。最终，合理的依赖管理将帮助团队实现高效开发、安全运行和长期可维护的目标。总结来看，依赖的真实成本不仅体现在初期的导入和学习上，更在于长期的维护、安全和部署。采用零依赖或极简依赖策略的例子说明，节省短期成本的依赖往往引发更多连锁反应。构建自己专属的、轻量且标准化的工具链和代码库，结合科学的依赖评估框架，是软件工程健康发展的必然选择。
只有通过持续评估和优化依赖，才能在复杂的软件环境中保持竞争力，避免被不合适依赖绑架，真正实现“NIH远比错误依赖更经济”的战略思想。
