Laravel部署后storage目录权限不足的排查与修复
刚部署完Laravel就遇到500错误，日志提示storage或bootstrap/cache不可写？这类权限问题在Linux环境下几乎必踩。这里分享一套从确认Web用户、调整目录归属到处理SELinux的完整排查流程，帮你快速恢复应用正常写入。
把Laravel项目传到服务器，Nginx或Apache刚配好，一刷新首页就报500。去服务器上看日志，大概率能翻到 failed to open stream: Permission denied，或者直接提示 storage/logs/laravel.log 创建失败。这种权限坑几乎每次部署都会踩，核心原因就是Web进程用户（比如www-data、nginx）对 storage 和 bootstrap/cache 没有写入权。别一上来就 chmod 777，按下面顺序排查更稳妥。
确认Web进程运行身份
不同发行版、不同Web服务器的默认用户并不一样。Debian/Ubuntu上Nginx和Apache通常是 www-data；CentOS/RHEL里Nginx是 nginx，Apache则是 apache。如果你用PHP-FPM，还要留意php-fpm的worker用户，配置文件一般在 /etc/php/版本/fpm/pool.d/www.conf 里。最稳妥的办法是直接跑 ps aux | grep -E 'nginx|apache|httpd|php-fpm'，看第一列的进程所有者，记下这个名字，后续所有权限调整都要对齐它。
查看现有目录归属
进项目根目录，先摸清当前状况，执行 ls -la storage bootstrap/cache。如果看到目录所有者是root或者你的SSH登录用户，而Web进程是 www-data，那写入被拒就毫不意外了。这时候不要直接给777，而是把所有权交给Web用户组，同时保留合理的权限位。
调整目录所有者和权限
假设Web用户是 www-data，先递归改归属：sudo chown -R www-data:www-data storage bootstrap/cache。接着给目录和文件分别设权限。目录需要可进入，文件需要可读写，但不必全开。执行 find storage bootstrap/cache -type d -exec chmod 775 {} \; 和 find storage bootstrap/cache -type f -exec chmod 664 {} \;。这样Web用户和所属组都能读写，其他用户只读，比777安全得多。如果你之前运行过 php artisan config:cache，bootstrap/cache 下已有缓存文件，这次也要一并修正。
设置SGID避免后续权限反弹
实际运维中，经常用SSH用户（比如deployer）跑 git pull 或 artisan 命令，导致新生成的文件归属变成deployer，Web进程再次写不进去。可以在 storage 和 bootstrap/cache 上设SGID位，让新文件自动继承目录的所属组：chmod g+s storage bootstrap/cache。配合前面的775权限，后续不管是Web进程还是部署用户生成的文件，组内都能协同写入，减少反复修权限的麻烦。