它存储一个精确的、版本化的依赖树，而不是像package.json它本身那样使用星号版本（例如
1.0.*）。这意味着您可以保证其他开发人员或产品版本等的依赖关系。它还具有锁定树的机制，但通常会在package.json更改时重新生成。
从npm 文档：
对于 npm 修改 node_modules 树或 package.json 的任何操作，都会自动生成 package-
lock.json。它描述了生成的确切树，以便后续安装能够生成相同的树，而不管中间依赖项更新如何。
该文件旨在提交到源存储库中，并用于各种目的：
描述依赖关系树的单一表示，以保证团队成员、部署和持续集成安装完全相同的依赖关系。
为用户提供“时间旅行”到 node_modules 先前状态的工具，而无需提交目录本身。
通过可读的源代码控制差异来促进对树更改的更大可见性。
并通过允许 npm 跳过以前安装的包的重复元数据解析来优化安装过程。”
关于仅使用package.json具有确切版本号的问题。请记住，您package.json只包含您的直接依赖项，而不是您的依赖项的依赖项（有时称为嵌套依赖项）。这意味着使用标准package.json您无法控制这些嵌套依赖项的版本，直接引用它们或作为对等依赖项将无济于事，因为您也无法控制直接依赖项为这些嵌套依赖项定义的版本容差。
即使您锁定了直接依赖项的版本，您也不能 100%
保证您的完整依赖项树每次都是相同的。其次，您可能希望允许对直接依赖项进行非破坏性更改（基于语义版本控制），这使您对嵌套依赖项的控制更少，而且您再次不能保证您的直接依赖项在某些时候不会破坏语义版本控制规则他们自己。
所有这一切的解决方案是锁定文件，如上所述，它锁定完整依赖树的版本。这允许您为其他开发人员或版本保证您的依赖树，同时仍然允许使用您的标准测试新的依赖版本（直接或间接）package.json。
注意。前一个npm-shrinkwrap.json做了几乎相同的事情，但锁定文件重命名它，使其功能更清晰。如果项目中已经有一个收缩包装文件，那么将使用它而不是任何锁定文件。