post-install-cmd 中执行 php artisan config:clear 不生效，因 composer 环境无 laravel 上下文、autoload 未就绪或 app_env 未正确加载；应改用 post-autoload-dump 阶段并配合 --no-interaction --env=production 运行 optimize:clear（laravel 9+）或 clear-compiled（旧版），确保 autoload 已生成、权限与扩展就绪。
post-install-cmd 里执行 php artisan config:clear 不生效？
因为 composer install 运行时，Laravel 的配置缓存可能还没生成，或者当前环境没加载到正确的 APP_ENV，导致 config:clear 没效果。更关键的是：这个命令必须在 Laravel 应用上下文里运行，而 post-install-cmd 是纯 Composer 环境，artisan 可能找不到 bootstrap/app.php 或报 Class 'Illuminate\Foundation\Application' not found。
实操建议：
- 改用
php artisan optimize:clear（Laravel 9+）或php artisan clear-compiled（旧版），它们对环境依赖稍低，但依然要确保artisan可执行且当前目录正确 - 在
post-install-cmd中显式指定工作目录：cd ./ && php artisan config:clear - 加
--no-interaction和--env=production避免交互卡住或读错环境：php artisan config:clear --no-interaction --env=production - 如果项目未安装过依赖，
vendor/autoload.php尚未生成，artisan必然失败——此时应把清理逻辑移到post-autoload-dump阶段
为什么推荐用 post-autoload-dump 而不是 post-install-cmd？
post-autoload-dump 触发时机更可靠：它在 vendor/autoload.php 已生成、类自动加载就绪之后执行，此时 artisan 才真正可运行。而 post-install-cmd 可能在 autoload 文件写入前就启动，尤其在 CI/CD 环境中容易出错。
实操建议：
- 在
composer.json的scripts中定义："post-autoload-dump": ["@php artisan config:clear --no-interaction --env=production", "@php artisan cache:clear --no-interaction --env=production"]
- 避免使用
exec()或 shell 组合命令，Composer 对多命令链式调用支持不稳定 - 若项目有多个环境，不要硬编码
--env=production，改用$_ENV['APP_ENV'] ?? 'production'—— 但注意：这需要部署时已设置好环境变量，否则会 fallback 到local，清错缓存
缓存清理脚本在 Docker 部署中常见失败原因
Docker 构建阶段执行 composer install 时，artisan 命令常因缺少扩展或权限失败，典型错误是：PHP Fatal error: Uncaught Error: Class 'Redis' not found 或 file_put_contents(/var/www/storage/framework/cache/data/...): failed to open stream: Permission denied。
实操建议：
- 确保
Dockerfile中 PHP 扩展（如redis,opcache）在运行composer install前已安装 - 缓存目录权限要在
RUN composer install后单独RUN chown -R www-data:www-data /var/www/storage，不能只靠USER www-data - 跳过缓存生成阶段（如
php artisan config:cache）比强行清理更稳妥——生产镜像里干脆不跑config:cache，让应用启动时按需生成 - 用
php -d memory_limit=-1 composer install防止因内存不足导致 autoload 生成中断，进而让post-autoload-dump不触发
optimize:clear 和手动删 storage/framework/cache 有什么区别？
直接 rm -rf storage/framework/cache/* 看似快，但会误删 packages.php（由 composer dump-autoload 生成）、services.php（由 php artisan package:discover 生成），导致下一次请求报 Class not found。而 php artisan optimize:clear 知道哪些该删、哪些要保留。
实操建议：
- 永远优先走
artisan命令，而不是手删文件；只有在artisan完全不可用时（比如框架根本起不来），才考虑人工清理，并严格排除packages.php和services.php -
optimize:clear在 Laravel 9+ 默认同时清config,routes,views,cache,compiled，不用再拆成多个命令 - 如果你用的是 Octane，还需额外跑
php artisan octane:reload，否则旧缓存仍驻留在内存中
