刚接手一个新项目时，最怕什么？不是复杂的业务逻辑，也不是晦涩的命名，而是运行不起来。明明代码都拉下来了，执行 npm install 或者 go mod tidy 却一堆报错。这时候问题往往出在依赖上——缺少某个包、版本对不上、甚至远程仓库被删了。这些看似琐碎的问题，背后其实是源码依赖管理的锅。
从“能跑就行”到“稳定可复现”
早期写个人项目，很多人习惯直接引入最新版依赖。比如前端随手装个 axios@latest，后端直接 import requests 就用。项目小的时候没问题，但一旦多人协作或部署到不同环境，就会发现同事的机器上跑得好好的，在 CI 上却构建失败。
根源在于没有锁定依赖版本。现代包管理工具像 npm、yarn、pip、Maven 都支持生成锁定文件，比如 package-lock.json、yarn.lock、poetry.lock。这些文件记录了确切的依赖树和版本哈希，确保每个人安装的依赖完全一致。
{
"name": "my-app",
"version": "1.0.0",
"dependencies": {
"lodash": "4.17.21"
},
"lockfileVersion": 2
}
// yarn.lock 中会精确记录 lodash@4.17.21 来自哪个 registry，hash 值是多少私有依赖与镜像策略
公司内部常有多个项目共享一套工具库的情况。把这些工具打成私有包，通过私有 NPM 或 PyPI 仓库发布，是常见做法。但这又带来新问题：如果私有仓库临时不可用，整个构建流程就卡住了。
一种解决思路是使用依赖代理镜像。比如搭建 Nexus 或 Verdaccio，既缓存公共包，也托管私有包。即使外网 registry 出问题，局域网内的镜像还能顶一阵子。另一种方式是将关键依赖打包进 vendor 目录，像 Go 的 vendor 文件夹或 Python 的 ./libs，虽然体积变大，但换来了更高的可移植性。
扁平化 vs 嵌套：依赖结构的取舍
npm 最早采用嵌套结构，每个包独立安装自己的依赖，导致 node_modules 层层叠叠，磁盘占用大。后来改为扁平化策略，尽量把依赖提到顶层，减少重复。但这也可能引发冲突——比如两个包分别依赖不同版本的 moment，强行提权可能导致其中一个出问题。
这时候需要人工干预，要么升级兼容版本，要么利用别名机制。yarn 支持在 package.json 中这样写：
"resolutions": {
"**/moment": "2.30.0"
}强制所有嵌套里的 moment 都用指定版本，避免不兼容。
定期清理过期依赖
项目做着做着，总会有人加一堆当时要用的库，后来功能改了也没删。时间一长，requirements.txt 里塞满了没人记得用途的包。这不仅增加攻击面，还拖慢安装速度。
建议定期用工具扫描无用依赖。JavaScript 可用 depcheck，Python 推荐 pipreqs 结合手动核对。删掉不用的，再重新生成锁定文件，保持依赖清单干净。
源码依赖管理不像架构设计那样引人注目，但它决定了项目能不能顺利启动、能不能稳定发布。一个可靠的依赖体系，能让新人第一天就能跑起项目，也让线上部署少几分忐忑。