hyperf 无内置批量修改限流策略，需按请求体条目数分档限流、结合租户/资源id构造分布式限流键，并在网关层前置拦截；禁用路由级注解，须校验 payload 大小并返回明确错误提示。
Hyperf 本身不内置针对「批量修改请求」的专用限流策略，但可通过组合框架能力实现精准、可控的限流控制。关键在于区分「接口维度」和「业务语义维度」——批量修改（如 /api/v1/users/batch-update）往往携带多个操作单元（如 50 条用户数据），单纯按请求次数限流（QPS）容易误伤或失效，需结合请求体内容、用户身份、资源粒度做分层限流。
按请求体数据量动态限流
对批量接口，实际压力常与 payload 大小或条目数正相关。可在中间件中解析 JSON body，提取关键指标并触发对应限流规则：
- 使用
Hyperf\HttpServer\Contract\RequestInterface获取原始 body，json_decode($request->getBody()->getContents(), true)解析后取count($data['items'] ?? []) - 配置多档阈值：例如 ≤10 条走宽松限流（如 100 次/分钟），11–50 条降为 20 次/分钟，>50 条直接拒绝并返回
429 Too Many Requests - 避免重复解析：将解析结果存入
$request->setAttribute('batch_size', $n)，供后续逻辑复用
基于用户+资源ID前缀的分布式限流
批量修改常涉及特定租户或业务域（如 tenant_id=123 或 project_id=abc）。此时应避免全局锁，改用带业务标识的限流键：
- 限流键构造示例：
rate_limit:batch_update:tenant_123或rate_limit:batch_update:user_ids_[1,5,8]（对 ID 数组做简单哈希或取前 3 个） - 推荐使用
hyperf/rate-limit组件，配合 Redis 驱动，设置key为闭包函数，动态生成带上下文的 key - 注意避免 key 过长或含敏感信息；ID 列表建议排序后拼接再 hash，保证一致性
在 Gateway 层前置拦截（适用于网关统一管控）
若已部署独立网关（非 hyperf/api-gateway，而是 Kong/Nginx/自研网关），应在入口层完成限流，避免请求触达业务服务：
- 提取请求头中的
X-User-ID或X-Tenant-Key，结合路径匹配^/api/.*/batch-.*$ - 配置 per-user 的滑动窗口限流（如 30 次/30 秒），比固定窗口更平滑
- 返回标准限流响应头：
Retry-After: 12、X-RateLimit-Limit、X-RateLimit-Remaining
补充：避免踩坑的关键细节
限流不是加个注解就完事，尤其对批量场景需特别注意：
-
不要依赖路由级注解限流：如
@RateLimit默认只认 URL 和方法，无法感知 body 内容，对批量接口形同虚设 -
拒绝未校验的超大 payload：在限流前先用
max_content_length（在server.php中配置）拦截 >5MB 的请求，防 DoS -
失败反馈要明确：返回 JSON 提示具体被限原因，例如
{"code":429,"message":"Batch size 62 exceeds limit 50 for tenant_123"}，方便前端降级或拆分重试
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
