Composer install 在 CI 中变慢的主因是未启用或配置不当的本地缓存机制，导致每次重复下载解压包；正确做法是挂载 ~/.composer/cache/files 目录并用 composer.lock 哈希作缓存 key，配合 --no-interaction --prefer-dist --optimize-autoloader 参数优化流程。
为什么 composer install 在 CI 里总变慢？
不是网络差，也不是机器弱，而是默认没复用已下载的包——每次从头拉 zip、解压、安装 autoload、生成 autoloader，重复劳动占大头。CI 环境冷启动 + 无本地缓存 = 每次都重来。
关键点：Composer 自带缓存机制，但 CI 默认不启用或配置不当，导致缓存目录被清空、或根本没命中。
- 缓存路径默认是
$COMPOSER_HOME/cache（Linux/macOS）或%APPDATA%\Composer\Cache（Windows），CI 容器通常不持久化该路径 - 缓存只对
composer install和composer update中的包下载、zip 解压阶段生效，不加速 autoloader 生成 - 若
composer.lock变更，缓存仍可复用旧包，但新包仍需下载；若 lock 文件不变，缓存命中率可接近 100%
如何在 GitHub Actions / GitLab CI 中正确挂载 Composer 缓存？
核心动作不是“开启缓存”，而是把 cache 目录映射为持久化卷，并确保 Composer 进程读写的是它。
GitHub Actions 示例（推荐用官方 actions/cache）：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
steps:
- name: Cache Composer dependencies
uses: actions/cache@v4
with:
path: ~/.composer/cache/files
key: ${{ runner.os }}-composer-${{ hashFiles('**/composer.lock') }}GitLab CI 示例（用 cache: 关键字）：
cache:
key: "$CI_JOB_NAME"
paths:
- ~/.composer/cache/-
~/.composer/cache/files是实际存放下载包的位置，files子目录必须精确指定，否则缓存无效 - 使用
hashFiles('**/composer.lock')作为 key，比单纯用 OS 或分支名更精准——lock 文件一变，缓存自动失效 - 别用
composer config --global cache-dir改全局路径，CI 容器生命周期短，改了也白改；靠环境变量COMPOSER_CACHE_DIR更可靠
composer install --no-interaction --prefer-dist --optimize-autoloader 这几个参数到底谁管啥？
它们不是锦上添花，而是 CI 场景下必须加的组合技：
-
--no-interaction：跳过所有交互提示（比如 auth token 输入），CI 没终端，不加会卡住 -
--prefer-dist：强制走 zip 包安装（而非 git clone），速度快、体积小、缓存友好；若某包没 dist，Composer 会自动 fallback 到 source，不用怕 -
--optimize-autoloader：生成扁平化 classmap，减少文件 stat 调用；对 Laravel/Symfony 类框架明显提速，但会略增构建时间；生产环境必开 - 别加
--ignore-platform-reqs，除非你真要绕过 PHP 版本或扩展检查——CI 环境应严格匹配目标运行环境
缓存失效却没报错？这几个信号说明你白配了
缓存看似启用，但日志里反复出现 Downloading ... 或 Installing ... from dist 后没提“Using cached archive”，基本就是没生效。
- 检查 CI 日志是否含
Cache hit或Cache miss—— GitHub Actions 的actions/cache会明确输出 - 运行
composer config --global cache-dir看路径是否指向你挂载的目录；再进容器执行ls -la $(composer config --global cache-dir)/files | head -n 5，确认有内容 - GitLab CI 若用
cache:，注意它默认只缓存 job 间共享，跨 pipeline 不共享；且key写成$CI_COMMIT_REF_SLUG会导致 feature 分支和 main 分支缓存隔离，反而降低复用率 - 私有包（如 GitLab 私仓、Satis）若用了
http-basic认证，缓存能复用，但首次认证失败会导致整个 install 失败——务必提前用composer config注入 token
缓存不是设了就完事，得看日志、查路径、验内容。最常被忽略的是：没确认 files 子目录是否真的被缓存，以及 lock 文件哈希是否真在变化时触发了更新。
