Request::method() 返回当前请求的原始 HTTP 方法名（大写全称，如 GET、POST），源自 $_SERVER['REQUEST_METHOD']；默认不解析 _method 伪造，启用 MethodFilter 中间件后才支持 POST 提交时通过 _method 参数覆盖方法。
Request::method() 返回的是什么？
它返回的是当前请求的 HTTP 方法名，字符串类型，比如 GET、POST、PUT、DELETE。注意：不是小写，也不是全大写缩写（如 post 或 P），而是标准的大写全称。
这个值来自服务器变量 $_SERVER['REQUEST_METHOD']，ThinkPHP 默认不做转换或映射，所以只要 Web 服务器（如 Nginx/Apache）正确传递了该字段，结果就可靠。
常见误用是以为它能识别伪静态路由伪装的请求方式（比如 POST 提交但 URL 带 ?_method=PUT），其实默认不处理 —— 那属于表单伪造方法，需要额外配置才能生效。
想支持 _method 参数伪造请求方式怎么办？
ThinkPHP 6+ 默认关闭对 _method 表单参数的支持，必须手动启用中间件 think\middleware\MethodFilter，否则 Request::method() 永远不会返回 PUT 或 DELETE，哪怕你提交了 _method=PUT。
立即学习“PHP免费学习笔记（深入）”；
启用方式很简单，在应用中间件配置里加上：
// app/middleware.php
return [
\think\middleware\MethodFilter::class,
];
启用后，Request::method() 就会优先检查请求体（POST）或查询参数中的 _method 字段，并以它为准（仅当原始请求为 POST 时才触发）。
- 原始请求是
POST，且含_method=PUT→ 返回PUT - 原始请求是
GET，即使带_method=DELETE→ 仍返回GET（不生效） - 原始请求是
PUT，同时带_method=PATCH→ 仍返回PUT（_method只在 POST 下覆盖）
在控制器里怎么安全地判断请求类型？
别只靠 Request::method() === 'POST' 做逻辑分支，尤其涉及数据修改时。真实场景中更推荐组合判断：
- 用
$request->isPost()替代硬比较字符串，语义清晰且兼容未来可能的内部调整 - 对 RESTful 接口，优先用
$request->isPut()、$request->isDelete()等快捷方法，它们已内置_method解析逻辑（前提是启用了 MethodFilter） - 如果自己解析 JSON 请求体，注意
Request::method()仍是POST，但业务上可能是「模拟 PUT」，此时应结合 Content-Type 和实际 payload 判断
例如前端发 Content-Type: application/json + PUT，Nginx 若未正确透传 REQUEST_METHOD，Request::method() 可能错误返回 POST —— 这类问题要查服务器配置，不是框架问题。
为什么有时候 Request::method() 总是 GET？
最常见三个原因：
- Nginx 配置漏掉了
fastcgi_param REQUEST_METHOD $request_method;，导致 PHP 收不到真实方法 - 用了 curl 或测试工具但没显式指定 -X 选项（如
curl -X PUT），默认就是 GET - 前端用 form 提交却没设
method="POST"，浏览器按规范回退为 GET
调试时直接打印 $_SERVER['REQUEST_METHOD'] 最快，如果它已经是错的，那就不用怀疑 ThinkPHP —— 框架只是读取它。
另外，Swoole 或 Workerman 环境下，如果自定义了 Request 实例但没正确设置 method 属性，Request::method() 也会失真，这时得检查实例化逻辑是否调用了 withMethod()。
