ThinkPHP的runtime目录必须可写，否则缓存、日志、模板编译等功能失效，表现为白屏、登录失败、日志不生成及Permission denied错误；根本原因是Web服务用户与目录属主不匹配或SELinux/AppArmor拦截，须实测确认PHP运行用户（如www-data）、递归设置chown和755/644权限，并检查父目录执行权限及安全模块干预。
ThinkPHP 的 runtime 目录必须可写，否则缓存、日志、模板编译等关键功能全部失效，典型表现为白屏、登录失败、日志不生成、报 mkdir(): Permission denied 或 file_put_contents(): failed to open stream 错误。核心不是“权限数字不够”，而是 Web 服务进程用户与目录属主不匹配，或系统级安全策略（如 SELinux）拦截。
确认 PHP 实际运行用户
不能凭经验猜，必须实测：
- 在项目根目录建一个
whoami.php，内容为<?php echo exec('whoami'); ?>，通过浏览器访问，看输出用户名（如www-data、nginx、apache） - 终端执行
ps aux | grep -E '(php-fpm|httpd|apache2|nginx)'，看主进程 USER 列；PHP-FPM 用户还要查/etc/php/*/fpm/pool.d/www.conf中的user和group字段 - Nginx + PHP-FPM 架构下，
runtime必须归属 PHP-FPM 用户，不是 Nginx 用户
正确设置属主和最小权限
禁用 chmod 777——它不解决根本问题，还引入严重安全隐患：
- 递归修改属主：
sudo chown -R www-data:www-data runtime（把www-data换成你上一步确认的实际用户） - 设置目录权限为
755：find runtime -type d -exec chmod 755 {} \; - 设置文件权限为
644：find runtime -type f -exec chmod 644 {} \; - 若仍报错，检查
runtime的父目录（如project/、/var/www/）是否也具备x（执行）权限，否则 PHP 进程无法进入路径
排查 SELinux 或 AppArmor 干预
CentOS/RHEL 系统常见，Ubuntu/Debian 可能启用 AppArmor：
立即学习“PHP免费学习笔记（深入）”；
- 查看错误日志中是否有
avc: denied { write }（SELinux）或apparmor="DENIED"（AppArmor）字样 - 临时验证：执行
sudo setenforce 0（SELinux）或sudo systemctl stop apparmor（AppArmor），再测试写入是否恢复 - 永久修复（SELinux）：
sudo semanage fcontext -a -t httpd_sys_rw_content_t "/path/to/project/runtime(/.*)?"，然后sudo restorecon -Rv /path/to/project/runtime
Windows 与容器环境特别注意
权限逻辑与 Linux 不同，需针对性处理：
- Windows（XAMPP/MAMP/IIS）：右键
runtime文件夹 → 属性 → 安全 → 编辑 → 添加当前登录用户或IIS_IUSRS/Everyone→ 勾选“修改”和“写入”；取消“只读”属性并应用到子项 - Docker：确保
runtime目录挂载为 volume，且宿主机对应目录 UID/GID 与容器内 PHP 用户一致；避免挂载 WSL 路径（如/mnt/c/） - CI/CD 部署后失效：检查发布脚本是否以
root打包，导致runtime归属变为root；应在部署末尾加chown步骤
