应使用 $request->method(true) === 'POST' 判断原始 HTTP 方法，因 isPost() 默认识别 _method 伪装而不可靠；推荐表单用 isPost() && !empty(post())，API 用 method(true) === 'POST'。
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 可能被丢弃。不要只依赖单一判断。
立即学习“PHP免费学习笔记（深入）”；
- 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()，务必确认这些配置没被静默覆盖。
