根本原因是web服务器进程无storage目录写权限，需用chown设正确属主（如www-data）并chmod 755/644，runtime目录同理，部署后须自动修复权限。
Storage 目录报 Permission denied 的根本原因
不是目录不存在，而是 Web 服务器进程（如 www-data、nginx 或 apache）没有对 storage 目录及其子目录的写权限。ThinkPHP 在运行时会往 storage/log、storage/cache、storage/framework 等路径写日志、缓存、模板编译文件，一旦权限不足，就会直接抛出 Permission denied 错误（常见于 file_put_contents()、mkdir() 调用失败时）。
典型错误现象：file_put_contents(/path/to/storage/logs/2024-05-15.log): failed to open stream: Permission denied，或框架启动时报 Unable to write to the "storage/framework/views" directory。
修复 storage 权限的实操步骤
别直接 chmod -R 777 storage —— 这是线上环境最常踩的坑，等同于裸奔。正确做法是让 Web 进程用户拥有所有权，并限制其他用户访问：
- 查当前 Web 进程用户：
ps aux | grep -E '(apache|httpd|nginx|php-fpm)'，常见为www-data（Ubuntu/Debian）、nginx（CentOS/RHEL）、或apache - 递归修改所有者：
sudo chown -R www-data:www-data storage（请按实际用户替换www-data） - 设置合理权限：
sudo find storage -type d -exec chmod 755 {} \;（目录可读可执行可进入）sudo find storage -type f -exec chmod 644 {} \;（文件仅可读） - 特别注意
storage/framework/cache和storage/framework/sessions：它们需要 Web 进程能创建新文件，所以确保父目录framework是755且属主正确
Runtime 目录（如 runtime/）也要一并处理
部分 ThinkPHP 版本（尤其是 5.1/6.x 自定义配置后）会把运行时目录指向 runtime/ 而非默认 storage/。如果改过 app.php 中的 'runtime_path' 配置项，就得同步处理该路径：
- 确认配置位置：
config/app.php中的'runtime_path' => APP_PATH . 'runtime' . DS, - 检查该路径是否存在、是否被
opcache.file_cache或 APCu 缓存了旧权限信息（重启 PHP-FPM 可解决） - 同样执行
chown -R www-data:www-data runtime+find runtime -type d -exec chmod 755 {} \; - 若使用 Docker，需在容器构建或启动时通过
USER指令或chown命令预设权限，不能依赖宿主机 chmod
CI/CD 部署或 Git 钩子后权限自动丢失怎么办
Git 默认不保存文件权限，git clone 或 git pull 后，storage 下的子目录可能变成 755 但属主仍是部署用户（如 deploy），导致 Web 进程无权写入。
- 上线脚本里必须包含权限修复命令，不要依赖“上次手动修过”
- 避免在
storage目录内做git init或提交 —— 它应该完全被.gitignore排除 - 如果用宝塔、AMH 等面板，注意其“一键部署”功能常忽略权限重置，需额外加钩子
- 测试是否真修复：用 Web 用户身份手动写个测试文件：
sudo -u www-data php -r "file_put_contents('storage/test.txt', 'ok');"，再删掉
真正麻烦的从来不是第一次赋权，而是每次部署后没人记得跑那行 chown。只要 storage 或 runtime 下任意一级目录属主错位，错误就立刻复现，而且不会报具体哪一层错了。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
