Composer 更新后需手动执行 composer clear-cache --no-interaction，因旧版缓存格式不兼容新版，错误隐蔽且卡在 Loading repositories；CI 中应显式调用而非依赖 post-update-cmd，清理须区分全局、项目与应用缓存，并避免误删或 hang 住。
Composer 更新后自动清理，不能只靠 post-update-cmd 绑定一条 composer clear-cache 就完事——它会清全局缓存、卡在 CI、误删正在用的文件，甚至根本没执行。
post-update-cmd 执行时机和权限陷阱
这个钩子只在本地运行 composer update 成功后触发，且默认以当前用户权限执行。CI 环境（如 GitHub Actions）常加 --no-scripts 参数跳过所有脚本，此时 post-update-cmd 完全不运行。
- CI 中更可靠的做法是：在 workflow 步骤里显式调用
composer clear-cache --no-interaction，而不是依赖钩子 - 本地开发时，若 IDE（如 PHPStorm）正扫描
~/.composer/cache/files/，clear-cache可能报Corrupted cache file错误——先关掉后台进程，或等 10 秒再重试 -
post-update-cmd中直接写composer clear-cache没加--no-interaction，在非交互环境会 hang 住，必须补上
清理范围必须分清楚：全局缓存 vs 项目缓存 vs 应用缓存
composer clear-cache 清的是全局的 ~/.composer/cache/，包括所有项目的元数据和已下载包归档；它不会动你的 storage/cache/ 或 var/cache/。这两类缓存混着清，要么漏掉，要么误删。
- 框架级缓存（如 Laravel 的
bootstrap/cache/compiled.php）得靠php artisan config:clear这类命令 - 临时包归档（
vendor/composer/archives/）建议一并删掉，避免下次install复用损坏 ZIP - Windows 用户别用
rm -rf，改用del /q vendor\composer\archives\*+rmdir /s /q vendor\composer\archives
推荐的 composer.json 脚本配置（带环境判断）
把清理逻辑封装成独立 script，并用 @ 引用，比堆命令更可控。下面这段可直接贴进 composer.json 的 scripts 字段：
"scripts": {
"clean-composer-cache": "composer clear-cache --no-interaction && rm -rf vendor/composer/archives/*",
"clean-app-cache": "if [ \"$APP_ENV\" = \"production\" ]; then php artisan cache:clear && php artisan view:clear; fi",
"post-update-cmd": [
"@clean-composer-cache",
"@clean-app-cache"
]
}
-
clean-composer-cache显式加了--no-interaction，适配 CI 和本地 -
clean-app-cache用$APP_ENV控制是否执行框架命令，避免开发时反复清缓存影响调试 - 如果项目不用 Artisan，把
php artisan ...替换成对应命令，比如 Symfony 用php bin/console cache:clear
真正容易被忽略的是：升级 Composer 本身（composer self-update）后，必须手动跑一次 composer clear-cache --no-interaction——旧版缓存格式可能被新版拒绝解析，但错误提示极其隐蔽，往往卡在 Loading repositories 就不动了。
