Composer 并发 install 会因无文件锁和写入校验导致 lock 文件覆盖或丢失，引发依赖不一致；须用 flock 等文件锁串行化操作，并禁用自动 update，统一通过人工审核 PR 更新 lock。
Composer 本身不处理并发安装竞争，lock 文件冲突必须靠外部协作机制规避。
为什么 composer install 并发会出问题
多个进程同时执行 composer install（尤其在 CI/CD 或共享部署环境），可能读到旧的 composer.lock、各自解析依赖、再写回 lock——最终结果是覆盖或丢失他人更新。这不是 Composer 的 bug，而是它默认不加锁、不校验写入时版本一致性的设计使然。
典型现象：composer.lock 被反复提交不同哈希、CI 构建失败提示 “lock file is not up to date”、线上依赖版本不一致。
- Composer 2.x 之后默认启用
lock文件哈希校验，但仅在校验阶段（如install开始时），不阻止并发写入 -
composer update更危险：多个进程同时跑会直接破坏 lock 一致性，绝对禁止并发 - 即使只跑
install，若 lock 文件在过程中被其他进程修改，当前安装可能跳过某些 require-dev 包或降级版本
用 composer install --no-interaction --no-progress 不够，得加文件锁
单纯加参数不能解决竞争，关键在阻塞写操作。Linux/macOS 下可用 flock，Windows 需换方案（如 PowerShell 的 Get-FileLock 或改用 CI 原生锁）。
示例（shell 脚本中）：
flock ./composer.lock -c 'composer install --no-interaction --no-progress'
注意点：
-
flock锁的是文件描述符，不是文件路径本身；./composer.lock必须存在且可写，否则锁无效 - 不要锁
composer.json——它不参与安装逻辑，锁错对象没用 - CI 中更推荐锁整个项目目录（如
flock .git -c 'composer install...'），避免多个 job 同时操作同一 repo
CI/CD 场景下最稳的实践：把 lock 更新和安装拆开、串行化
真正高频出问题的不是 install，而是多人 push 后自动触发的 lock 更新 + install 混合流程。
- 禁止任何自动化流程执行
composer update—— 改为 PR 方式人工审核后合并 lock - 所有
composer install流程统一走一个带锁的脚本，且该脚本只读 lock，不生成新 lock - 若用 GitHub Actions，可用
concurrency配置限制同一仓库的 job 并发（按github.head_ref或路径分组） - Docker 构建中，把
composer install放进中间层缓存前，确保 base image 已含锁定好的 vendor 和 lock
真正麻烦的不是命令怎么写，而是团队里有人在本地 update 后忘了 commit lock，或者 CI 脚本偷偷调了 update --dry-run 还以为安全——这些行为会让锁机制形同虚设。
