composer install 不具备并发安全性，必须通过 flock 锁 composer.lock 实现串行化，且严禁自动化执行 composer update。
Composer 本身不提供并发安全的初始化逻辑，composer install 在多进程/多 Job 环境下直接并行执行必然导致 composer.lock 覆盖或状态错乱——这不是 bug，是设计使然。必须用外部锁机制串行化写操作，且严禁在自动化流程中混用 composer update。
为什么不能靠加参数解决并发 install 冲突
很多人试过 composer install --no-interaction --no-progress 或 --prefer-dist，但这些参数只控制输出和下载策略，完全不干预文件读写顺序。冲突根源在于：composer install 会先读取 composer.lock，再解析依赖、下载包、写入 vendor/，最后（可能）校验哈希——但整个过程无原子性，也无版本戳校验。多个进程同时读旧 lock、各自写 vendor、再各自写回 lock，结果就是谁最后写完谁赢，中间人的修改被静默丢弃。
-
composer.lock文件本身不带版本号或时间戳，Composer 不做写前比对 -
install阶段默认跳过 lock 校验（除非显式加--dry-run或触发更新） - CI 中常见现象：两个 PR 几乎同时合并，触发两个
composer install，最终 master 的composer.lock哈希与任一 PR 的都不一致
flock 是 Linux/macOS 下最轻量可靠的锁方案
核心原则：锁住的是「正在被写的文件」，不是「要读的文件」。所以必须锁 composer.lock（它参与写），而不是 composer.json（只读）。且 flock 锁的是文件描述符，要求目标文件已存在、可写。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 正确写法：
flock ./composer.lock -c 'composer install --no-interaction --no-progress' - 错误写法：
flock ./composer.json -c 'composer install'（composer.json不参与写入，锁无效） - 如果
composer.lock不存在（比如新分支首次构建），flock会失败；此时应先确保 lock 存在（例如从 main 分支 checkout 一份干净副本） - 在 CI 中更稳妥：锁整个工作目录，如
flock .git -c 'composer install'，避免同一 repo 多个 job 并发操作
CI/CD 中必须拆开 lock 更新与 install 两步
真正高频出问题的不是 install，而是自动化流程里把 composer update 和 install 混在一起跑。一旦多个 PR 触发自动 update，lock 文件立刻进入不可控竞争态。
- 禁止任何自动化流程执行
composer update——它会重写 lock，且无并发保护 - 所有 lock 变更必须走人工 PR：开发者本地运行
composer update xxx→ 提交composer.lock→ Code Review → 合并 - 所有 install 流程统一调用一个带
flock的封装脚本，且该脚本只接受已有 lock，不生成新 lock - GitHub Actions 示例：
concurrency: { group: ${{ github.head_ref }}, cancel-in-progress: true }，按分支分组限流，比锁文件更上层有效
Docker 构建中绕过运行时竞争的 trick
在 Dockerfile 中，composer install 放在构建中间层，天然具备缓存隔离性——但前提是 base image 已含锁定好的 vendor/ 和 composer.lock。否则每构建一次都可能因网络抖动或镜像源切换导致 vendor 内容微变，破坏层复用。
- 最佳实践：将
composer install提前到基础镜像中，例如自定义php-composer:8.2镜像，内建稳定 lock 和 vendor - 应用镜像只需
COPY composer.json composer.lock ./+RUN composer install --no-dev --no-interaction，且该命令不改 lock - 若必须动态 install，务必在 RUN 指令前加
chmod +w composer.lock，确保flock可写（Docker 构建上下文默认只读）
最麻烦的从来不是命令怎么写，而是团队里有人悄悄在 CI 脚本里加了 composer update，或者把 flock 锁错了文件路径——这些细节不显眼，但会在高并发部署时突然爆发。盯住 lock 文件的每一次写入来源，比优化 autoload 更关键。
