它存储一个精确的、有版本控制的依赖树，而不是像package那样使用星号版本控制。Json本身(例如1.0.*)。这意味着您可以保证对其他开发人员或产品版本的依赖关系等等。它也有一个锁定树的机制，但通常会重新生成如果包。json的变化。

来自npm文档:

package-lock.json is automatically generated for any operations where npm modifies either the node_modules tree, or package.json. It describes the exact tree that was generated, such that subsequent installs are able to generate identical trees, regardless of intermediate dependency updates. This file is intended to be committed into source repositories, and serves various purposes: Describe a single representation of a dependency tree such that teammates, deployments, and continuous integration are guaranteed to install exactly the same dependencies. Provide a facility for users to "time-travel" to previous states of node_modules without having to commit the directory itself. To facilitate greater visibility of tree changes through readable source control diffs. And optimize the installation process by allowing npm to skip repeated metadata resolutions for previously-installed packages."

Edit

To answer jrahhali's question below about just using the package.json with exact version numbers. Bear in mind that your package.json contains only your direct dependencies, not the dependencies of your dependencies (sometimes called nested dependencies). This means with the standard package.json you can't control the versions of those nested dependencies, referencing them directly or as peer dependencies won't help as you also don't control the version tolerance that your direct dependencies define for these nested dependencies.

即使你锁定了你直接依赖的版本，你也不能100%保证你的整个依赖树每次都是相同的。其次，你可能想要允许直接依赖的非破坏性更改(基于语义版本控制)，这让你对嵌套依赖的控制更少，而且你不能保证你的直接依赖不会在某些时候破坏语义版本规则本身。

所有这些问题的解决方案是锁文件，如上所述，锁在完整依赖树的版本中。这允许你为其他开发人员或发行版本保证你的依赖树，同时仍然允许使用你的标准package.json测试新的依赖版本(直接或间接)。

NB。之前的npm-shrinkwrap。Json做了几乎相同的事情，但锁文件重命名它，以便它的功能更清楚。如果项目中已经有收缩包装文件，则将使用此文件而不是任何锁定文件。

这是npm的一个非常重要的改进:保证每个包的版本完全相同。

如何确保在不同的时间、不同的环境中使用相同的包构建项目?比方说，您可以在包中使用^1.2.3。Json，或者你的一些依赖项正在使用这种方式，但是你如何确保每次NPM安装都在你的开发机器和构建服务器中获得相同的版本呢?package-lock。Json将确保这一点。

NPM install会重新生成锁文件。 在构建服务器或部署服务器上，执行npm ci (它将从锁文件中读取，并安装整个包树)

package-lock。当package.json中的一个属性(如“version”属性)中的数值或依赖属性被更改时，Json将被写入。

如果这些数值在包装中。Json和包锁。Json匹配，包锁。Json被读取。

如果这些数值在包装中。Json和包锁。Json不匹配，包锁定。Json被写入这些新值，以及新的修饰符，如插入号和波浪号(如果它们存在的话)。但是正是这个数字触发了对package-lock.json的更改。

要明白我的意思，请执行以下操作。使用包。不带包锁的Json。运行NPM install，使用:

{
  "name": "test",
  "version": "1.0.0",
  ...
  "devDependencies": {
    "sinon": "7.2.2"
  }
}

package-lock。Json现在有:

"sinon": {
  "version": "7.2.2",

现在复制/粘贴两个文件到一个新目录。改变计划。Json到(只添加插入符号):

{
  "name": "test",
  "version": "1.0.0",
  ...
  "devDependencies": {
    "sinon": "^7.2.2"
  }
}

运行NPM install。如果没有包裹锁。Json文件，sinon@7.3.0将被安装。NPM install正在从package-lock读取。Json和安装7.2.2。

现在换包。json:

{
  "name": "test",
  "version": "1.0.0",
  ...
  "devDependencies": {
    "sinon": "^7.3.0"
  }
}

运行NPM install。package-lock。Json已经被写入，现在将显示:

"sinon": {
  "version": "^7.3.0",

还有一件重要的事情需要提及，那就是包锁文件带来的安全性改进。因为它保存了所有包的哈希值，如果有人篡改了公共npm注册表，甚至没有改变包本身的版本就改变了包的源代码，包锁文件就会检测到。

npm会自动创建这个文件，并使用它来跟踪你的包安装情况 并且更好地管理项目依赖项的状态和历史。你 不应该改变这个文件的内容。

package-lock。json:它包含应用程序当前安装的确切版本细节。

包锁的目标。Json文件是为了跟踪安装的每个包的确切版本，以便即使包由其维护者更新，产品也可以100%以相同的方式再现。

这解决了一个非常具体的问题。jsonleft没有解决。在包中。Json，你可以设置你想升级到哪个版本(补丁或小)，使用semver符号。

包中。json文件包含你安装的包和库的主要名称，你可以编辑它，但是Package-lock。json包含每个包的详细信息和每个包的存储库链接(考虑它是来自package.json的包的详细信息)引用

https://web-brackets.com/discussion/69/what-is-the-use-of-package-lock-json-file