ThinkPHP如何替换已废弃的请求类型检测_使用Request方法判定技巧-ThinkPHP-PHP中文网

应使用 $request->method(true) === 'post' 判断原始 http 方法，因 ispost() 默认识别 _method 伪装而不可靠；推荐表单用 ispost() && !empty(post())，api 用 method(true) === 'post'。

thinkphp如何替换已废弃的请求类型检测_使用request方法判定技巧

ThinkPHP 5.1+ 中 input('method') 或 $request->method() 已不能直接用于判断「是否为 POST 请求」这类业务逻辑，因为底层不再自动过滤伪造的 HTTP_METHOD_OVERRIDE 或 _method 参数 —— 这不是 bug，是安全加固后的预期行为。

为什么 `$request->isPost()` 返回 false 却实际收到 POST 数据

常见于表单提交或 AJAX 调用后，$request->isPost() 返回 false，但 $request->post() 能取到数据。根本原因是：TP6 默认启用「方法伪装」（var _method=PUT），且 isPost() 只校验原始请求的 HTTP 方法（即 $_SERVER['REQUEST_METHOD']），不关心请求体内容。

如果你用 fetch('/api', {method: 'POST', body: 'a=1'})，$request->isPost() 为 true
如果你用 fetch('/api?_method=PUT', {method: 'POST'})，$request->isPost() 仍为 true（因为原始 method 是 POST）
但如果你用 curl -X PUT 直接发请求，$request->isPost() 就是 false，哪怕你同时带了 Content-Type: application/x-www-form-urlencoded 和表单数据

替换废弃的 `input('server.REQUEST_METHOD')` 的安全写法

旧项目常写 input('server.REQUEST_METHOD') === 'POST'，这在 TP6+ 中依然能用，但绕过了框架的请求对象封装，丢失了中间件、Hook 和统一过滤能力。应优先走 $request 实例。

判断原始 HTTP 方法（最严格）：$request->method(true) —— 第二个参数 true 表示「不解析伪装」
判断业务语义上的「提交动作」（推荐）：$request->isMethod('post') 或 $request->isPost()，它们默认会识别 _method 参数，但仅当配置开启方法伪装时才生效（'var_method' => '_method'）
若需排除伪装、只信原始头：$request->method(true) === 'POST'，这是最接近旧 input('server.REQUEST_METHOD') 的等价写法

兼容 TP5.1 / TP6 / TP8 的判定组合建议

不同版本对 isPost() 的实现细节有差异，尤其涉及 CLI 环境、Swoole 长连接、或 Nginx 配置了 underscores_in_headers off 时，_method 可能被丢弃。不要只依赖单一判断。

Web 表单提交场景：用 $request->isPost() && !empty($request->post())，双重保险
API 接口（明确要求 POST）：用 $request->method(true) === 'POST'，禁用伪装更可控
需要支持 PUT/PATCH 但又允许 POST 伪装：显式检查 $request->param('_method', '', 'strtolower') === 'post'，再配合 $request->isPost()
注意：TP8 中 $request->method() 默认返回大写（如 'POST'），而 TP5.1 某些补丁版本可能返回小写，比较时别漏掉 strtoupper()

真正容易被忽略的是：isPost() 的行为受 Request 类构造时传入的 $options 影响，尤其是 'var_method' 和 'method_filter'。如果项目自定义了 Request 类或重写了 initialize()，务必确认这些配置没被静默覆盖。