依赖管理的两条底线：锁版本与定期清账

项目引入一个组件只需要一行声明，但它会一直留在那里。很多团队在某个时刻突然发现，构建需要五分钟、升级任一个包都要改一片代码、没人能说清某个组件到底用在哪。这不是选择错了某个组件，而是缺少两项常规动作。

第一项是版本锁定。声明范围与实际解析结果不是一回事。只用范围表述而不保存解析结果，会让同一份代码在不同时间、不同机器上得到不同的依赖集合，故障难以复现。锁定文件的价值就在于把某一次成功解析的具体版本固定下来，让人与机器得到同一份答案。

但锁定不等于永远不动。锁定的依赖不会自动获得安全修复，需要定期做一次受控更新：先只更新小版本，跑完整验证；再按季度评估大版本升级。把升级作为固定动作而不是等到出问题才做，成本会低很多，也更可预测。

第二项是依赖清账。每季度做一次盘点，把每个依赖标成三种状态之一：核心使用、间接需要、可以移除。第三种最容易积累——功能改过之后原依赖不再被调用，但声明还留着，风险面与构建时间同时增加。移除的过程要跑一遍完整验证，避免误删间接依赖。

还有一项经验值得记下：把依赖数量当作指标看。从三十个涨到一百二十个项目，出问题的概率不只是线性增长，冲突组合与升级路径复杂度上升更快。当数字越过了团队能讲清来源的范围，选择新组件时就应该更倾向于用已有能力替代，而不是新增一个。