简答：不，project.lock.file不应该被签入到源代码控制中-你应该配置版本控制系统来忽略它（如果你使用git，将它添加到.gitignore中）。
详细回答：project.lock.json包含了项目整个依赖关系树的快照-不仅仅是“dependencies”部分中列出的包，还有这些依赖关系的所有解析依赖关系，等等。但它不像ruby的Gemfile. lock。与Gemfile.lock不同，project.lock.json并不告诉dotnet restore应该恢复哪个确切版本的包-它只是被覆盖。因此，它应该像缓存文件一样被处理，并且永远不会被签入到源代码控制中。

如果您将其签入版本控制，那么很可能在其他机器上：

• dotnet会认为所有的软件包都已恢复，但实际上有些软件包可能丢失，构建将失败，而不会提示开发人员运行dotnet restore
• project.lock.json在dotnet restore期间会被覆盖，并且在大多数情况下会与存储在源代码控制中的版本不同。所以它几乎会在每次提交中被修改
• project.lock.json将在合并期间导致冲突

实际上，你有时候确实想在git中提交你的project.lock.json。

检查项目json

由于确切的原因，它会显示您使用的依赖项。说：
1.我作为一个开发人员在一个应用程序上工作，我讨厌每次更新包，所以我添加了一个包依赖到nuget包X = 1。
1.我恢复包我得到版本1.2.4
1.软件包制造商刚刚犯了一个非常愚蠢的错误，他在试图修复并发布1.2.5时破坏了一些东西

1. Person 2 checkout （或者更糟糕的版本构建启动）。
   1.人2恢复并获得版本1.2.5
   1.第二个人运行你的应用程序，发现应用程序坏了。
   1.第二个人开始调试，认为软件中一定有bug。
   在第7步，第二个人可能已经在git中看到他的锁文件被修改了，并且下载了一个新版本的库，这个库还没有被任何其他开发人员测试过！

缺点

签入这个文件的缺点是，你可能会在继续更新软件包时遇到很多合并冲突。

备选方案

只使用硬版本依赖（这对nuget来说很难）。并且只手动更新到新版本一次。

缺点

• 如果您构建了一个供其他人使用的库，这就不起作用了，因为您将它们固定到了依赖项的某个版本。
• 依赖项的重复仍然会自动解决，因此如果您不自己指定它们，则无法保证dotnet restore上的版本

总结

如果你想避免“在我的机器上工作”的引用和不断手动更新到新版本的地狱：检查project.lock.json。
在你发布之前，也要建立一个CI/Release构建检查来测试这个文件是否与git相比没有改变（如果你的软件非常关键）！
如果这不是一个问题，并且自动更新（到可能损坏的包）也不是一个大问题，那么您可能不想提交project.lock.json。

是，应提交/签入packages.lock.json。

至少截至2023年，回答“不”是错误的：
1.官方的NuGet wiki页面“使用锁定文件启用可重复的软件包恢复”明确指出
应将锁定文件签入到源资料档案库中。

1. Microsoft Learn文章Cache NuGet packages指出
   确保将packages.lock.json文件签入到源代码中。
   （sic，可能是指源代码 * 控件 *）
2. Microsoft开发博客文章"Enable repeatable package restores using a lock file" (2018)指出

• 您必须在源代码库中提交/签入此文件，以便它始终可用于还原。
• 锁定文件是由工具（NuGet）生成的文件，不应手动编辑。
• 锁定档案不应该放在套件内。它在套件内没有任何意义，NuGet永远不会使用它。

因此，至少有三个不同的官方来源/文件参考直接与 * 否 * 相矛盾，并声明 * 是 *。
推理
锁文件可用于不同的情况，包括：

• 确保可重复构建相关的依赖项解决方案-参见NuGet Wiki。
• 在CI管道缓存中缓存还原的NuGet依赖项-请参阅Cache NuGet packages。

如果完整的依赖关系树在构建/开发人员/计算机之间共享，这两种方法都有意义。
如果明确启用了此功能，则也只会创建packages.lock.json文件：

<PropertyGroup>
    <RestorePackagesWithLockFile>true</RestorePackagesWithLockFile>
</PropertyGroup>

字符串
如果该文件可用，则可以使用dotnet restore --locked-mode来恢复锁文件中持久化的依赖关系树。这在构建服务器上最有意义（对于可重复恢复、缓存或两者）--在构建服务器上，只有在提交了类似文件后，该文件才可用。
更多想法
使用锁定模式的另一种常见方法是在csproj文件中包含类似以下内容的内容：

<PropertyGroup>
    <RestoreLockedMode Condition="'$(ContinuousIntegrationBuild)' == 'true'">true</RestoreLockedMode>
</PropertyGroup>

型
然后像这样开始一个构建：

dotnet build -c Release /p:ContinuousIntegrationBuild=true

型
在应使用确定性生成的情况下，锁定相关性树也是有意义的，因此在创建确定性生成时启用锁定模式。有关ContinuousIntegrationBuild属性的详细信息，请参阅使用源链接生成包：确定性生成。

不，它只是一个锁文件，当锁文件存在时，你真的不应该签入它（除非锁定它的程序想把它签入源代码控制，在这种情况下，排除你的锁文件！）。