GitHub Actions中vendor目录缓存失效主因是cache-key未动态绑定composer.lock内容，须用hashFiles('composer.lock')生成key；同时需校验lock文件存在、路径统一为vendor/、按“恢复→安装→保存”顺序执行，并在key中嵌入PHP版本与OS标识以确保兼容性。
GitHub Actions里vendor目录缓存失效的常见原因
缓存没生效，八成不是Composer的问题，而是GitHub Actions的缓存键（
）没随
内容变化——用固定字符串或只读取文件名，会导致哪怕
更新了，缓存也照旧复用旧包。
必须用
生成动态key，不能写死
如果项目有
但没提交
，缓存会命中但安装结果不稳定——CI必须要求lock文件存在且提交
对路径大小写和斜杠方向敏感，
和
会被视为不同路径，务必统一用
正确配置
composer
install缓存的三步顺序
顺序错了就白配：先恢复缓存 → 再装依赖 → 最后保存新缓存。中间任何一步失败（比如
报错），都不能跳过缓存保存逻辑，否则下次还会加载坏缓存。
用
的
填
，不是
或
可加一个宽泛兜底项，比如
，避免lock微调后完全miss
在
后显式加
，否则CI可能卡住或生成低效autoload
多PHP版本或平台时缓存是否兼容？
不兼容。PHP 8.2生成的
不能直接给PHP 8.1用，尤其涉及扩展依赖（如
）或opcache预热逻辑时，强行复用会触发
或
错误。
GitHub Copilot
GitHub AI编程工具，实时编程建议
下载
缓存key里必须包含PHP版本，例如：
如果用
，它的
默认已带PHP维度，但仅适用于单job；跨job复用仍需自己控制key
Windows与Linux的
也不能混用——扩展名、路径分隔符、符号链接处理都不同
为什么有时候缓存命中的vendor还是慢？
因为
即使从缓存还原了
，仍会执行autoload dump和插件初始化，这部分无法跳过，但可以优化。
加
让autoloader跳过文件扫描，前提是确认没用
类型autoload
禁用非必要插件：在
里设
没用，但
锁死可减少兼容检查开销
CI中避免用
代替
——update必重解依赖树，缓存完全无效
缓存本身不难配，难的是让key真正反映“哪些输入变了”，以及接受vendor不是二进制安全的——PHP版本、OS、甚至某些插件的内部状态，都会让同一份lock产生行为差异。
cache-keycomposer.lockcomposer.lockhashFiles('composer.lock')'composer-vendor'composer.jsoncomposer.lockactions/cache@v4vendor/vendorvendor/composer installactions/cache@v4pathvendor/./vendorvendorrestore-keyscomposer-vendor-${{ hashFiles('composer.lock') }}-composer install--no-interaction --no-progress --optimize-autoloadervendor/ext-gdClass not foundUndefined symbolphp-${{ matrix.php-version }}-composer-vendor-${{ hashFiles('composer.lock') }}shivammathur/setup-phpcache: composervendor/composer installvendor/--classmap-authoritativefilescomposer.json"config": {"disable-tls": true}"plugin-api-version"composer updateinstall