答案是：composer install 本身不原子，必须靠 mv 原子替换模拟；换镜像后必须清空 vendor 和 composer.lock 并重装，因 vendor 含平台相关产物且不可复用。
composer install 本身不原子，必须靠 mv 替换模拟
Composer 没有内置事务或回滚机制。composer install 过程中任意环节失败（网络中断、磁盘满、post-install-cmd 报错），vendor/ 就会卡在半更新状态，composer.lock 却可能已写入新哈希——此时项目大概率无法启动。
生产环境唯一靠谱的做法是：在临时目录完成完整安装，再用 mv 原子替换：
- 执行
composer install --no-scripts --no-plugins --prefer-dist -d /tmp/myapp-new - 校验关键文件是否存在：
test -f /tmp/myapp-new/vendor/autoload.php && php -l /tmp/myapp-new/vendor/autoload.php - 用
mv vendor vendor.old && mv /tmp/myapp-new/vendor .切换（Linux/macOS 同一文件系统下mv是原子操作） - 切换成功后，再单独运行必要脚本，如
php artisan config:clear
注意：cp -r 或 rsync 不行——它们不是原子操作，中间态可见；rm -rf vendor && composer install 更危险，运行时直接缺失依赖。
镜像切换后 vendor 必须清空重装
换源（比如从 https://packagist.org 切到 https://mirrors.aliyun.com/composer/）不会改变 composer.lock 内容，但 vendor/ 里混杂了平台相关产物：符号链接指向本地路径、autoload_static.php 依赖当前 PHP 版本、扩展编译产物（如 ext-protobuf）无法跨机器复用。
常见错误现象：
-
Class not found，但类文件明明在vendor/里 →autoload.php映射了旧路径 -
Package foo/bar has a PHP requirement incompatible...→composer.lock中platform字段未同步，或被编辑器删了 trailing comma 导致 JSON 解析不全 - 本地能跑，Docker 构建失败 → 容器内没重建
vendor/，直接 COPY 了带 dangling link 的目录
实操建议：
- 每次换镜像后，先
rm -rf vendor composer.lock，再composer install - Dockerfile 中用多阶段构建：builder 阶段用完整镜像源 +
--no-dev --optimize-autoloader，final 阶段只COPY --from=builder /app/vendor ./vendor - CI 脚本加防护：
composer config --list | grep repositories.packagist.url | grep -q 'mirrors.aliyun.com'，不匹配则 abort
composer update --refresh 才能真正拉到镜像站最新元数据
镜像站元数据（packages.json）有 15 分钟本地缓存，默认不主动刷新。你看到 Packagist 页面已发布 monolog/monolog v3.6.0，但 composer update monolog/monolog 仍显示 Nothing to install or update——不是网络问题，是 Composer 复用了过期的本地元数据。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
错误做法：
-
composer clear-cache：它清的是 ZIP 包缓存，packages.json缓存照旧 - 手动删缓存目录：
rm -rf $(composer config --global cache-dir)/repo/https---mirrors-aliyun-com-composer，繁琐且易漏
正确姿势：
-
composer update --refresh（≥2.5）：只丢弃所有缓存的packages.json和provider-*.json，强制从当前镜像源重新下载元数据 - 验证是否生效：
curl -I https://mirrors.aliyun.com/composer/packages.json看Last-Modified时间是否更新 - 确认镜像源真正在用：
composer config --list | grep repositories.packagist.url，避免项目级"repositories"配置覆盖全局设置
composer.lock 是二进制快照，禁止任何手动编辑
composer.lock 不是配置文件，而是带完整哈希校验的二进制快照。改一个空格、删一个逗号、甚至换行符被编辑器转成 CRLF，都会导致 composer install 拒绝执行，或退化为 update 行为。
常见错误现象：
- CI 日志出现
Lock file operations: 123 installs, 45 updates, 67 removals，但你只改了一个包版本 → 实际是composer.lock被意外破坏 - 本地
install成功，CI 报错 → Git 的core.autocrlf在 Windows 上自动转换换行符，破坏 JSON 结构
实操建议：
- 提交前运行
composer validate --strict检查语法与完整性 - 全局禁用自动换行：
git config --global core.autocrlf false - 禁止在 CI 脚本中运行
composer update --lock后不提交——这等于把构建机的偶然结果当成了权威快照 - IDE 终端可能加载不同 shell 环境，
composer config -g repo.packagist输出和实际执行命令用的配置可能不一致
最麻烦的点往往藏在细节里：composer.lock 里一个被编辑器悄悄删掉的 trailing comma，或者 Docker 构建时 COPY 了未清理的 vendor/，都能让整个部署链路在最后一刻失效。
