github actions中vendor目录缓存失效主因是cache-key未动态绑定composer.lock内容，须用hashfiles(‘composer.lock’)生成key；同时需校验lock文件存在、路径统一为vendor/、按“恢复→安装→保存”顺序执行，并在key中嵌入php版本与os标识以确保兼容性。
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错误。
- 缓存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产生行为差异。