Composer如何在CI流水线中缓存vendor目录？（GitHub Actions示例）-composer-PHP中文网

GitHub Actions中vendor目录缓存失效主因是cache-key未动态绑定composer.lock内容，须用hashFiles('composer.lock')生成key；同时需校验lock文件存在、路径统一为vendor/、按“恢复→安装→保存”顺序执行，并在key中嵌入PHP版本与OS标识以确保兼容性。

composer如何在ci流水线中缓存vendor目录？（github actions示例）

GitHub Actions里vendor目录缓存失效的常见原因

缓存没生效，八成不是Composer的问题，而是GitHub Actions的缓存键（cache-key）没随composer.lock内容变化——用固定字符串或只读取文件名，会导致哪怕composer.lock更新了，缓存也照旧复用旧包。

必须用hashFiles('composer.lock')生成动态key，不能写死'composer-vendor'
如果项目有composer.json但没提交composer.lock，缓存会命中但安装结果不稳定——CI必须要求lock文件存在且提交
actions/cache@v4对路径大小写和斜杠方向敏感，vendor/和vendor会被视为不同路径，务必统一用vendor/

正确配置composer install缓存的三步顺序

顺序错了就白配：先恢复缓存 → 再装依赖 → 最后保存新缓存。中间任何一步失败（比如composer install报错），都不能跳过缓存保存逻辑，否则下次还会加载坏缓存。

用actions/cache@v4的path填vendor/，不是./vendor或vendor
restore-keys可加一个宽泛兜底项，比如composer-vendor-${{ hashFiles('composer.lock') }}-，避免lock微调后完全miss
在composer install后显式加--no-interaction --no-progress --optimize-autoloader，否则CI可能卡住或生成低效autoload

多PHP版本或平台时缓存是否兼容？

不兼容。PHP 8.2生成的vendor/不能直接给PHP 8.1用，尤其涉及扩展依赖（如ext-gd）或opcache预热逻辑时，强行复用会触发Class not found或Undefined symbol错误。

openclaw-github-config-impact

OpenClaw 技能 — 给定一个 GitHub 仓库 URL，自动解析出 owner/repo 名称，发现其中的 YAML/properties 配置文件及其配对的中文字段说明；在 `workspace/{repo}/` 目录下按同步日期（格式为 `YYYY-MM-DD`）创建时间戳子目录；写入 `.openclaw-config-state.json` 状态文件。每次用户提问前，先比对远程仓库当前 ref（如 `main` 或 `master`）的最新提交 SHA 与本地状态文件中记录的 SHA：

下载

缓存key里必须包含PHP版本，例如：php-${{ matrix.php-version }}-composer-vendor-${{ hashFiles('composer.lock') }}
如果用shivammathur/setup-php，它的cache: composer默认已带PHP维度，但仅适用于单job；跨job复用仍需自己控制key
Windows与Linux的vendor/也不能混用——扩展名、路径分隔符、符号链接处理都不同

为什么有时候缓存命中的vendor还是慢？

因为composer install即使从缓存还原了vendor/，仍会执行autoload dump和插件初始化，这部分无法跳过，但可以优化。

加--classmap-authoritative让autoloader跳过文件扫描，前提是确认没用files类型autoload
禁用非必要插件：在composer.json里设"config": {"disable-tls": true}没用，但"plugin-api-version"锁死可减少兼容检查开销
CI中避免用composer update代替install——update必重解依赖树，缓存完全无效

缓存本身不难配，难的是让key真正反映“哪些输入变了”，以及接受vendor不是二进制安全的——PHP版本、OS、甚至某些插件的内部状态，都会让同一份lock产生行为差异。