必须提交composer.lock且不能被.gitignore拦截——应用项目依赖一致性的强制契约；验证用git check-ignore -v composer.lock，有输出即被忽略；冲突时应删lock后运行composer update --no-install重建，而非手动编辑。
composer.lock 被 .gitignore 拦截了怎么办
直接运行 git check-ignore -v composer.lock，如果有输出，说明它正被忽略——这是最常见也最隐蔽的问题。常见误配包括：/composer.lock（只匹配根目录，但某些项目生成路径含子目录）、*lock*（会连带屏蔽其他文件）、或空格导致的隐式失效。全局 ~/.gitignore 里写了也会生效，得一并检查。
修复只需两步：
1. 从所有 .gitignore 文件中删掉涉及 composer.lock 的行
2. 运行 git add -f composer.lock 强制加入暂存区
为什么 composer install 会退化成 composer update
当 composer.lock 缺失或被 Git 忽略时，composer install 实际行为等同于 composer update：它不再读取 lock 中记录的精确版本、commit hash 和 SHA256 校验值，而是重新解析 composer.json 中的范围约束（如 "^2.0"），在当前环境下求解“最新兼容版”。结果就是：本地装的是 monolog/monolog v2.9.1，CI 装出 v2.10.2，而后者可能引入未测的 API 变更。
验证是否真退化很简单：删掉 vendor/ 和 composer.lock，只留 composer.json，再跑 composer install。如果装出来的包版本和之前不一致，就说明 lock 没起作用。
团队协作中 composer.lock 冲突怎么处理
多人同时改 composer.json 并提交，容易触发 composer.lock 合并冲突。不要手动编辑 JSON 内容——格式稍错（多逗号、换行不一致）就会让 composer install 报 file could not be parsed。
使用 `gh` CLI 与 GitHub 交互。通过`gh issue`、`gh pr`、`gh run` 和 `gh api` 管理 issue、PR、CI 运行以及高级查询。
正确做法是：
1. 先用 git checkout --ours composer.lock 或 --theirs 保留任一方版本
2. 删除 vendor/
3. 运行 composer update --no-install 重建 lock（不装包，只写文件）
4. 提交新 composer.lock
注意：不能用 composer install 解决冲突，它不会更新 lock；也不能跳过校验直接 push，否则别人 composer install 会失败。
CI/CD 流程里漏掉 lock 文件校验的后果
很多 CI 脚本只写 composer install --no-dev --no-interaction，却没前置检查 composer.lock 是否存在且合法。一旦 lock 缺失，流程照常跑完，但实际装的是动态计算出的依赖版本，和开发环境完全脱节。
加一道保险很简单：
在 CI 脚本开头插入：test -f composer.lock || { echo "composer.lock missing"; exit 1; }
上线前还可加 composer install --locked：它会校验 lock 中每个包是否仍满足 composer.json 的约束，不满足直接报错退出。
真正难排查的不是报错，而是没报错却装错了——比如某个嵌套依赖悄悄升了 patch 版本，导致线上偶发类型错误，日志里找不到线索。
