根本原因是PHP进程用户与storage目录属主/属组不匹配，需先用ps或posix_getpwuid确认实际运行用户，再chown -R 用户:用户组 storage/ 和 bootstrap/cache/，并设目录755、文件664。
PHP 写入 storage 目录失败，根本不是权限数字没设够，而是 PHP 进程用户和目录属主/属组不匹配——改错对象比改错数字更致命。
确认 PHP 实际运行用户（不是你登录的用户）
用 ps aux | grep php-fpm 或 ps aux | grep apache2 查看 worker 进程启动用户。宝塔常见的是 www、www1 或 nginx；Ubuntu/Debian 通常是 www-data；macOS 是 _www。别猜，必须查。如果站点启用了独立 php-fpm 池，用户可能和全局设置不同，www1 和 www 不通用。
验证方式：在项目里放一个临时 PHP 文件，写 print_r(posix_getpwuid(posix_geteuid()));，访问它看输出的 name 字段。
chown 必须对准 PHP 用户，且同时指定用户和组
只改 chown www:www storage/ 不够，漏掉 bootstrap/cache 就会缓存生成失败；只改用户不改组（如 chown www storage/），在 umask 为 0022 的环境下，新文件默认无组写权限，Laravel 日志轮转或 session 写入仍报错。
立即学习“PHP免费学习笔记（深入）”；
chown -R www:www /www/wwwroot/your-project/storagechown -R www:www /www/wwwroot/your-project/bootstrap/cache- 若用户是
www1，必须用www1:www1，不能混用 - macOS 下对应
_www:staff，staff是你的用户所在组，确保继承可写
chmod 要区分目录和文件，且需保留组写位
Laravel 不仅要读，还要创建子目录、重命名日志、写 session 文件——这意味着目录必须有 x（进入权限）和 w（写权限），文件需要 w 才能覆盖。755 对目录够用，但 644 对文件不够，因为 Laravel 经常要 file_put_contents(..., FILE_APPEND)，这要求文件本身可写。
- 目录统一用
755：find storage -type d -exec chmod 755 {} \; - 文件统一用
664（保留组写）：find storage -type f -exec chmod 664 {} \; -
bootstrap/cache整个目录建议chmod -R 755，因为 Laravel 会往里面写.php缓存文件，需要执行权限 - 避免
777：多数生产环境（尤其启用了 SELinux 或容器）会直接拦截该权限，报错反而更难排查
open_basedir 和禁用函数也会伪装成权限错误
即使 chown 和 chmod 全对，file_put_contents 仍报 Permission denied，大概率是 open_basedir 没包含 storage 路径，或宝塔 PHP 设置中禁用了 putenv（Laravel 启动时会调用）。
- 检查宝塔面板 → 网站 → 设置 → PHP 版本 → 配置修改 → 搜索
open_basedir，确保值包含/www/wwwroot/your-project/storage/:/www/wwwroot/your-project/bootstrap/cache/ - 同页面检查「禁用函数」列表，删掉
putenv、pcntl_alarm（虽不直接写文件，但某些 Laravel 组件初始化时触发检测） - 重启 php-fpm：
systemctl restart php-fpm或在宝塔界面点「重载配置」
最容易被忽略的是：父目录缺少执行位（x）。比如 /www/wwwroot/your-project 权限是 750，而属组不是 www，那即使 storage 是 775，PHP 用户也进不去——ls -ld /www/wwwroot/your-project 必须能看到组有 r-x。这个层级关系，比改 storage 本身还关键。
