应优先用 $request->isget() 和 $request->ispost() 判断 http 方法，但需注意其不校验数据来源；禁用伪装请求或显式处理 x-http-method-override；isajax() 依赖 x-requested-with 头，现代前端需手动设置；cli 环境下所有 isxxx() 均返回 false，应通过 php_sapi_name() === 'cli' 显式判断。
如何准确判断当前请求是 GET 还是 POST
ThinkPHP 的 $request->isGet() 和 $request->isPost() 是最直接的方式，但它们只检测 HTTP 方法，不校验实际数据来源。比如用 curl -X POST 发送空体，isPost() 仍返回 true；而前端用 GET 提交表单（method="get"），isGet() 才为 true。
真正容易出错的是：混淆「请求方法」和「是否有提交数据」。例如用户以为 isPost() 能防刷新重复提交，其实不能——F5 刷新 POST 页面时，浏览器会重发原始请求，isPost() 依然为 true。
- 优先用
$request->isGet()/$request->isPost()判断协议层方法，别依赖input('post.') || input('get.') - 需要区分“有无有效提交”时，应额外检查关键参数是否存在，比如
!empty(input('username')) - 在 API 场景下，有些客户端用 POST 发 JSON，但没设
Content-Type: application/json，此时isPost()为 true，但input()可能取不到值 —— 要确认中间件是否已启用Json.php解析
为什么 $request->method() 返回的不是你看到的请求方式
ThinkPHP 默认开启「伪装请求」支持，即允许通过 _method=PUT（GET 参数）或 X-HTTP-Method-Override: DELETE（Header）来覆盖真实 method。所以 $request->method() 返回的是“被伪造后的结果”，而 $request->server('REQUEST_METHOD') 才是原始值。
这在前后端分离项目中特别容易踩坑：前端发了个 PUT 请求，但 Nginx 或 CDN 把它转成了 POST + Header，后端却按 method() 当成 PUT 处理，路由匹配失败或中间件逻辑错乱。
- 调试时先打日志：
dump($request->method(), $request->server('REQUEST_METHOD')) - 禁用伪装请求：在
config/app.php中设置'var_method' => false - 若必须保留伪装，注意
Route::rule()定义资源路由时，默认只响应真实 method，需显式加['method' => ['PUT', 'POST']]才兼容伪造请求
isAjax() 和 isPjax() 判定失效的常见原因
$request->isAjax() 实际检查的是 X-Requested-With: XMLHttpRequest 这个 header，而不是看 URL 是否含 /api/ 或是否返回 JSON。很多现代前端库（如 axios、fetch）默认不带这个 header，导致明明是 Ajax 请求，isAjax() 却返回 false。
isPjax() 同理，依赖 X-PJAX: true，但 pjax.js 2.0+ 已默认改用 X-PJAX-Container，旧版 ThinkPHP 的判定逻辑可能不匹配。
- axios 请求需手动加 header：
headers: {'X-Requested-With': 'XMLHttpRequest'} - fetch 不支持自动设该 header，必须用
new Headers({ 'X-Requested-With': 'XMLHttpRequest' }) - 如果用 Vue Router history 模式 + 后端渲染，
isPjax()几乎无效，建议改用自定义 header 如X-Render-Mode: pjax并自行判断
CLI 请求下 isGet() isPost() 全都返回 false 怎么办
命令行执行 php think hello 时，$_SERVER['REQUEST_METHOD'] 根本不存在，ThinkPHP 的请求类初始化后，所有 isXxx() 方法因缺少上下文而统一返回 false。这不是 bug，是设计使然 —— CLI 本就不属于 HTTP 请求生命周期。
如果你在命令行里调用了本该用于 Web 的控制器方法，又依赖 isPost() 做分支逻辑，就会跳进默认分支或报错。
- 不要在 Command 类中复用 Controller 的请求判断逻辑
- 需要区分调用来源时，用
php_sapi_name() === 'cli'显式判断运行环境 - 通用做法：把业务逻辑抽到 service 层，Controller/Command 分别封装输入适配，避免条件判断散落在各处
请求类型的判断本质是上下文还原，不是字符串匹配。越想靠一个函数兜底，越容易在反向代理、HTTP/2、Server-Sent Events 这些场景里翻车。留心 method 伪造、header 缺失、运行环境切换这三个点，比背熟所有 isXxx 方法更重要。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
