CI中composer install每次都慢的根本原因是默认不复用缓存，因每次都是全新环境导致vendor和全局cache为空，必须显式配置COMPOSER_CACHE_DIR并挂载持久化路径，配合--no-interaction、--prefer-dist、--optimize-autoloader等参数才能有效复用缓存。
CI 中 composer install 为什么每次都慢？
根本原因不是网络差，而是默认不复用本地缓存 —— CI 每次都是全新容器/虚拟机，vendor/ 目录和 Composer 的全局 cache（~/.composer/cache/）全为空。即使用了相同的 composer.lock，也要重新下载、解压、校验每个包。
必须启用 COMPOSER_CACHE_DIR 并挂载持久化路径
Composer 不会自动识别 CI 环境的缓存位置，必须显式指定且确保该目录在 job 间可复用。GitHub Actions、GitLab CI、Jenkins 都需配置缓存路径绑定：
- GitHub Actions：用
actions/cache@v4缓存~/.composer/cache，键值建议包含composer.lock的 hash（如${{ hashFiles('**/composer.lock') }}） - GitLab CI：在
cache:下声明key: $CI_COMMIT_REF_SLUG+paths: [ "~/.composer/cache" ]，并确保 runner 使用 shell 或 docker executor（不能是 parallels） - 关键点：
COMPOSER_CACHE_DIR必须在composer install前设好，例如：export COMPOSER_CACHE_DIR="$HOME/.composer/cache"
composer install --no-interaction --prefer-dist --optimize-autoloader 这几个参数缺一不可
少一个都可能绕过缓存或降低命中率：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
--no-interaction：避免因交互提示中断流程（CI 无 TTY） -
--prefer-dist：强制走 zip 包安装（而非 git clone），才能利用 cache 中已下载的 dist 归档；若项目强制--prefer-source，缓存基本失效 -
--optimize-autoloader：虽不直接影响缓存复用，但能减少后续测试启动时间，且部分 CI 镜像（如 php:alpine）默认关闭此选项
注意：composer update 在 CI 中应禁止使用 —— 它会忽略 composer.lock 并重新解析依赖，完全跳过缓存逻辑。
私有包或 VCS repo 的缓存行为容易被忽略
如果项目依赖了 GitLab/GitHub 私有仓库或自建 Packagist，缓存机制会退化：
- Composer 对 VCS 包默认走
--prefer-source，除非你在repositories中显式声明"type": "package"或配置"dist"字段 - 私有 Packagist 若未开启
allow-plugins或未正确设置auth.json，composer install会 fallback 到逐个 clone，导致缓存无效且频繁认证失败 - 解决方案：在 CI job 开头注入
auth.json到$HOME/.composer/auth.json，并确保其权限为600（否则 Composer 拒绝读取）
真正起效的缓存，取决于 dist 包是否能被稳定命中 —— 而这需要 lock 文件稳定、镜像源可用、认证可靠、参数严格对齐。任何一环松动，缓存就变成摆设。
