我已阅读有关package-lock.json文件的以下内容：
该文件旨在提交到源存储库中，并用于各种目的：
- 描述依赖关系树的单一表示，以保证团队成员、部署和持续集成安装完全相同的依赖关系。
- 为用户提供“时间旅行”到 node_modules 先前状态的工具，而无需提交目录本身。
- 通过可读的源代码控制差异来促进对树更改的更大可见性。
- 并通过允许 npm 跳过以前安装的包的重复元数据解析来优化安装过程。
请参阅NPMJS 文档 package-lock.json 描述。
但在同一链接的另一个片段中，我看到：
正直§
这是此资源的标准子资源完整性。
- 对于捆绑的依赖项，这不包括在内，无论来源如何。
- 对于注册表源，这是注册表提供的完整性，或者如果未在 shasum 中提供 SHA1。
- 对于 git 源，这是我们从中克隆的特定提交哈希。
- 对于远程 tarball 源，这是基于文件 SHA512 的完整性。
- 对于本地 tarball 源：这是一个基于文件 SHA512 的完整性字段。
请参阅NPMJS 文档 package-lock.json 依赖完整性。
在链接到标准子资源完整性（SRI）之后，我发现了以下内容：
1.1。目标
- 损害第三方服务不应自动意味着损害包括其脚本的每个站点。内容作者将拥有一种机制，他们可以通过该机制指定他们加载的内容的期望，例如，他们可以加载特定的脚本，而不是碰巧具有特定 URL 的任何脚本。
请参阅W3C 子资源完整性
所以我想知道为什么在 NPMJS 文档中对package-lock.json的描述中没有提到/列出安全目的。就我个人而言，我也喜欢使用 package-lock.json 来提高我的应用程序安全性的想法（通过仔细查看锁定的实际依赖项并同时更改签入到我的 VCS 存储库的锁定文件，同时对我的package.json进行一些更改以防止任何被篡改的依赖项进入我的应用程序）。
但也许我遗漏了一些东西，由于某些原因，锁定文件不能用于我上面解释的安全目的。