ThinkPHP 路由限制请求方法须在 Route::rule() 中显式指定 method 参数，如 Route::rule('/api/login', 'LoginController@login', 'POST')，仅用 Route::get() 或 Route::post() 不足以阻止其他方法访问，需确保配置 'url_route_must' => true 生效。
ThinkPHP 路由里怎么限制只允许 POST 请求
直接在路由定义里加 method 参数就行，不是靠中间件或控制器判断。比如想让 /api/login 只响应 POST，就得在路由注册时明确声明，否则 GET 请求也能撞进来，后端逻辑可能误执行。
常见错误是写成这样：Route::get('/api/login', 'LoginController@login')，结果发现用 POST 也能访问——因为 get 方法只约束“注册为 GET 类型”，但不禁止其他方法；真正起过滤作用的是 rule 的 method 选项。
-
Route::rule('/api/login', 'LoginController@login', 'POST')—— 最简写法，第三个参数指定允许的请求方法 - 支持多个方法：
Route::rule('/api/user', 'UserController@save', ['POST', 'PUT']) - 如果用数组方式定义路由，必须显式传
'method' => 'POST'，不能只靠闭包或控制器方法名推断 - 注意：URL 规则匹配成功后，才校验 method；若规则没匹配上，根本不会走到这一步，所以优先级高于控制器里的
$this->request->isPost()
为什么用了 Route::post() 还能被 GET 访问
因为 Route::post() 是快捷方法，它只是把路由注册进 POST 方法组，并不自动开启“严格方法校验”。如果项目关闭了路由的 method 检查（比如配置了 'url_route_must' => false），或者用了兼容模式（url_common' => true），ThinkPHP 就会忽略 method，退化成按路径匹配后直接执行。
典型表现：浏览器直接打开 http://xxx.com/api/login（GET），接口照样返回数据，甚至执行了登录逻辑。
立即学习“PHP免费学习笔记（深入）”；
- 检查配置文件
config/route.php，确认'method_depr' => ''和'url_route_must' => true已启用 -
Route::post()底层等价于Route::rule(..., ..., 'POST')，但前提是路由必须走“规则路由”而非“普通 URL 解析” - 如果用了
bind或domain分组，要确保 method 限制写在分组内，而不是分组外漏掉
RESTful 路由中 method 冲突的真实场景
比如定义了 Route::resource('user', 'UserController')，它会自动生成 7 条路由，其中 user/:id 对应 GET（查看）和 DELETE（删除）。但如果前端发了个 GET 请求带了 ?_method=DELETE（模拟删），而你又开了 'var_method' => '_method'，ThinkPHP 就会把它当 DELETE 处理——这时候 method 校验就依赖请求头或参数，不是单纯看原始 HTTP 方法。
- 真实踩坑点：Nginx 或 CDN 可能重写或丢弃
X-HTTP-Method-Override头，导致_method参数失效，但路由仍按原始 GET 匹配，结果调用错方法 - 调试时用
php think route:list看实际注册的路由表，重点核对Method列是否符合预期 - 如果需要混合支持（如 API 兼容旧客户端），建议不用
_method，改用显式路径区分：DELETE /api/user/:id和GET /api/user/:id/detail
中间件里做 method 校验 vs 路由层校验哪个更可靠
路由层校验更早、更干净。中间件是在路由匹配成功之后才运行的，意味着 URL 已解析、参数已绑定、甚至模型查询都可能提前触发。一旦 method 不合法，前面这些开销白做了。
但有些动态场景绕不开中间件：比如权限系统要根据用户角色决定某个接口是否允许 PUT，这种没法写死在路由定义里。
- 静态限制（如“登录接口只能 POST”）一律写在路由定义里，性能高且意图清晰
- 中间件适合做“二次校验”，比如
if ($request->isPut() && !$auth->can('update_user')) { abort(403); } - 不要在中间件里重复写
$request->isPost()来替代路由限制——这是设计倒置，容易漏掉新路由或产生维护盲区
最麻烦的是混合使用：路由写了 POST，中间件又加了 isAjax() 判断，结果非 AJAX 的 POST 请求被拦在中间件，但开发者以为是路由没生效，来回排查半天。
