我知道package-lock.json的主要优点，我同意这一点。它不仅在上次安装中锁定下载的版本，还锁定了 uri...在大多数情况下，这是可以复制最相似的项目所必需的。
但是对我来说似乎很奇怪的一件事是，package.json具有声明依赖项的功能，例如dependency: ^1.0.0，这应该使 npm 在每个安装中下载该包的最新和兼容版本。
我正在从事一个我真正需要这个的项目。否则，每次我的依赖项发布补丁时，都需要进行新的提交更新，package.json仅更改版本，因此我的管道也可以覆盖package-lock.json。
简而言之，似乎虽然package.json使用了一个功能......package-lock.json防止了那个。
我错过了什么吗？
package-lock.json的重点是准确地表示树在某个时间点实际存在的树，以便克隆项目的人得到与您完全相同的树。
如果要将该依赖项升级到较新版本，只需使用npm update，然后提交更新的package-lock.json。团队的其他成员将获得该更新，作为获取最新信息的正常过程的一部分。
有关包锁的 npmjs.com 页面中的更多信息。
让我们考虑一下你和我在一个团队中，我们的项目使用nifty-lib，package.json说"nifty-lib": "^0.4.0"，我们不分享package-lock.json。也许我在这个项目上工作的时间比你长了几个月，当我安装它时，我得到了nifty-libv0.4.0。但是当你拿起它并安装它时，你得到了v0.4.1(一个错误修复更新，可悲的是，引入了一个新的错误)。在某些时候，您会注意到我们项目中似乎存在错误，但我无法复制它。我们在原地旋转了一会儿，试图弄清楚为什么它发生在你身上而不是发生在我身上。最后，我们意识到这是因为这实际上是他们在 v0.4.1 中引入的nifty-lib中的一个错误。希望我们随后得到 0.4.2 或其他东西(或者如果没有，我们修复错误并进行 PR，同时在整个项目中回滚到 0.4.0)。
如果我们一直分享package-lock.json，我们就不会在原地旋转，想知道为什么问题发生在你身上而不是发生在我身上，因为你会和我有相同版本的nifty-lib。作为正常周期的一部分，我们会定期执行npm update，如果测试中出现新的错误，我们会从提交历史记录中知道这是因为依赖项中的错误。
现在，将"我"和"你"改为"开发"和"生产"。
这就是为什么package-lock.json锁定版本，但package.json让您说"这个或更好"。package-lock.json使您的团队在版本上保持一致，但您可以有意使用npm update进行更新，这会显示在提交历史记录中，以便您可以跟踪它的回归。
正如我在上面的评论中提到的，简短的回答是它使update依赖项更容易。
但是，我喜欢考虑这两个文件的另一种方式是：package.json是人类读取的文件，而package-lock.json是计算机读取的文件。
NPM 是一个包/依赖管理器。因此，在您的package.json文件中，您写出"我的库需要这些库才能工作"。作为一项功能，您可以列出依赖项的一系列版本。当您在特定包上运行npm update时，这会有所帮助。它将查看与您的 *package.json** 匹配的最新版本是什么，并更新您的锁定文件。
package-lock.json锁定文件很有用，因为它详细描述了您的node_modules/文件夹的外观，因此当其他人安装您的库时可以准确地重新创建它。此外，由于此文件是自动生成的，因此您不必担心维护它。
当然，所有这些恰好是NPM(以及相反的大多数包管理器)处理这个问题的方式。也就是说，没有技术原因说明为什么我们不能有一个文件来描述运行更新时允许的版本范围，以及固定版本以允许可重新创建的依赖树的详细锁文件部分。
基本上，这只是一种便利。您有一个文件可以简洁地列出项目所需的依赖项。它是可读的，易于更新。另一个文件，即锁定文件，是自动生成的，并确保每个npm install为您提供与以前完全相同的node_modules/文件夹。