yii框架中restful与普通控制器可共存，但需将enablestrictparsing设为false或分离urlmanager配置；否则rest规则会拦截未匹配请求导致404。
Yii 框架的 RESTful 接口不适合与普通控制器混用在同一 URL 管理器配置下，除非你主动规避其路由冲突机制。根本原因不是功能不兼容，而是 yii\rest\UrlRule 在 enableStrictParsing => true 时会「吃掉所有未匹配的请求」，导致普通控制器路由失效。
enableStrictParsing 开启后，普通控制器路由直接 404
yii\rest\UrlRule 的设计目标是「接管整个资源路径空间」。当它启用且 enableStrictParsing => true 时，Yii 会在路由解析阶段做两件事：
- 尝试将当前请求 URI 匹配到任一注册的 REST 控制器（如
user、post） - 若不匹配，立即返回 false，不再继续尝试其他规则（包括你手动写的
['pattern' => 'video/upload', 'route' => 'video/upload']）
这就造成：
-
GET /users→ 正常走UserController -
GET /video/upload→ 被 REST rule 拦截、判定不匹配、直接抛出 404
常见错误现象：
-
GET /video/upload报错Not Found: Page not found. - Gii、debug toolbar 等后台工具打不开（它们的路由也被 REST rule 拦截了）
- 日志里看不到普通控制器的 action 调用痕迹
解决办法只有两个：
- 关闭严格解析：
'enableStrictParsing' => false（推荐开发/调试期） - 或把 REST rule 和普通 rule 分开管理（见下一条）
混合使用必须拆分 urlManager 规则层级
如果你既要 /api/v1/users 这类 RESTful 路径，又要保留 /admin/login、/video/upload 这类传统 Web 路由，就不能让它们共用一个 urlManager 实例。
正确做法是：
- 为 API 单独建一个模块（如
api应用），配置独立的urlManager - 主应用（
frontend或backend）保持普通路由，不引入yii\rest\UrlRule - 前端通过域名或路径前缀区分流量：
@#@#@#@#@#@#@#@#@#@0→ 走 api 应用@#@#@#@#@#@#@#@#@#@1→ 走 frontend 应用
这样做的好处：
- 避免路由优先级打架
- 可分别配置认证方式（JWT for API，session for Web）
- 日志、中间件、CORS 策略可按需隔离
注意：别在同一个应用里塞两种 rule 并指望 Yii 自动“聪明分流”——它不会。
yii\rest\ActiveController 的行为默认禁用 HTML 渲染
即使你强行让普通控制器和 REST controller 共存，也会遇到内容格式问题。
yii\rest\ActiveController 默认注册了 ContentNegotiator 行为，它会强制：
- 忽略
Accept: text/html - 所有响应都转成 JSON（哪怕你 return $this->render('index')）
- 400+ 错误也走 JSON 格式，不渲染 error view
这意味着：
- 如果你在同一个控制器里混写
return $this->render(...)和return $model;，后者会生效，前者静默失败 - 普通控制器若没显式设置
Response::FORMAT_JSON，返回数组会被当成 PHP 数组打印，不是 JSON 字符串
所以混合使用的真正难点不在路由，而在响应格式不可控。你要么统一 JSON，要么彻底分开控制器职责。
RESTful 和普通控制器混合部署不是技术禁区，但代价是显式的架构切分和额外的运维负担。多数团队踩坑后发现：与其花时间绕过 Yii 的路由设计哲学，不如用模块化把 API 和 Web 流量物理隔离。真正的复杂点从来不是“能不能”，而是“值不值得为临时需求破坏边界清晰性”。
