thinkphp的throttle中间件默认只对显式绑定控制器方法的路由生效，因其实现依赖$route->getcontroller()提取controller+action生成限流key；闭包路由、未显式绑定的资源路由及route::any+闭包均无法获取该信息而直接跳过。
throttle 中间件默认只对显式绑定控制器方法的路由生效，闭包路由、资源路由未显式绑定、Route::any + 闭包全都不触发——这不是配置错误，是框架机制决定的。
throttle中间件为什么只认控制器绑定路由
ThinkPHP 的 throttle 中间件在执行时依赖 $request->rule() 和 $route->getController() 等信息生成限流 key。
它不是靠 URL 路径字符串匹配，而是靠路由解析后得到的「控制器+方法」组合来识别接口粒度。
-
Route::get('api/user', 'Api/UserController@index')✅ 可提取出Api/UserController@index，key 为throttle_7a8b9c...（含 controller+action） -
Route::get('api/user', function(){})❌ 没有 controller/action，$route->getController()返回 null，中间件直接跳过 -
Route::resource('posts', 'Api/PostController')❌ 默认不显式绑定方法，posts.index这类规则不会被throttle识别为独立接口 -
Route::any('api/data', [...])❌ 方法类型模糊，无法确定是否该计入 GET/POST 分开统计
所以你加了 ->middleware('throttle:60,1') 却没效果，大概率是因为路由没走控制器绑定路径。
为什么必须限制请求方法而非仅限 URL
同一 URL 支持多种 HTTP 方法时（如 GET /api/orders 查列表，POST /api/orders 提交订单），业务语义和资源消耗完全不同：
- GET 请求通常只读、可缓存、幂等；
- POST 请求可能写库、发消息、调第三方，资源消耗高得多；
- 若共用一个限流计数器，攻击者可用高频 GET 拖垮配额，再用 POST 绕过真实防护。
ThinkPHP 默认的 throttle 不区分方法，但你可以：
- 在自定义中间件里用
$request->method()拼进 key：rate_limit:{$ip}:{$route}:{$method} - 或改用
topthink/think-throttle扩展，它支持visit_method配置项，例如只对['POST', 'PUT']限流 - Nginx 层也可前置拦截：
limit_req zone=api_post burst=5 nodelay;配合if ($request_method = POST) { ... }
请求方法限制容易踩的坑
-
OPTIONS预检请求会被throttle计入——若你启用了 CORS 中间件且没把它放前面，预检失败会导致真实请求永远发不出去 -
Route::post('api/login', ...)和Route::any('api/login', ...)表面一样，后者实际允许任意方法，throttle无法按 method 区分 - 使用
application/json提交时，$request->param()会合并 GET/POST，但$request->method()仍准确，别混淆判断依据
真正起效的限流，从来不是“限制某个地址”，而是“限制某类操作在特定上下文中的发生频次”。
IP + 路由 + 方法 + 时间窗口，四个维度缺一不可——少一个，就可能被绕过。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
