PHP实际运行用户是Web服务器进程（如www-data、apache、nginx）或PHP-FPM所配置的用户，而非Shell登录用户；需通过ps aux | grep相关进程或创建whoami.php访问确认，且runtime目录必须chown归属该用户而非仅chmod。
确认PHP实际运行用户是谁
权限问题的根源往往不是目录没设对，而是你改权限时用的用户和PHP真正干活的用户不一致。Web请求走的是Apache/Nginx/PHP-FPM进程，不是你登录Shell的账号。
Linux/macOS下直接跑：ps aux | grep -E '(apache|httpd|nginx|php-fpm)'，看USER列；Windows查IIS应用池标识或Apache服务“登录”选项卡里的账户名（常见IIS_IUSRS或SYSTEM）。
更稳妥的方式是建个whoami.php文件，内容为，用浏览器访问它——输出结果才是真实执行用户。
别信get_current_user()，它返回的是脚本所有者，不是进程运行者。
runtime目录必须chown，不能只chmod
chmod 755只是控制“谁能做什么”，chown才决定“谁说了算”。ThinkPHP写缓存、日志、路由文件，全靠Web进程用户对runtime目录拥有所有权。
操作顺序很重要：
- 先清空旧目录：
rm -rf runtime/（Linux/macOS）或手动删空（Windows） - 重建目录：
mkdir runtime - 赋权：
sudo chown -R www-data:www-data runtime/（Ubuntu）或sudo chown -R apache:apache runtime/（CentOS） - 再补权限：
sudo chmod -R 755 runtime/
Windows上右键runtime → 属性 → 安全 → 编辑 → 添加对应用户（如IIS_IUSRS）→ 勾选“完全控制”→ 应用。
避免chmod -R 777，SELinux或安全模块可能直接拒绝，且线上环境有风险。
检查open_basedir是否拦住了runtime路径
即使目录权限全对，PHP也可能因为open_basedir白名单没包含runtime路径而报“Permission denied”。
查配置位置：php.ini、虚拟主机配置、或宝塔面板PHP设置页，找这行：
open_basedir = /var/www/html:/tmp
如果runtime在/var/www/myapp/runtime，就得把它加进去：
open_basedir = /var/www/html:/var/www/myapp/runtime:/tmp
Docker环境还要额外检查：volumes挂载路径是否用了绝对路径，宿主机目录是否对容器内用户（如www-data）可写；WSL环境下，Windows与Linux子系统间文件所有权不会自动同步，得在WSL里重新chown。
umask影响子目录权限，别只盯着父目录
ThinkPHP运行时会动态创建runtime/cache/12/34/这类多层子目录，它们的权限由系统umask决定，不是你手动chmod一次就能一劳永逸的。
默认umask 0022生成的目录权限是755，但如果Web用户不是所有者，组和其他人只有读+执行权，没法写入——这就是为什么有时你chown了父目录，子目录还是不可写。
验证当前值：php -r "echo umask();"，输出2即0002，输出18即0022。
生产环境建议在PHP-FPM池配置中统一设：php_admin_value[umask] = 0002，比在入口文件里临时umask(0002)更可靠。
容器或宝塔环境下，权限错位高频发生：宝塔默认用www用户，但PHP进程可能跑在www-data下；Docker挂载时UID/GID不匹配——这些细节容易被跳过，但恰恰是反复报错的根源。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
