应将runtime目录属组设为Web服务器用户（如www-data），赋予g+rwxs权限，并确保父目录有g+rx权限，而非简单chmod 777；需通过ps或配置文件确认真实Web用户，关闭debug模式验证，排查SELinux或Docker权限限制。
直接给 runtime 目录加 chmod 777 是常见但危险的做法，多数情况下也解决不了问题——真正卡住的是 Web 服务器用户（如 www-data 或 nginx）没被正确赋予组权限，或父目录缺少执行位（x），导致进程根本进不去目录。
确认 Web 服务器运行用户是谁
别猜，用命令查真实用户：
- Nginx（Ubuntu/Debian）：通常是
www-data；CentOS/RHEL 多为nginx - Apache：常见是
www-data（Debian系）或apache（RHEL系） - PHP-FPM：检查
ps aux | grep php-fpm的 USER 列，或看/etc/php/*/fpm/pool.d/www.conf中的user和group
正确设置 runtime 权限（三步法）
核心不是数字权限，而是「属组 + sgid + 父目录可进入」：
- 把
runtime目录属组设为 Web 用户组：sudo chgrp -R www-data /path/to/yii2/basic/runtime - 加写权限并开启 sgid（保证新生成子目录自动继承组）：
sudo chmod -R g+rwxs /path/to/yii2/basic/runtime - 确保上层路径（如
basic/、basic/web/）对组有r-x权限，否则 Web 进程无法遍历进入：sudo chmod g+rx /path/to/yii2/basic和/path/to/yii2/basic/web
验证是否真生效
别只看开发模式下有没有报错，它会掩盖权限问题：
- 临时关闭 debug：
YII_DEBUG=false php index.php或改index.php中定义 - 访问首页或任意页面，观察是否出现 500 错误或空白资源（比如 JS/CSS 404）
- 检查日志：
cat runtime/logs/app.log | grep "Permission denied" - 清空 OPcache 或 APCu 缓存，避免旧行为干扰
特别注意 SELinux 和 Docker 场景
在 CentOS/RHEL 上，即使权限全对，SELinux 也可能拦截写入：
- 临时测试：
sudo setenforce 0，若问题消失，说明是 SELinux 导致 - 永久修复：
sudo chcon -R -t httpd_sys_rw_content_t /path/to/yii2/basic/runtime - Docker 环境：确保挂载 volume 时指定了正确用户（如
user: "www-data"），且宿主机对应目录属组匹配
