Node.js 项目之所以容易“今天能跑，明天失灵”，很多时候不是业务代码问题，而是依赖边界没有管好。package.json、版本范围、锁文件、开发依赖和生产依赖这些看起来基础的东西，实际决定了项目能不能稳定协作。
package.json 为什么不只是依赖清单？
很多人第一次接触 package.json 时，只把它当成“项目里装了哪些包”的地方。但更准确地说，它其实是 Node 项目的核心契约文件之一。这里不只记录依赖，还会影响：
- 脚本入口；
- 模块类型；
- 发布信息；
- 包管理器约定；
- 项目基础元数据。
也就是说，package.json 不是“顺手配一配”的文件，而是项目和工具链之间沟通的重要接口。
版本范围为什么会带来协作风险？
Node 生态里非常常见的一个现象是：依赖写着写着就从精确版本变成了带范围的版本号，比如 ^、~ 之类。这样做不是错，但它代表着不同程度的升级空间。
问题在于，一旦允许自动浮动升级，就意味着：
- 不同时间安装出来的依赖树可能不同；
- 本地和 CI 如果没有锁文件保护，结果也可能不同；
- 某个看似无害的小版本升级，也可能在边界场景里改变行为。
所以，版本范围本质上不是语法细节，而是风险管理策略。你要清楚自己是在追求更灵活的跟进，还是更稳定的复现。
lockfile 为什么必须认真对待？
锁文件的价值，简单说就是“把当前这一套可运行依赖树固定下来”。它让团队协作从“理论上依赖这些包”变成“实际就安装这一组版本组合”。
这对 Node 项目尤其重要，因为它的依赖树往往很深。你直接依赖的包也许只有几个，但它们背后还会继续拉很多层间接依赖。如果没有锁文件，今天装出来和下周装出来，细节可能完全不同。
所以，一个非常基本但又经常被忽略的原则是：锁文件不是可选附属物，而是工程稳定性的基础组成部分。
依赖边界为什么要分层？
只要项目开始变复杂，你就不能把所有包都平铺看待。最起码，你应该知道：
- 哪些包是运行时真正需要的；
- 哪些包只服务于开发和构建；
- 哪些包是测试、Lint、格式化之类的辅助工具；
- 哪些依赖是可选或环境相关的。
这件事之所以重要，是因为“依赖是什么”决定了它应该在什么场景存在、由谁感知、出问题时影响哪一层。没有边界的依赖管理，最终通常会演变成升级困难、环境膨胀和问题难排。
总结
这一篇把 Node.js 工程实践最基础的一层地基铺起来了：package.json 是项目契约，版本范围意味着升级策略，锁文件决定依赖是否可复现，而依赖分层则决定项目边界是否清晰。
下一篇我们会继续看另一个经常被低估的基础设施，也就是 npm scripts 如何成为团队协作入口。