Yii2 的 isGet() 和 isPost() 仅比对 $_SERVER['REQUEST_METHOD']，不支持 method spoofing、不校验 Content-Type、在 CLI 下返回 false；RESTful 场景须用 getIsMethod('PUT') 等；需手动存“上一请求类型”，视图层不应调用。
Yii2 中 isGet 和 isPost 的实际行为是什么
这两个方法不是“检查 HTTP 方法字符串是否等于 GET/POST”，而是调用 getIsMethod() 并传入大写字符串，最终比对的是 $_SERVER['REQUEST_METHOD'] —— 所以它们只认原始请求方法，不处理重写、代理转发或表单伪造的伪装请求。
常见错误现象：isPost() 在 AJAX 提交时返回 false，但你确认前端发的是 POST；原因很可能是前端用了 method: 'post' 却没设 contentType，导致 Yii 把它当成了 GET（因某些中间件或 Nginx 配置误判）。
- 它们不感知
_method参数（即不支持 method spoofing） - 不校验 Content-Type，哪怕请求体是空的，只要
REQUEST_METHOD === 'POST'就返回 true - 在 CLI 环境下（如 console command 调用 request 对象），
REQUEST_METHOD为空，两个方法都返回false
什么时候该用 isGet() / isPost()，什么时候该用 getIsMethod('PUT')
如果你只处理标准 GET/POST，用 isGet() 和 isPost() 更简洁；但一旦涉及 RESTful 场景（比如 API 接口要区分 PUT/PATCH/DELETE），就必须用 getIsMethod('PUT') 或 getIsMethod('PATCH') —— Yii 没提供 isPut() 这样的快捷方法。
使用场景差异：
- 表单提交判断：用
isPost()安全，因为表单原生只支持 GET/POST - API 控制器动作分发：必须用
$request->getIsMethod('DELETE')，否则无法匹配 DELETE 请求 - CSRF 验证前的请求类型过滤：别只靠
isPost()，得配合getIsAjax()或自定义头判断，防止伪造
isGet() 在重定向后失效？注意请求上下文切换
Yii 的 Request 对象是单例，但它的状态依赖于当前 PHP 请求生命周期。如果在控制器中先执行了 return $this->redirect(...)，再调用 isGet()，结果仍反映**当前跳转后的 GET 请求**，而不是跳转前那个 POST —— 很多人误以为能“回溯”上一个请求类型。
容易踩的坑：
- 在
actionCreate()里用if ($request->isPost()) { ... } else { $this->redirect(...) }，重定向后用户看到的是新 GET 请求，isGet()返回 true，但这和原始业务逻辑无关 - 想保存“上一次请求类型”做流程控制？得自己存到 session 或 flash，不能依赖
Request对象跨请求记忆 - 测试时用
createRequest()模拟请求，记得手动设置setMethod('POST')，否则默认是 GET
兼容性与性能影响：这些方法几乎无开销，但别在循环里反复调用
isGet() 和 isPost() 内部只是字符串比较，没有 IO、无数据库查询、不触发事件，性能可忽略。但它们每次调用都会重新读取 $_SERVER['REQUEST_METHOD'] —— 虽然这个值本身是 PHP 内置超全局变量，非常快，但在高频循环（比如批量处理请求头的中间件）里反复调用仍是冗余。
建议做法：
- 在 action 开头一次性判断并赋值给局部变量：
$isPost = $request->isPost(); - 不要在 view 层或 widget 中调用这些方法 —— 视图不该决定请求类型逻辑，应由 controller 提前传参
- 升级到 Yii3 后注意：
isGet()已被移除，统一用$request->getMethod() === 'GET'，老项目迁移时要扫一遍
最常被忽略的一点：它们不校验请求是否可信。即使 isPost() 返回 true，也不能代表数据来自你的表单 —— CSRF token、input name 过滤、参数白名单一个都不能少。
