随着npm@5 的发布，它现在将写入 a package-lock.json，除非 anpm-shrinkwrap.json已经存在。
我通过以下方式全局安装了 npm@5：
npm install npm@5 -g
现在，如果npm-shrinkwrap.json在以下期间找到 a：
npm install
将打印警告：
npm WARN read-shrinkwrap This version of npm
is compatible with lockfileVersion@1,
but npm-shrinkwrap.json was generated for lockfileVersion@0.
I'll try to do my best with it!
所以我的结论是我应该用package-lock.json.
然而，为什么它有一种新的格式呢？能做什么不能package-lock.json做什么npm-shrinkwrap.json？
这些文件具有完全相同的内容，但 npm 处理它们的方式存在一些差异，其中大部分在package-lock.json和npm- shrinkwrap.json 的文档页面上都有说明：
package-lock.json永远不会发布到 npm，而npm-shrinkwrap默认情况下是package-lock.json不在顶级包中的文件被忽略，但属于依赖项的收缩包装文件被尊重npm-shrinkwrap.json向后兼容 npm 版本 2、3 和 4，而package-lock.json仅被 npm 5+ 识别您可以通过运行将现有转换package-lock.json为.npm-shrinkwrap.jsonnpm shrinkwrap
因此：
如果您不将包发布到 npm，则在这两个文件之间进行选择几乎没有影响。您可能希望使用package-lock.json它，因为它是默认的，并且它的名称对 npm 初学者来说更清楚；npm-shrinkwrap.json或者，如果您难以确保开发团队中的每个人都使用 npm 5+ ，您可能希望使用与 npm 2-4 的向后兼容性。（请注意，npm 5 于 2017 年 5 月 25 日发布；从那个日期开始，向后兼容性将变得越来越不重要，因为大多数人最终都会升级。）
如果您将包发布到 npm，您可以选择：
package-lock.json准确记录您安装了哪些版本的依赖项，但允许安装您的包的人使用与您指定的版本范围兼容的任何版本的依赖项package.json，或者npm-shrinkwrap.json来保证安装你的包的每个人都得到完全相同版本的所有依赖项
文档中描述的官方观点是选项 1 应该用于库（大概是为了减少当包的许多依赖项都依赖于相同辅助依赖项的略有不同版本时引起的包重复量），但是该选项2 对于将要全局安装的可执行文件可能是合理的。
这个想法绝对是让 package-lock.json 成为收缩包装技术中最新和最伟大的，而 npm-shrinkwrap.json 是为那些非常关心他们的库是否具有精确 node_modules 的宝贵少数人保留的——和对于希望 CI 使用 npm@>=2 来安装特定树而不必修改其 npm 版本的人。
新的锁文件（“package-lock.json”）基本上共享所有相同的代码，与 npm-shrinkwrap 完全相同的格式（您可以在彼此之间重命名它们！）。社区似乎也理解这一点：“它有一个锁定文件”似乎与人们点击的速度要快得多。最后，拥有一个新文件意味着我们可以使用shrinkwrap 进行相对低风险的向后兼容，而不必做一些奇怪的事情，例如父帖子中提到的allow-publication。
我认为这个想法是让 --save 和 shrinkwrap 默认发生，但避免在不需要的地方发生任何潜在问题。所以，他们只是给它一个新的文件名以避免任何冲突。来自 npm 的人在这里更彻底地解释了它：
相关报价：
默认情况下，npm 会在您的源目录中发布大多数文件，并且人们多年来一直在发布收缩包装。我们不想破坏兼容性。默认情况下使用 --save 和 shrinkwrap，它有很大的风险意外进入并通过注册表传播，并且基本上使我们能够更新 deps 和重复数据删除... null。
所以我们选择了一个新名字。我们突然选择了一个新名字。新的锁文件基本上共享所有相同的代码，完全相同的格式
package-lock.json仅保证版本npm ci（因为如果与 存在冲突，则会npm install覆盖package-lock.jsonpackage.json）。
npm-shrinkwrap.jsonnpm ci和都保证版本npm install。