Composer如何利用缓存提高构建速度_在CI/CD中持久化目录【持续集成】-composer-PHP中文网

ci中composer install慢的根本原因是vendor/和~/.composer/cache未同时缓存：只缓存vendor/时，cache-dir清空会导致重复下载解压zip、校验哈希；必须双路径缓存+--no-interaction --prefer-dist --optimize-autoloader三参数齐备。

composer如何利用缓存提高构建速度_在ci/cd中持久化目录【持续集成】

CI 中 composer install 慢，不是因为没开并行，而是 vendor 和 cache-dir 没一起持久化 —— 缺一不可。

为什么只缓存 vendor/ 目录会失效

很多 CI 脚本只缓存 vendor/，但 Composer 安装前会先从 COMPOSER_CACHE_DIR 解包 ZIP、校验哈希、写临时文件。如果每次构建都清空 ~/.composer/cache，那即使 vendor/ 命中了，仍要重复下载 + 解压 + 校验。

现象：composer install 耗时稳定在 120s+，且网络请求量没减少
根本原因：cache-dir 清空 → 所有 dist 包重新下载 → vendor 重建只是“最后一环”
特别注意：vendor/bin/ 是符号链接，缓存时若未排除，可能在不同 runner 上指向错误路径

必须同时缓存的两个路径

GitHub Actions、GitLab CI、Jenkins 等平台必须同时声明以下两个缓存路径：

vendor/（需排除 vendor/bin/ 和生成类如 vendor/autoload.php 的临时内容）
~/.composer/cache（默认路径；CI 中建议显式设为 $HOME/.composer-cache-$PHP_VERSION，避免多 PHP 版本混用）

GitLab 示例（.gitlab-ci.yml）：

cache:
  key:
    files: [composer.lock]
    prefix: "${CI_JOB_NAME}-php-${PHP_VERSION}"
  paths:
    - vendor/
    - ~/.composer-cache-$PHP_VERSION

GitHub Actions 示例（actions/cache@v4）：

with:
  path: |
    vendor
    ~/.composer/cache
  key: ${{ runner.os }}-php-${{ matrix.php-version }}-composer-${{ hashFiles('**/composer.lock') }}

安装命令必须带的三个参数

漏掉任意一个，缓存就等于白配：

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 包安装；不加它，哪怕 cache-dir 有包，也会 fallback 到 git clone，彻底绕过缓存
--optimize-autoloader：生成 vendor/composer/autoload_classmap.php，跳过运行时扫描，PHP 加载快 20%+

完整推荐命令：

composer install --no-interaction --prefer-dist --optimize-autoloader --no-progress

部署阶段再加 --no-dev；测试阶段保留 --dev，但缓存 key 必须区分（例如用不同 prefix）。

缓存 key 设计最容易被忽略的点

只用 hashFiles('**/composer.lock') 当 key，看似合理，实则危险：

composer.lock 不含 platform 配置（如 "platform": {"php": "8.2"}），PHP 升级后旧缓存可能装错扩展兼容版本
私有仓库 token、镜像源切换、config.gitlab-token 变更不会反映在 lock 文件里，但会影响下载行为
多个 job 共享同一缓存 key，但实际执行环境（PHP 版本、OS、扩展）不同 → vendor 内容错乱

正确做法是把运行时关键变量显式纳入 key：

GitHub Actions：${{ runner.os }}-php-${{ matrix.php-version }}-composer-${{ hashFiles('**/composer.lock') }}
GitLab CI：files: [composer.lock] + prefix: "test-php-${PHP_VERSION}"

如果项目用了 composer.json 中的 autoload 变更（比如新增 psr-4 映射），vendor 缓存不会自动失效 —— 这时候得靠 composer dump-autoload --optimize 后手动触发缓存重建，或在 before_script 中加哈希校验逻辑。