Php 为什么composer设计为使用两个文件：composer.json和composer.lock，而不是一个文件

我想创建自己的包管理器，目前正在审查现有的解决方案

我现在正在使用PHP的Composer，它有两个文件，这非常令人惊讶：

用于项目配置和非固定依赖项的composer.json

composer.lock用于精确固定的依赖项

我确实理解为什么需要锁定依赖项。在我看来，锁定信息本身似乎是合乎逻辑的

我不明白的是为什么项目元数据被分成两个文件

有人能解释一下为什么它是这样设计的吗？为什么不能将deps固定在composer.json中

UPD。事实证明，Rust的Cargo具有相同的两个文件配置，并且对.lock文件的含义有很好的解释：

。锁信息是绝对固定的，通常由基于json信息的composer更新请求创建。。。但是开发人员不一定希望将所有内容都绑定到一个确切的版本，如果没有.json文件，他们必须为依赖项的每个版本升级手动升级.lock文件

锁还保存依赖项的依赖项，以及依赖项的依赖项等等。。。而.json文件只包含直接依赖项。。。。作为一名开发人员，您应该只需要控制直接依赖项，并允许这些库通过自己的.json文件控制自己的依赖项

基本上，您应该根据json构建应用程序，但要根据.lock部署。锁信息是绝对固定的，通常由基于json信息的composer更新请求创建。。。但是开发人员不一定希望将所有内容都绑定到一个确切的版本，如果没有.json文件，他们必须为依赖项的每个版本升级手动升级.lock文件

锁还保存依赖项的依赖项，以及依赖项的依赖项等等。。。而.json文件只包含直接依赖项。。。。作为一名开发人员，您应该只需要控制直接依赖项，并允许这些库通过自己的.json文件控制自己的依赖项

---

基本上，您应该根据json构建应用程序，但要根据.lock部署。在开发过程中，您通常希望能够轻松地升级到最新兼容版本的依赖项。composer.json提供了有关依赖项以及兼容版本的信息。composer.lock缺少兼容性信息，它可能会说包是根据依赖项的版本2.2.7构建的，但缺少有关规则的信息，例如该依赖项的版本>=2.1和<3是兼容的，而较低版本则不兼容，下一个主版本不保证安全

---

另一方面，在为测试或发布而构建时，有必要确保每次都根据完全相同的依赖版本集进行构建。通过列出使用的确切版本，composer.lock允许这样做。即使出现了新版本的依赖项，依赖项固定也可以确保生成不会更改，因此您不必担心依赖项包的更改会导致行为的更改。

在开发过程中，您通常希望能够轻松地升级到最新兼容版本的依赖项。composer.json提供了有关依赖项以及兼容版本的信息。composer.lock缺少兼容性信息，它可能会说包是根据依赖项的版本2.2.7构建的，但缺少有关规则的信息，例如该依赖项的版本>=2.1和<3是兼容的，而较低版本则不兼容，下一个主版本不保证安全

---

另一方面，在为测试或发布而构建时，有必要确保每次都根据完全相同的依赖版本集进行构建。通过列出使用的确切版本，composer.lock允许这样做。即使出现了新版本的依赖项，依赖项固定也可以确保构建不会更改，因此您不必担心依赖项包中的更改会导致行为的更改。

仍然不理解。所以，如果我使用project作为一个独立的应用程序，我使用的是.lock，我很满意。当我将project用作第三方应用程序时，我并没有使用它自己的.lock，而是使用放置在.json中的信息来安装库依赖项，对吗？我仍然不理解。所以，如果我使用project作为一个独立的应用程序，我使用的是.lock，我很满意。当我将project用作第三方应用程序时，我不是使用它自己的.lock，而是使用放置在.json中的信息来安装库依赖项，对吗？