核心是Web服务器用户必须拥有storage目录及其子目录的所有权和执行（x）权限，否则无法进入目录树导致log写入失败或CSS加载异常。
直接结论：不是 chmod 777 就能解决，核心是 Web 服务器用户（如 www-data、apache、nginx）必须对 storage 及其子目录拥有所有权和执行（x）权限。
为什么 storage/logs/laravel.log Permission denied
报错 file_put_contents(): failed to open stream: Permission denied 通常不是因为文件没写权限，而是 Web 进程无法“进入” storage 目录树——Linux 中访问子目录需每一级父目录都有 x 权限。常见卡点在 storage 或 storage/framework 目录属主是 root，而 Web 用户既不是所有者也不在同组。
- 运行
ls -ld storage查看顶层目录权限与属主，若显示drwxr-x---且属组不是 Web 用户组，就阻断了访问 - 定时任务（如
crontab）用root执行php artisan schedule:run，会以root身份创建laravel.log，导致后续 Web 请求因用户不匹配被拒 -
storage/framework/cache/data下的缓存文件权限若为644（而非664），Laravel 5.8+ 会拒绝写入，需检查config/cache.php中file驱动的permission配置或手动修复权限
如何正确设置 storage 目录所有权
不要跳过属主修复直接改权限。Web 服务器用户必须是 storage 和 bootstrap/cache 的实际所有者。
- 先确认 Web 用户名：Nginx 常用
www-data（Ubuntu/Debian）或nginx（CentOS/RHEL）；Apache 常用www-data或apache。用ps aux | grep -E '(nginx|httpd|apache)' | head -1看进程启动用户 - 统一属主属组：
sudo chown -R www-data:www-data storage bootstrap/cache - 若项目部署在 Docker 中，需确保容器内 UID/GID 与宿主机一致（通过
docker-compose.yml的args: - UID=${UID}传入），否则chown在宿主机生效，容器内仍无权访问
目录权限必须包含 x，不能只设 775
仅对 storage 目录 chmod 775 不够——子目录可能继承 750 或 700，缺少执行位（x）即无法 cd 进入，更无法读取内部文件。
- 递归给所有目录加
x：find storage -type d -exec chmod 755 {} \; - 递归给所有日志/缓存文件设安全读写权限：
find storage -type f \( -name "*.log" -o -name "*.php" \) -exec chmod 644 {} \; - 特别注意
storage/framework/cache/data目录下的文件，Laravel 默认期望它们是664，可加参数强制：find storage/framework/cache/data -type f -exec chmod 664 {} \;
public/storage 软链接失效也会导致 CSS 加载失败
页面样式丢失、图片 404，常因 public/storage 指向的 ../storage/app/public 不可读，而非前端代码问题。
- 检查软链接是否存在且有效：
ls -la public/storage，应输出类似public/storage -> ../storage/app/public - 验证目标路径是否可读：
sudo -u www-data ls -l storage/app/public/css/，若报Permission denied，说明storage/app/public或其任意父级（storage、storage/app）缺x权限或属主不匹配 - 重建链接（仅当链接损坏时）：
php artisan storage:link，但前提是storage/app/public已具备正确权限
最易被忽略的是多用户混用场景：开发时用自己账号跑 artisan 或 git pull，上线后 Web 进程却以另一用户运行——这时 chown 必须覆盖全部子目录，且要定期检查 cron 日志生成者是否仍是 Web 用户。权限问题从来不是单点配置，而是一条从根目录到具体文件的完整信任链。
