这篇帖子围绕“是否应该持续更新第三方依赖”展开，争论焦点是安全性、稳定性和维护成本。评论里频繁提到 lockfile、版本 pinning、CI/CD、CVE，以及 npm（Node.js 的包管理器）和 pip（Python 的包管理器）等生态。很多人把问题放到供应链安全上，尤其是依赖包可能被投毒、更新通道可能被劫持，像 xz/ssh 供应链事件就是典型案例。也有人从运维流程角度补充说，真正可行的是分层更新、内部缓存和 QA 测试，而不是盲目追新或彻底不更新。
一部分评论认为，比较稳妥的做法是让依赖保持未固定状态，但通过 lockfile 锁住最终解析结果，并且一年只更新几次。这样既能避免长期不更新导致版本过旧，又能减少每次 CI 运行都暴露在供应链攻击窗口里的次数。另一部分评论则更激进，主张把依赖和 lockfile 都完全 pin 住，连 "^"、"*" 这类自动浮动版本符号也去掉，改成完全可预测的固定版本。有人反驳说所谓“行业标准”在现实中并不常见，更多像是经验判断而不是普遍实践。
有评论直接把这篇文章看成 startup sales pitch，认为它先把整个生态描述成一团糟，再推销一个复杂的 CI 工具链来审查依赖更新。质疑点在于：如果依赖代码本身都没人审过，那么用新工具再审一遍更新补丁，真的能解决根本问题吗。还有人指出，文章前半段其实讲的是常识性的安全做法，后半段却突然转向“用我们的新工具”，这种转折显得很可疑。相对地，评论者更认可传统安全做法：固定版本和 SHA、使用 artifact repository、做 cryptographic verification、尽量减少依赖并审查来源与签名。
另一些评论没有停留在“更不更新”的二元对立，而是讨论实际发布流程怎么安排。建议是：不要直接从互联网拉包，而是维护本地缓存；开发环境可以跟着包仓库较频繁更新，QA 按团队节奏测试，生产环境则跟下一次正式发布走，最好不要频繁于 90 天一次。这个思路把更新看成一条从 dev 到 prod 的流水线，而不是每次依赖有新版本就立刻升级。评论者还把它和 CVE 的公开披露节奏联系起来，认为测试和修复本来就需要时间，盲目追新反而更容易把 bug 带进生产。
有评论强调，这场争论更多是在讲 web dev，而不是一般意义上的 software development，尤其是 npm（Node.js 的包管理器）和 pip（Python 的包管理器）这类生态。有人拿 phpMyAdmin（MySQL 的 Web 管理工具）直接暴露公网的例子来讽刺：如果还开着公开端口，却不走 SSH tunneling（通过 SSH 转发端口的方式），那安全策略本身就有问题。另一条线索则把问题放到历史演进上：过去开发者更重视 API backward compatibility，而现在依赖树和 BOM（Bill of Materials，依赖清单）太复杂，兼容性维护成本暴涨。评论还提到 xz/ssh 供应链事件，作为现代软件生态复杂且易被投毒的现实案例。
lockfile: 依赖解析结果的锁定文件，用来固定实际安装到的版本，提升构建可重复性。
pinning: 把包版本或哈希固定到具体值，避免自动升级带来的不可预测变化。
supply chain attack: 攻击者通过依赖包、更新通道或构建流程投毒，间接入侵下游项目。
BOM（Bill of Materials）: 依赖清单或物料清单；在软件里常指项目所依赖的组件树，越复杂越难维护。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。