iris.Context 是请求响应流的唯一枢纽，所有读写操作都必须经它中转；直接使用 *http.Request 或 http.ResponseWriter 会跳过自动解码、表单解析、响应缓冲等关键逻辑，导致路径参数未解码、PostForm 失效、状态码不可修改及中间件链中断。
iris.Context 是请求响应流的唯一枢纽，所有读写操作都必须经它中转，不能绕过或缓存原始 *http.Request 或 http.ResponseWriter。
为什么不能直接用 *http.Request 和 http.ResponseWriter
iris.Context 封装了底层 *http.Request 和 http.ResponseWriter，但做了关键增强：自动处理 URL 解码、表单解析、MIME 类型协商、响应缓冲、错误统一拦截。直接操作原始对象会跳过这些逻辑，导致：
- 路径参数未解码（如
%20保持原样） -
ctx.PostForm("key")失效，因为Request.ParseMultipartForm()未被调用 - 响应头写入后无法再修改状态码（而
ctx.StatusCode(400)可安全覆盖） - 中间件链中断（
ctx.Next()依赖上下文内部索引）
ctx.ReadJSON() 和 ctx.Bind() 的行为差异
二者都用于反序列化请求体，但触发时机和容错能力不同：
-
ctx.ReadJSON(&v)：直接读取ctx.Request().Body，不检查Content-Type，也不预解析表单；若请求体已被其他方法（如ctx.FormValue()）读过，则返回io.EOF -
ctx.Bind(&v)：先检查Content-Type，自动选择 JSON / XML / 表单解析器；会跳过已读取的 body，从缓存中提取数据；支持结构体字段标签（如json:"name"）和验证（binding:"required"） - 常见误用：
ctx.FormValue("x")后再调用ctx.ReadJSON()→ 必然失败；应统一用ctx.Bind()或确保只读一次 body
响应写入时 ctx.StopExecution() 的真实作用
它不终止 HTTP 连接，而是阻止后续中间件和路由处理器执行，但已写入的响应内容仍会发出。典型使用场景：
- 权限校验失败后立即返回 401，避免继续执行业务逻辑：
if !authorized { ctx.StatusCode(401); ctx.WriteString("unauthorized"); ctx.StopExecution(); return } - 注意：调用
ctx.StopExecution()后不能再调用ctx.Next()，否则 panic - 与
return的区别：return仅退出当前 handler 函数，不影响同一路由链上的其他 handler；StopExecution影响整个链
自定义 ResponseWriter 的风险点
通过 ctx.ResetResponseWriter() 替换 writer 能实现压缩、日志、重定向拦截等，但必须满足：
- 新 writer 必须嵌入
iris.ResponseWriter接口，否则ctx.StatusCode()等方法失效 - 不能在 writer.Write() 中调用
ctx.ResponseWriter().Write()，否则递归死锁 - 若需包装原 writer，应保存原始
ctx.ResponseWriter()引用，而非再次调用ctx.ResponseWriter() - 常见坑：
gzipWriter忘记调用Close()→ 响应体被截断
最易被忽略的是：iris.Context 生命周期绑定到单次请求，任何跨请求缓存它的行为（比如存进 map 或全局变量）都会引发竞态和内存泄漏——sync.Pool 已为你管理复用，别自己造轮子。
