根本原因是PHP进程无storage目录写权限，导致日志、缓存、会话等功能中断；需统一属主为Web用户（如www-data）、递归设目录755权限、确保路径各层含x位、清理残留root属主文件，并检查SELinux/AppArmor等系统级拦截。
根本原因是 PHP 进程（Web 服务器或命令行）没有对 storage 目录及其子目录的写入权限，导致日志、缓存、会话、视图编译等关键功能全部中断——页面空白、500 错误、Permission denied 报错都是表象。
Web 服务器用户与目录属主不匹配
Laravel 在生产环境由 Web 服务器（如 Nginx/Apache）调用 PHP-FPM 执行，而 PHP-FPM 是以特定用户身份运行的（例如宝塔默认是 www，Ubuntu 是 www-data，CentOS 是 nginx 或 apache）。如果 storage 目录属主是部署时的当前用户（比如 john），但 PHP-FPM 用的是 www，那它就无权写入。
- 查 Web 用户：在宝塔中看 PHP 配置文件里的
user =和group =；或执行ps aux | grep php-fpm - 查目录属主：
ls -ld storage bootstrap/cache，对比输出第一列是否与 Web 用户一致 - 不一致时必须重设：
sudo chown -R www:www storage/ bootstrap/cache/（请按实际用户替换www）
目录缺少执行（x）权限，路径访问被阻断
Linux/macOS 中，要进入一个目录，用户必须对该目录有 x（执行）权限。而 storage/logs、storage/framework/views 等多层嵌套路径中，只要任意一层缺 x，PHP 就无法抵达目标文件位置。
- 仅设
775或755给顶层不够，必须递归确保所有子目录可进入：find storage bootstrap/cache -type d -exec chmod 755 {} \; - 特别注意
storage/logs/laravel.log：若它已存在且属主为root，直接删除再让 Laravel 重建，避免残留权限污染
软链接 public/storage 无法被 Web 服务器读取
php artisan storage:link 创建的是符号链接 public/storage → ../storage/app/public，但 Web 服务器能否顺着链接读取真实文件，取决于它对 storage/app/public 路径是否有 r-x 权限。
- 验证方式：
sudo -u www ls -l storage/app/public/（macOS 用_www） - 若报错“Permission denied”，说明 Web 用户无读取权限——此时不应改
$USER权限，而应加组授权：sudo chgrp -R www storage/app/public，再补chmod -R 755 storage/app/public - 链接本身也需检查：
ls -la public/storage必须显示正确指向，否则先rm -f public/storage再重新执行php artisan storage:link
系统级安全机制额外拦截
某些环境启用 SELinux（如 CentOS）、AppArmor（如 Ubuntu）或 macOS SIP/Gatekeeper，即使传统权限设置正确，也会阻止 PHP 写入。
- SELinux 检查：
sudo ausearch -m avc -ts recent | grep storage；放行命令：sudo semanage fcontext -a -t httpd_sys_rw_content_t "/path/to/storage(/.*)?"，再sudo restorecon -Rv /path/to/storage - macOS 上若提示 “Operation not permitted”，需临时禁用 SIP（重启进恢复模式执行
csrutil disable）或改用staff组授权配合chgrp -R staff storage - Docker 或 NFS 挂载场景：宿主机权限未同步，需在容器内确认用户 UID/GID 与挂载目录权限匹配
