iris.limithandler不能直接限制post请求体大小，因为它仅校验content-length请求头且需在ctx.readbody等操作前生效，不流式校验、无法防御伪造头或multipart场景；应改用iris.limitrequestbody作为首中间件全局限流。
为什么 iris.LimitHandler 不能直接限制 POST 请求体大小
很多用户以为 iris.LimitHandler 能像 Nginx 的 client_max_body_size 那样拦截超大请求体，但实际它只对 Content-Length 头做校验，且必须在 ctx.ReadBody 或 ctx.FormValue 等读取操作前生效。如果路由没显式调用读取方法，中间件根本不会触发检查。
- 它不阻断 TCP 连接，也不流式校验上传流，纯靠 Header 判断 —— 所以伪造
Content-Length就能绕过 - 对 multipart/form-data 类型的文件上传无效，因为其真实长度在解析时才可知
- 若你用
ctx.ReadJSON()但没配iris.LimitHandler，超大 JSON 会直接 OOM，而不是返回 413
如何用 iris.LimitRequestBody 正确配置全局请求体上限
iris.LimitRequestBody 是更可靠的选择，它在请求进入路由前就检查 Content-Length，并主动拒绝超限请求（返回 413 Payload Too Large）。它必须作为第一个中间件注册，否则后续中间件可能已触发读取逻辑。
app.Use(iris.LimitRequestBody(2
- 值单位是字节，
2 比 <code>2097152更易读，也避免手误 - 该限制对所有路由生效，包括静态文件服务 —— 若需放行上传接口，得用
app.Party分离路由组 - 它不处理 chunked transfer encoding，遇到分块传输时
Content-Length为空，自动跳过检查
如何为特定路由组（如 /api/admin）添加 IP 访问频次限制
Iris 自带的 iris.LimitIP 可按秒/分钟/小时维度限制单个 IP 的请求数，但要注意它的计数器基于内存，重启即清零，不适合分布式部署。
admin := app.Party("/api/admin")
admin.Use(iris.LimitIP(100, time.Minute)) // 每分钟最多 100 次
- 第二个参数支持
time.Second、time.Minute、time.Hour，别传字符串或数字 - 它使用
net.ParseIP提取客户端 IP，默认信任X-Forwarded-For—— 如果你用 CDN 或反向代理，需先调用app.SetFirewall配置可信代理段 - 被限流时返回状态码 429，响应头含
Retry-After，前端可据此退避重试
为什么自定义中间件里调用 ctx.Next() 后不能再写响应
这是 Iris 的执行模型决定的：一旦 ctx.Next() 返回，说明后续中间件和 handler 已执行完毕，response writer 可能已被提交（ctx.ResponseWriter().Written() == true）。此时再调用 ctx.StatusCode() 或 ctx.JSON() 会 panic。
- 限流类中间件应在判断失败后立即
return，不要调用ctx.Next()；成功才放行 - 想统一处理错误？用
app.OnErrorCode(429, ...)注册回调，而非在中间件里覆盖响应 - 调试时可用
if ctx.ResponseWriter().Written() { fmt.Println("response already sent") }快速定位写冲突
Content-Length 是否可信、IP 是否经过代理清洗、计数器是否跨进程共享。这些细节不提前确认，上线后只会看到 413 和 429 错误混在一起，却找不到源头。
