gitlab ci中composer install总重装依赖是因为未配置缓存，需手动用cache关键字设置key（推荐含composer.lock哈希）和restore-keys（如分支前缀+main兜底），并同时缓存vendor/和$home/.composer/cache。
gitlab CI里composer install为什么总重装依赖？
因为默认没开缓存，每次流水线都从零拉包，既慢又浪费带宽。GitLab CI本身不自动缓存vendor/或~/.composer/cache，得靠cache关键字手动配，而且必须配对——key决定缓存命中的逻辑，restore-keys决定降级匹配策略。
key不能只用$CI_COMMIT_REF_SLUG
单靠分支名做key会导致：同一分支多次提交时缓存复用（OK），但不同分支之间完全隔离（浪费）。更糟的是，如果composer.json或composer.lock变了，缓存却还命中，composer install可能跳过更新，导致实际依赖和锁文件不一致。
- 推荐用
key: ${CI_PROJECT_ID}-composer-${CI_COMMIT_REF_SLUG}-${CI_JOB_NAME}-$(sha256sum composer.lock | cut -d' ' -f1) - 如果没
composer.lock（不建议），至少用$(sha256sum composer.json | cut -d' ' -f1) - 避免用
$CI_PIPELINE_ID或$CI_JOB_ID——它们每跑必变，等于没缓存
restore-keys是兜底救命键
当key完全不匹配时（比如换了分支、改了锁文件哈希），GitLab会按restore-keys列表从前往后尝试找“最接近”的缓存。不配它，就真的一点缓存都用不上。
- 第一项建议用
${CI_PROJECT_ID}-composer-${CI_COMMIT_REF_SLUG}-${CI_JOB_NAME}-——匹配同分支同任务的旧缓存 - 第二项加
${CI_PROJECT_ID}-composer-main-—— fallback 到 main 分支的缓存，适合 feature 分支刚建时快速冷启 - 不要写死路径或版本号；
restore-keys只支持前缀匹配，末尾通配符无效
缓存路径必须包含vendor/和~/.composer/cache
只缓存vendor/，下次composer install仍要下载并解压 ZIP；只缓存~/.composer/cache，则vendor/每次重建，失去意义。两者必须同时声明。
-
paths:下写两行：vendor/和$HOME/.composer/cache/ -
$HOME/.composer/cache在 GitLab Runner 默认镜像里存在，无需mkdir -p - 别用
composer global config cache-dir改路径——增加不可控变量 - 注意权限：某些私有 Runner 以 root 运行，
$HOME可能是/root，确保cache配置路径可写
GitLab CI 的 Composer 缓存不是“开了就快”，关键在key是否真实反映依赖状态、restore-keys是否留了合理退路、路径是否覆盖下载+安装两个环节——漏掉任意一环，缓存就形同虚设。