composer.lock未提交会导致CI每次构建随机失败，因composer install退化为update并按版本范围重选依赖，引发Class not found等兼容性问题。
composer.lock没进Git，CI构建就等于裸奔
不是“可能失败”，而是每次构建都随机失败。CI服务器执行composer install时发现没有composer.lock，会自动退化为composer update逻辑——它按composer.json里的"^2.0"这种范围约束重新选版本，今天装monolog/monolog v2.8.0，明天可能是v2.10.2，而后者删了一个你代码里还在用的Monolog\Handler\NativeMailerHandler类。
- 典型现象：
Class not found、Call to undefined method、测试通过率忽高忽低 - 验证是否真被忽略：运行
git check-ignore -v composer.lock，有输出就说明它早被.gitignore拦下了 - 常见误配：
/composer.lock（只匹配根目录）、composer.lock（可能误匹配my-composer.lock）、行首尾空格导致规则静默生效 - 补救：删掉
.gitignore中相关行，再用git add -f composer.lock强制加入暂存区
本地能跑通，线上报错，90%是lock文件没同步
你本地composer install成功，是因为你上次运行过composer update，生成了composer.lock并留在磁盘上；但这个文件没提交，别人拉代码后composer install实际走的是update流程，装出来的vendor/和你根本不是同一套依赖树。
- 关键区别：
composer install读composer.lock装精确版本；composer update忽略composer.lock，按composer.json重算整个依赖图 - 错误操作链：改完
composer.json→ 忘记composer install或composer update→ 直接git commit→ 别人git pull && composer install→ 装出不一致包 - 上线前必查：
git status确认composer.lock在待提交列表里；git diff composer.lock看content-hash是否更新
合并分支时composer.lock冲突，手动编辑=埋雷
Git把composer.lock当普通文本合并，<<<< HEAD残留、字段顺序错乱、dist.sha256值错位——这些都会让composer install直接拒绝执行，或静默装错子依赖。
审计 GitHub Actions 工作流文件的密钥泄露风险，例如 pull_request_target 密钥使用、密钥回显命令及未固定版本的 Action 密钥传递。
- 绝对禁止：用编辑器删冲突标记、凑“看起来合理”的版本号、调整JSON字段顺序
- 安全重建流程：先确保
composer.json已干净合并 →rm composer.lock→composer update --no-install→git add composer.lock - 预防优于治疗：在
composer.json里加"sort-packages": true，让packages数组固定排序，大幅减少“假冲突” - CI脚本加固：
composer validate --strict放在composer install前，校验失败直接中断构建
误删或损坏composer.lock后，别急着composer install
composer install不是万能恢复命令。如果composer.lock已损坏（JSON语法错误、冲突标记残留）或vendor/目录不完整，直接运行composer install大概率报错Command "install" is not defined（Composer 2.5+行为）或Invalid lock file. Corrupted.。
- 先诊断：
composer validate—— 报The lock file is not up to date是过期，跑composer update --lock即可；报./composer.lock is invalid带行号才是真损坏 - vendor可信？若
vendor/没动过，备份composer.lock后直接composer update --lock（不重装包，只重写lock） - vendor不可信？删掉
vendor/和composer.lock，再composer install --no-cache，避免缓存污染 - Git历史还在？用
git checkout HEAD -- composer.lock秒级恢复，比重生成更可靠
真正容易被忽略的点在于：composer.lock不是“缓存”或“中间产物”，它是依赖快照的哈希契约。它小、可读、Git友好，删它省不了什么，留它防得住所有“明明我本地好好的”类故障。
