post-install-cmd中清缓存大概率不生效，因其触发时vendor/autoload.php尚未完整生成，artisan等命令依赖的自动加载器和环境变量（如APP_ENV）不可用，导致命令静默失败或清错目录；应改用post-autoload-dump钩子，确保autoload就绪后再执行清理。
直接在 composer.json 的 scripts 里配 post-autoload-dump 钩子，用系统命令或框架命令清理指定目录——但必须避开 post-install-cmd，否则多数缓存命令会因 autoload 尚未就绪而静默失败。
为什么 post-install-cmd 里清缓存大概率不生效
Composer 执行 post-install-cmd 时，vendor/autoload.php 可能刚写入一半，或根本还没生成；Laravel/Symfony 的 artisan 或 bin/console 依赖完整 autoloader 和环境变量（如 APP_ENV），此时调用会直接报错或跳过操作。常见现象是：命令看似执行了，但 bootstrap/cache/config.php、storage/framework/views/ 等文件依然存在。
-
post-install-cmd触发时机太早，不保证 autoload 已可用 - 框架命令（如
php artisan cache:clear）需要bootstrap/app.php加载，而该文件依赖已生成的 autoload - 环境变量（如
APP_DEBUG）常未设置，导致命令 fallback 到 local 环境，清错目录
应该用 post-autoload-dump + 显式环境参数
post-autoload-dump 是更可靠的钩子：它只在 vendor/autoload.php 完整生成、类映射就绪后触发，此时 artisan 才真正可运行。配合 --no-interaction 和 --env=production 可绕过交互提示和环境误判。
- 在
composer.json中配置：
"scripts": {
"post-autoload-dump": [
"@php artisan config:clear --no-interaction --env=production",
"@php artisan cache:clear --no-interaction --env=production",
"@php artisan view:clear --no-interaction --env=production"
]
}
- 若项目无 artisan，改用 shell 命令（跨平台需注意）：
"post-autoload-dump": [ "if [ -d 'bootstrap/cache' ]; then rm -f bootstrap/cache/*.php; fi", "if [ -d 'storage/framework/views' ]; then rm -rf storage/framework/views/*; fi" ]
- Windows 用户避免
rm，可统一用 PHP 脚本封装，或改用del /q+rd /s /q
清理哪些目录才算真正有效
别只盯着 storage/cache/。Laravel 的「编译缓存」（bootstrap/cache/compiled.php、config.php、packages.php）才是部署后最常出问题的地方——它们由 php artisan optimize 或 config:cache 生成，但不会被 cache:clear 删除，必须手动删或用 optimize:clear（Laravel 9+）。
-
bootstrap/cache/：优先清空，含配置/路由/服务提供者编译结果 -
storage/framework/views/：Blade 编译模板，删后首次访问会重建，不影响功能 -
storage/framework/sessions/：按需清理（如加-mmin +60防误删活跃会话） -
storage/logs/和var/log/不建议自动删——日志应由 logrotate 管理，脚本介入易丢排障线索
容易被忽略的权限与路径陷阱
CI/CD 或 Docker 构建中，post-autoload-dump 脚本常因用户权限或工作目录错位失败。典型错误是 file_put_contents(bootstrap/cache/config.php): failed to open stream: Permission denied，或 Could not open input file: artisan。
- 确保脚本运行时当前目录是项目根目录（Composer 默认满足，但自定义 shell 命令里
cd ./更稳妥） - Docker 构建阶段若用 root 安装依赖，后续非 root 用户运行 artisan 会因
bootstrap/cache/目录属主不一致而失败 - 所有路径判断必须加
[ -d 'xxx' ]，防止项目结构不标准时命令中断（如某些微服务项目没storage/目录） - 不要在钩子里调用
composer dump-autoload后立刻删vendor/composer/autoload_*.php——这些是 Composer 运行必需的，删了会导致后续脚本崩溃
真正起效的清理，核心不是“删得多”，而是“删得准”且“删得稳”：选对钩子时机、避开 autoload 依赖盲区、验证路径是否存在、控制好执行用户权限——漏掉其中任一环，脚本就只是个安静的摆设。
