Laravel权限错误根源是PHP CLI用户对目录无读写执行权限，需分步修复属主、目录x权限、文件r/w权限及Web用户组协同，并绕过macOS Gatekeeper/SIP限制。
权限不足是 Laravel 项目中最常触发“Permission denied”“failed to open stream”“mkdir(): Permission denied”这类报错的根源，本质是 PHP CLI 进程（你执行 php artisan 时的用户）对目标目录或文件没有读、写或执行权限。处理关键不是盲目加 777，而是理清属主、组、目录执行位（x）和 Web 用户协同读取这四层关系。
确认当前 CLI 用户与目录属主是否一致
在终端运行：
-
whoami查看当前登录用户名（如john） -
ls -ld storage bootstrap/cache public/storage观察各目录第一列（属主）是否与whoami输出一致 - 若显示
root:root或其他用户，说明曾误用sudo php artisan，导致部分目录被 root 占据，后续普通用户无法写入
重置 storage 和 cache 目录权限链
storage 是日志、缓存、session 的核心目录，权限断裂往往出现在某一层缺 x（进入权限）。执行以下命令分步修复：
- 重设属主（macOS 用
staff组，Linux 常用www-data或nginx）：sudo chown -R $USER:staff storage bootstrap/cache - 确保所有子目录可进入（
x权限必须）：find storage bootstrap/cache -type d -exec chmod 755 {} \; - 确保日志和缓存文件可读写：
find storage/logs storage/framework/cache -type f -exec chmod 644 {} \; - 若
storage/logs/laravel.log存在且属主为 root，直接删除：rm storage/logs/laravel.log，再运行php artisan log:clear让系统重建
解决 public/storage 软链接与 Web 服务器读取冲突
CSS/JS 加载失败、图片 403，常因 Web 服务器（如 nginx）用户无法读取 storage/app/public 内容。验证并修复：
- 检查软链接有效性：
ls -la public/storage，应显示指向../storage/app/public - 模拟 Web 用户读取（Linux）：
sudo -u www-data ls -l storage/app/public/css/；macOS 则用sudo -u _www - 若报错，说明 Web 用户对该路径无
r-x权限，需补全组权限：sudo chgrp -R staff storage/app/publicsudo chmod -R g+rx storage/app/public
绕过 macOS Gatekeeper/SIP 对脚本和目录的拦截
macOS 下 artisan 报错或文档生成失败，可能因 Gatekeeper 拦截或 SIP 保护临时目录：
- 确保
artisan可执行：ls -l artisan应含x，否则运行chmod +x artisan - 若双击提示“已损坏”，右键 → “打开” → 点“打开”放行一次
- 确认使用 Homebrew 版 PHP：
which php应为/opt/homebrew/bin/php（Apple Silicon）或/usr/local/bin/php（Intel）；不对则重链：brew unlink php@8.2 && brew link php@8.2 - 清理缓存并重设 storage 组权限：
php artisan config:clear && php artisan cache:clearsudo chgrp -R staff storage && sudo chmod -R ug+rwx storage && sudo chmod -R g+s storage
