必须提交composer.lock，否则各环境因解析时间、网络顺序等差异会安装不一致依赖；仅改composer.json无法锁定版本，因^2.0等约束每次解析结果可能不同，而composer.lock才是确保vendor目录完全一致的“快照签名”。
必须提交 composer.lock，否则所有环境都会因解析时间、网络顺序、缓存状态不同而装出不一致的依赖版本。
为什么只改 composer.json 不够用
Composer 默认按 composer.json 中的约束（如 "monolog/monolog": "^2.0"）动态解析最新兼容版本。同一行约束，在 A 机器上可能装 2.10.0，在 B 机器上装 2.11.2 —— 尤其当包发布新小版本时，这种漂移每天都在发生。
- 不提交
composer.lock，等于把“版本决策权”交给每台机器的 Composer 解析器，而非项目本身 -
composer install在无锁文件时会自动触发update行为，结果不可控 - CI/CD 流水线拉代码后直接
install，若没锁文件，就可能意外升级到含 BC break 的版本
composer.lock 必须进 Git，且不能忽略
它不是临时产物，而是项目依赖的“快照签名”。只要内容不变，install 就永远还原出完全相同的 vendor/ 目录。
- 运行
git add composer.lock后提交，确保所有协作者和部署节点共享同一份精确版本记录 - 不要把
composer.lock加进.gitignore—— 这是团队里最常见也最危险的误配 - 从 Composer 2.5 起，如果
composer.lock缺少composer.json里声明的包，install会直接失败，强制你修复一致性
切换 PHP 版本后，vendor/ 和 composer.lock 必须一起重装
PHP 8.2 下生成的 autoload_static.php 可能包含 match 表达式或联合类型反射逻辑，在 8.1 环境下运行时直接 ParseError，哪怕文件本身能加载。
- 每次更换 CLI PHP 版本（如从
/usr/bin/php8.1切到/usr/bin/php8.3），必须先删掉vendor/和composer.lock - 再用目标版本执行：
/usr/bin/php8.3 composer install - 别指望
config.platform.php能绕过这个问题——它只影响安装期解析，不改变运行时语法兼容性
真正难的不是生成锁文件，而是让所有人理解：锁文件不是“可选备份”，它是依赖一致性的唯一载体。一旦有人本地删了它又没提交，整个团队的环境信任链就断了。
