必须提交 composer.lock 并统一运行 composer install：它精确记录包版本、哈希与依赖树，缺失会导致环境不一致、CI 构建波动、安装失败；通过配置 "lock": true 和 pre-update-cmd 脚本可强制约束流程。
必须提交 composer.lock，且所有成员必须运行 composer install（而非 composer update）来还原依赖——这是唯一能保证团队环境一致的底线。
为什么 composer.lock 不能忽略或只在本地生成
它不是缓存文件，而是精确记录了每个包的最终解析版本、哈希值、安装路径和依赖树快照。一旦不提交，不同人执行 composer install 会各自解析 composer.json，而 packagist 上的最新版可能已变（比如 monolog/monolog 从 3.4.0 升到 3.5.0），导致行为差异甚至静默故障。
- CI/CD 流水线若没
composer.lock，每次构建都可能拉取新版本，测试通过但线上崩 -
git clone后直接composer install失败，报错Package operations: 0 installs, 0 updates, 0 removals—— 实际是 lock 文件缺失，Composer 退化为仅读composer.json并拒绝操作 - 团队中有人手抖运行了
composer update又没提交 lock，其他人composer install仍用旧 lock，但实际装的是新包（Composer 不校验 lock 是否匹配当前 json）
如何防止误用 composer update 破坏一致性
靠流程不如靠机制。在项目根目录加 composer.json 配置项，让 Composer 主动拦截危险操作：
{
"config": {
"lock": true,
"platform-check": false
},
"scripts": {
"pre-update-cmd": "echo '❌ composer update is disabled in team mode'; exit 1"
}
}
-
"lock": true强制所有命令（包括require）都以 lock 为准，避免意外升级 -
pre-update-cmd脚本会在每次composer update前触发并中断，比靠文档提醒可靠得多 - 如需真正升级依赖，应走明确流程：修改
composer.json→ 运行composer update vendor/package-name→ 检查变更 → 提交新的composer.lock
composer install 报 hash mismatch 或 failed to download 的常见原因
不是网络问题，大概率是 lock 文件被部分修改或混入了本地调试配置：
- 手动编辑过
composer.lock（比如删掉某个 dev-only 包的条目），导致哈希校验失败 - 本地
composer.json中repositories指向了私有源，但 lock 里记录的是 packagist 官方源的 dist URL，CI 环境无该私有源权限 - PHP 版本不一致：lock 文件中
platform字段声明了"php": "8.2"，但某台机器是 PHP 8.1，Composer 会跳过安装并报错 - 解决方案优先级：先
git checkout -- composer.lock恢复原始 lock；再确认php -v和composer show --platform输出是否匹配
最易被忽略的一点：CI 环境默认启用 --no-interaction，但某些私有包若未配置 auth.json 或 token，composer install 会卡住而非报错——务必在 CI 脚本开头显式检查 composer config --global --list | grep github-oauth 或挂载凭证文件。
