“Failed to extract”或“corrupted archive”根本原因是缓存中ZIP文件损坏，而非网络问题；需确认运行用户、验证镜像配置是否生效（输出完整JSON且URL末尾带斜杠）、清空并修复~/.composer/cache权限，禁用vendor/缓存，改用COMPOSER_CACHE_DIR=/dev/null --no-cache安装。
CI/CD里composer install报“Failed to extract”或“corrupted archive”
这基本不是网络问题，而是缓存目录里某个 .zip 文件本身损坏了——比如下载中断、磁盘写入异常、镜像源同步滞后导致校验哈希不匹配。在CI环境中，composer clear-cache 往往无效，因为缓存路径可能被挂载为持久卷，且命令执行用户与配置用户不一致。
- 先确认实际运行用户：
whoami，别用sudo composer config -g写进 root 的配置，runner 用户读不到 - 验证镜像是否真生效：
composer config -g repo.packagist必须输出完整 JSON，URL 末尾带斜杠（如https://mirrors.aliyun.com/composer/） - 绕过缓存干扰最可靠的方式是设环境变量：
COMPOSER_CACHE_DIR=/dev/null composer install --no-cache --prefer-dist - 若仍失败，说明缓存目录权限错位：运行
ls -ld $(composer config --global cache-dir)，若 owner 是root，执行sudo chown -R $USER:$USER $(composer config --global cache-dir)
流水线中vendor目录莫名报Class not found或Cannot declare class
这不是包没装全，而是缓存了错误版本的 vendor/ —— 不同 PHP 版本、扩展启用状态（如 xdebug）、甚至不同 OS 下生成的 autoloader 不能混用。CI 中缓存 vendor/ 是高危操作，应只缓存 ~/.composer/cache。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 检查 CI 脚本是否误用了
CACHE_PATH: vendor/，正确做法是缓存~/.composer/cache并设置COMPOSER_CACHE_DIR - 如果已缓存了
vendor/，必须清掉再重装：在 install 前加rm -rf vendor/，且后续必须用--no-cache - PHP 版本切换后必现此问题，可在 install 前加检测：
php -v和composer show --platform | grep php对比是否匹配composer.json中的"php": "^8.1" - 某些 IDE 或杀毒软件会锁住
cache/files/下的 ZIP，CI 容器里可加--no-interaction避免卡在解压重试环节
换镜像源后依然从 packagist.org 下载
说明配置没落到当前用户环境，或项目级配置被覆盖。CI 中常见静默失效：字段名拼错、URL 少斜杠、repositories 字段格式错误，都会让 Composer fallback 到官方源。
- 执行
composer config -g repo.packagist，输出为空或仍是https://packagist.org就是没生效 - 别手写
"packagist.org": false，这会彻底关掉所有 fallback，镜像不可用时直接失败 - 推荐项目级配置：
composer config repo.packagist composer https://mirrors.tuna.tsinghua.edu.cn/composer/，它会安全追加到composer.json的repositories字段（前提是该字段是对象而非数组） - 加
-vvv运行composer install，日志里出现GET https://mirrors.aliyun.com/composer/p2/...才算真正走镜像
Docker 多阶段构建中依赖层反复重建
根本不是 Composer 缓存问题，而是 Docker 层缓存机制被破坏：把 COPY . /app 放在 composer install 前，会导致任何文件变更都触发重装。修复关键在于分离依赖安装与代码复制。
- 第一阶段 COPY 只限
composer.json和composer.lock：COPY composer.json composer.lock ./ - 立即运行
composer install --no-cache --prefer-dist --no-dev --optimize-autoloader - 第二阶段再
COPY . /app，这样只要 lock 文件不变，依赖层就复用缓存 - 避免在构建中用
composer update，CI 应始终基于 lock 文件还原，而非动态解析
composer clear-cache 很少奏效，得看日志里实际请求发往哪个域名、缓存目录归谁所有、vendor 是否被跨环境复用——这些细节漏掉一个，重装十次也没用。 
