绝大多数情况是请求被中间件或Web服务器提前拦截：先查urlManager和accessControl配置，再看Apache/Nginx是否放行非GET方法，最后排查RBAC规则。
Yii RESTful 接口返回 403，绝大多数情况不是权限系统本身出错，而是请求被中间件或 Web 服务器提前拦截了——先查 urlManager 和 accessControl 配置，再看 Apache/Nginx 是否放行非 GET 方法，最后才排查 RBAC 规则。
为什么 POST/PUT/DELETE 请求全 403，但 GET 正常？
若依、Yii2 默认安全配置中，accessControl 的 antMatchers 往往只写了 GET 路径放行，漏掉其他动词：
-
antMatchers(HttpMethod.GET, "/api/**").permitAll()—— 这行存在，但没写POST、PUT对应的规则 - 实际请求是
POST /api/user，却被当成未授权路径直接拒掉，连控制器都没进 - Apache 的
.htaccess或 Nginx 的limit_except块也可能禁用非 GET 方法（尤其 MAMP/XAMPP 默认配置）
解决方法：在 config/web.php 的 as access 或自定义行为中补全动词，例如：
'rules' => [
[
'actions' => ['index', 'view'],
'allow' => true,
'verbs' => ['GET'],
],
[
'actions' => ['create', 'update', 'delete'],
'allow' => true,
'verbs' => ['POST', 'PUT', 'DELETE'],
],
],
gii 页面提示 “You are not allowed to access this page”
这是 Yii 内置的 IP 白名单机制触发的，gii 模块默认只允许 127.0.0.1 和 ::1 访问，哪怕你在本地用 localhost 或 192.168.x.x 打开也会 403。
- 检查
config/main.php中gii模块的ipFilters配置项 - 开发环境可临时放开：
'ipFilters' => ['127.0.0.1', '::1', '192.168.0.0/16'] - 生产环境严禁删掉
ipFilters或设为['*']，否则 gii 后台将暴露在公网 - 注意：修改后需清空
runtime/cache/下的配置缓存，否则改动不生效
Web 服务器返回 “403 Forbidden You don't have permission to access / on this server”
这个错误来自 Apache/Nginx，和 Yii 代码完全无关。常见于 MAMP、XAMPP 或手动配虚拟主机时目录权限未正确开放。
- Apache：确认
<Directory>块中包含Require all granted（Apache 2.4+），而非旧版的Allow from all - Nginx：检查
location /块是否遗漏try_files $uri $uri/ /index.php?$args;，否则静态资源路径可能误触发 403 - MAMP 特别注意：在
httpd-vhosts.conf中，DocumentRoot对应的目录必须在<Directory "xxx">中显式授权，且路径末尾不能多斜杠 - Linux 系统下还要确认 web 用户（如
www-data）对web/目录有rx权限，对runtime/有rwx
RBAC 权限已分配，但接口仍 403
若依或自建 RBAC 中，403 很可能是权限标识（permission name）前后端不一致导致的静默拒绝。
- 前端请求头带的
X-Access-Token或 session 中的角色 ID，是否真被后端正确解析并关联到角色？ - 检查数据库
auth_assignment表，确认该用户 ID 对应的角色名存在于auth_item中，且未被禁用（status = 1） - 若使用 Redis 缓存权限数据，
yii\rbac\DbManager不会自动刷新，必须手动执行php yii rbac/flush或清 Redis 中rbac:*:key - 若控制器用了
@VerbFilter或自定义beforeAction()，优先级高于 RBAC，容易覆盖权限判断逻辑
最易忽略的一点：Yii 的 AccessControl 是「白名单优先」，只要某条规则匹配且 allow => false，就会立刻 403，根本不会走到 RBAC 层。务必逐条检查 rules 数组顺序和条件表达式。
