不，package-lock.json 不应该被添加到 .gitignore 中。相反，我强烈建议:

1. 将 package-lock.json 添加到您的版本控制仓库中
2. 在构建本地应用程序和部署管道时使用 npm ci 而不是 npm install。
   （如果不确定，请通过以下方式升级您的 npm：
   npm install -g npm。）

npm install 命令最大的缺点之一是其具有意外行为，可能会改变 package-lock.json，而 npm ci 仅使用锁定文件中的版本，如果 package-lock.json 和 package.json 不同步，则会产生错误。

此外，npm ci 要求存在 package-lock.json ，如果不存在，则会输出错误。
有一个强烈的用例，即能够确信项目的依赖项可以在不同的计算机上以可靠的方式重复解析。

此外，npm ci 在添加依赖项之前会将整个 node_modules 文件夹清除，从而确保您使用实际的依赖项而不是本地更改，同时仍比普通的 npm install 更快。

从 package-lock.json 中，确切地获得一个经过验证的状态，具有完全相同的依赖树。

过去，我的一些项目没有 package-lock.json / npm-shrinkwrap.json / yarn.lock 文件，在某一天构建失败，因为一个随机的依赖项有了破坏性更新。（尽管许多库都遵循语义化版本指南，但您不能保证他们不会在次要更新中出错。）

这些问题很难解决，因为有时您需要猜测最后一个可用版本。

关于测试项目的最新依赖项：这就是 npm update 的用途，我认为应由开发人员运行该命令，同时在本地运行测试，如果出现问题则解决问题，然后提交更改的 package-lock.json。（如果升级失败，可以恢复到最后一个正常工作的 package-lock.json。）

此外，我很少一次性升级所有依赖项（因为这也可能需要进一步的维护），而是选择我需要的升级（例如 npm update {dependency} 或 npm install {dependency}@2.1.3）。这也是为什么我认为这是手动维护步骤的另一个原因。

如果您真的想自动化，则可以创建以下作业：

• 检出代码库
• 运行 npm update
• 运行测试
  • 如果测试通过，则提交并推送到代码库
  • 否则，失败并报告要手动解决的问题

我认为这是应该托管在 CI 服务器（例如 Jenkins）上的内容，不应通过将文件添加到 .gitignore 来实现。

或者引用npm文档:

强烈建议将生成的包锁定提交到源代码控制中：这将允许您团队中的任何其他人、您的部署、您的CI/持续集成以及在您的软件包源中运行npm install的任何其他人获取与您正在开发的完全相同的依赖树。此外，这些更改的差异是人类可读的，将通知您npm对您的node_modules所做的任何更改，因此您可以注意到任何传递性依赖项是否已更新、是否已提升等。

关于 npm ci与npm install之间的差异：:

• 项目必须有现有的package-lock.json或npm-shrinkwrap.json文件。
• 如果包锁中的依赖项与package.json中不匹配，则npm ci将出现错误，而不是更新包锁。
• npm ci一次只能安装整个项目：无法使用此命令添加单个依赖项。
• 如果node_modules已经存在，则在npm ci开始安装之前，它将被自动删除。
• 它永远不会写入package.json或任何包锁定：安装实际上是冻结的。