GitLab CI/CD 中应优先缓存 Composer 全局缓存目录（~/.composer/cache/）并以 composer.json 和 composer.lock 文件哈希值为 cache key，避免直接缓存 vendor/ 目录以防权限、环境漂移等问题，可提升构建速度 40%–70%。
在 GitLab CI/CD 中缓存 Composer 依赖，核心是复用 vendor/ 目录或 Composer 的全局缓存目录，避免每次构建都重新下载和安装包。关键是选对缓存路径、配置合理的缓存键（cache key），并避开常见陷阱（比如缓存污染或权限问题）。
使用 Composer 全局缓存目录（推荐）
Composer 自带的缓存机制（~/.composer/cache）比直接缓存 vendor/ 更安全、更高效——它只缓存下载的 zip/tar 包和已解析的元数据，不包含项目特定的 autoloader 或脚本，不会因 composer.json 微小变动导致整个 vendor 失效。
在 .gitlab-ci.yml 中配置如下：
cache:
key: ${CI_COMMIT_REF_SLUG}-composer-cache
paths:
- ~/.composer/cache/
再确保每次 job 都运行 composer install --no-interaction --prefer-dist（CI 环境默认启用 cache，无需额外参数）。
按依赖指纹生成 cache key（精准失效）
用 composer.json 和 composer.lock 的 SHA256 值作为 cache key，能保证：lock 文件一变，缓存自动失效；没变就复用，真正实现“增量优化”。
示例写法：
cache:
key:
files:
- composer.json
- composer.lock
paths:
- ~/.composer/cache/
GitLab 会自动计算这两个文件的哈希值拼接成唯一 key，无需手写 script。
避免缓存 vendor/ 目录（除非必要）
直接缓存 vendor/ 看似快，但容易出问题：
- 权限混乱：不同 runner 用户 UID 不同，缓存的 vendor 可能因权限拒绝执行脚本
- 环境漂移：本地开发用 PHP 8.2，CI 用 8.1，缓存的扩展二进制可能不兼容
-
锁文件未生效：若误用
composer update而非install，缓存 vendor 会掩盖版本不一致问题
仅当项目极小、无扩展、且严格锁定 PHP 版本时，才考虑：
cache:
key: ${CI_COMMIT_REF_SLUG}
paths:
- vendor/
并务必搭配 composer install --no-dev --optimize-autoloader 和 rm -rf vendor 在 job 开头清理残留（防污染）。
补充提速技巧
让 Composer 安装更快，还可以加几条轻量配置：
- 设置
COMPOSER_CACHE_DIR显式指向缓存路径（与 cache.paths 一致） - 加
--no-suggest跳过建议包提示（纯 CI 场景不需要） - 用
composer install --ignore-platform-reqs仅在测试多 PHP 版本时启用，生产环境慎用 - 如用私有包，提前在 before_script 中配置 auth.json 并加入 cache key 计算（防止凭据变更后缓存误用）
基本上就这些。用好全局缓存 + lock 文件 key，90% 的 PHP 项目 CI 构建时间能降 40%–70%。
