Composer如何缓存加速CI构建_Composer CI缓存优化教程【入门】-composer-PHP中文网

composer install 在 ci 中变慢的主因是未启用或配置不当的本地缓存机制，导致每次重复下载解压包；正确做法是挂载 ~/.composer/cache/files 目录并用 composer.lock 哈希作缓存 key，配合 --no-interaction --prefer-dist --optimize-autoloader 参数优化流程。

composer如何缓存加速ci构建_composer ci缓存优化教程【入门】

为什么 `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