c.json() 不适合流式大数据响应，因其全量序列化到内存再写入，导致内存峰值达原始数据2~3倍、gc压力线性增长、无法中断或限速、错误发生时资源已白耗。
直接用 c.JSON() 返回超大 JSON 数组（比如几 MB 甚至上百 MB）会触发 OOM 或响应超时，根本原因是它调用 json.Marshal() 全量序列化到内存，再一次性写入 response body。
为什么 c.JSON() 不适合流式大数据响应
c.JSON() 内部执行三步：反射遍历结构体 → 分配 []byte 缓冲区 → 调用 json.Marshal() → 整体写入 http.ResponseWriter。对大数组来说：
- 内存峰值 = 原始数据大小 × 2~3 倍（marshal 中间对象 + 序列化 buffer）
- GC 压力随数组长度线性增长，P99 延迟跳变明显
- 无法中断或限速，客户端断连时服务端仍继续序列化
- 错误发生在最后一步（写入失败），但前面所有 CPU 和内存已白耗
用 jsoniter + c.Stream() 实现边序列化边传输
核心是绕过 c.JSON()，手动控制序列化节奏和写入时机。推荐组合：jsoniter.ConfigFastest + c.Stream() + io.Pipe 或直接写 http.ResponseWriter。
- 不要用
jsoniter.Marshal()全量生成[]byte，那只是把encoding/json换了个更快的马甲，仍吃内存 - 改用
jsoniter.NewEncoder(c.Writer)，它复用http.ResponseWriter的底层 writer，零拷贝输出 - 对切片元素逐个
Encode()，中间可插入c.Writer.Flush()控制 chunk 大小 - 示例关键片段：
func StreamLargeArray(c *gin.Context) {
c.Header("Content-Type", "application/json")
c.Writer.WriteString("[") // 手动写开头
// 模拟大数据源：数据库游标、文件行读取、channel 流
items := getLargeItemStream() // 返回
<h3>处理超大 payload 时的截断与降级策略</h3>
<p>上游传来的原始 JSON 如果本身就很大（如日志 dump），别试图全量解析再重发——直接透传并加保护。</p>
- 用
io.LimitReader(c.Request.Body, 2<code>10241024) 在读取阶段硬限制最大 2MB，超出部分丢弃 - 若需保留原始字节流，用
bytes.NewReader()包一层后交给jsonvalue.UnmarshalReader()流式解析，避免json.Unmarshal()全加载 - 对不可信输入，禁用
jsoniter.Unsafe模式；UTF-8 确保可信时才启用，否则可能 panic - 在 handler 开头加
defer func() { if r := recover(); r != nil { c.AbortWithStatus(500) } }()，防止流式解析中途 panic 导致连接挂死
容易被忽略的流式响应陷阱
流式不是万能解药，几个关键点不注意，反而比 c.JSON() 更糟：
- 没调
c.Writer.Flush()—— 数据卡在 Go HTTP 底层缓冲区（默认 4KB），客户端收不到任何内容，直到缓冲满或连接关闭 - 在
for循环里反复创建jsoniter.Encoder实例 —— 每次 new 都分配内存，应复用或直接用jsoniter.ConfigFastest.Encode()函数式调用 - 忽略
context.DeadlineExceeded—— 客户端断连后，c.Request.Context().Done()会关闭，但你的 for 循环还在跑，必须检查c.Request.Context().Err() - 没设
Content-Encoding: identity或禁用 Nginx gzip —— 反向代理对流式响应做 gzip 会等完整 body，彻底破坏流式语义
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
