composer.json 定义项目依赖需求，composer.lock 锁定实际安装的精确版本，两者协同确保不同环境中依赖的一致性与可复现性。
在使用 Composer 管理 PHP 项目依赖时，composer.json 和 composer.lock 是两个核心文件。它们各自承担不同的职责，协同确保项目依赖的一致性和可复现性。
composer.json：定义项目依赖需求
composer.json 是你手动创建和维护的配置文件，用于声明项目的元信息和依赖关系。
它主要包含：
- name：项目的名称（如 vendor/project-name）
- description：项目简要说明
- require：列出项目运行所必需的外部包及其版本约束（例如 "monolog/monolog": "^2.0"）
- require-dev：开发阶段需要的工具，如测试框架、代码检查工具等
- autoload：自动加载配置，定义类如何被加载
当你运行 composer require package/name 命令时，Composer 会自动修改 composer.json 并安装对应包。
这个文件是版本控制的一部分，所有开发者共享相同的依赖声明起点。
composer.lock：锁定精确依赖版本
composer.lock 是由 Composer 自动生成的文件，记录当前环境中实际安装的所有依赖及其确切版本。
它包括：
- 每个直接依赖和间接依赖（即依赖的依赖）的完整名称和精确版本号（如 2.1.3）
- 每个包的来源地址（如 GitHub 链接或镜像地址）
- 校验和（checksum），用于验证包内容是否被篡改
只要存在 composer.lock 文件，运行 composer install 就会严格按照其中记录的版本安装依赖，不会拉取新版本。
这保证了在不同环境（开发、测试、生产）中安装的依赖完全一致，避免因版本差异导致的“在我机器上能运行”问题。
两者协作的工作流程
假设你在一个团队中开发 PHP 应用：
- 你添加一个新功能，需要使用 guzzlehttp/guzzle，执行 composer require guzzlehttp/guzzle
- Composer 根据 composer.json 中的约束选择一个兼容版本（比如 7.4.5），更新 composer.json，并生成或更新 composer.lock
- 你将这两个文件提交到 Git
- 同事克隆项目后运行 composer install，Composer 优先读取 composer.lock，安装 exactly 7.4.5 版本的 Guzzle 及其依赖链
如果只提交 composer.json 而忽略 composer.lock，每个人执行 composer install 时都可能得到不同的依赖组合，增加出错风险。
什么时候该提交 lock 文件？
对于大多数项目——尤其是应用型项目（application），应将 composer.lock 提交到版本控制系统中。
库（library）项目通常不提交 composer.lock，因为库本身是被别人使用的组件，不应限制使用者的依赖解析过程。
简单判断：如果你的项目最终会部署运行，就提交 lock 文件；如果它是供他人引用的 SDK 或组件，则不提交。
基本上就这些。composer.json 定义“想要什么”，composer.lock 记录“实际用了什么”。两者配合，让依赖管理更可靠。
