bootstrap/cache目录缺失或不可写会导致Target class [request] does not exist.、Please provide a valid cache path、file_put_contents() Permission denied等错误，本质是Laravel无法生成packages.php、services.php、config.php等缓存文件。
bootstrap/cache 目录不存在或不可写导致报错
常见错误现象包括：Target class [request] does not exist.、Please provide a valid cache path、file_put_contents(): failed to open stream: Permission denied。本质不是代码问题，而是 Laravel 在运行时无法写入 bootstrap/cache 目录下的 packages.php、services.php、config.php 等自动生成文件。
典型触发场景：
- Git 仓库忽略
bootstrap/cache（.gitignore 中含bootstrap/cache），部署后该目录为空 - 自动化部署脚本未创建目录或未赋权，尤其在 Docker 或 CI/CD 环境中
- Web 服务器用户（如
www-data、nginx、apache）对目录无写权限
手动创建并赋权的最小可行操作
不要只改权限，先确保目录结构存在。Laravel 运行前必须有 bootstrap/cache 这个完整路径，且 Web 服务器进程能往里写文件。
执行以下三步（以 Linux 为例）：
-
mkdir -p bootstrap/cache（确保路径存在，-p避免父目录缺失报错） -
chown www-data:www-data bootstrap/cache（根据实际 Web 用户调整，Nginx 常用nginx:nginx） -
chmod 755 bootstrap/cache（不推荐盲目777；755对目录足够，文件由 Laravel 自己生成并设合适权限）
如果仍报 Permission denied，检查 SELinux 是否启用（CentOS/RHEL）：getenforce。若为 Enforcing，临时测试可 setenforce 0，长期方案是用 chcon -R -t httpd_sys_rw_content_t bootstrap/cache。
为什么不能只靠 php artisan config:clear？
这个命令只是删掉 bootstrap/cache/config.php，但不会重建目录、修复权限，更不会生成其他必需缓存文件（如 services.php）。它常被误当作“万能清缓存命令”，但前提是 bootstrap/cache 本身可写且存在。
真正需要的是组合动作：
-
rm -f bootstrap/cache/*.php（清空已有缓存文件） -
php artisan config:cache（重新生成config.php） -
php artisan optimize:clear（Laravel 9+ 推荐，等价于清 services + packages + config）
注意：执行这些命令的用户，也得对 bootstrap/cache 有写权限 —— 否则命令本身就会失败。
CI/CD 或容器化部署时最容易漏的点
很多团队在 GitHub Actions、Jenkins 或 Dockerfile 中执行 composer install 和 php artisan config:cache，却忘了在构建阶段或启动脚本里初始化 bootstrap/cache 的所有权和权限。
建议在部署脚本末尾加：
mkdir -p bootstrap/cache chown -R $WEB_USER:$WEB_USER bootstrap/cache chmod -R 755 bootstrap/cache
其中 $WEB_USER 应与运行 PHP-FPM 或 Web 服务的用户一致。硬编码用户名不如用 id -un $(ps aux | grep 'php-fpm\|httpd\|nginx' | head -1 | awk '{print $1}') 动态获取（视环境而定）。
最麻烦的情况是多个进程用户不一致：CLI 用 root 执行 artisan，但 Web 请求由 www-data 处理 —— 缓存文件生成后，www-data 可能读不了 root 写的文件。务必统一用户上下文。
