根本原因在于 json.unmarshal 默认无限制构建嵌套结构，超深嵌套或超大数组会触发 gb 级内存分配；需结合 disallowunknownfields、token 扫描限深限长、maxbytesreader 限总字节数及上下文超时四层防护。
为什么 json.Unmarshal 遇到恶意或畸形 JSON 会吃光内存
根本原因在于 Go 的 json.Unmarshal 默认不设限地构建嵌套结构：遇到超深嵌套、超大数组、超长键名或重复键时，它照单全收，把整个输入解析成 map[string]interface{} 或 []interface{} —— 这些类型底层是 Go 运行时动态分配的堆对象，没有深度/长度/键长约束。一个 1MB 的恶意 JSON（比如 10 万层嵌套对象）可能触发 GB 级内存分配。
用 json.Decoder + DisallowUnknownFields() 拦住未知字段膨胀
真正起作用的不是禁止未知字段本身，而是它迫使你必须定义明确结构体，从而规避 interface{} 的泛型膨胀。但注意：DisallowUnknownFields() 只对结构体有效，对 map[string]interface{} 完全无效。
- 必须提前定义
struct，字段名与 JSON 键严格对应，未声明字段直接报错 - 在解码前调用
decoder.DisallowUnknownFields()，否则该设置不生效 - 错误类型是
*json.UnmarshalTypeError或*json.InvalidUnmarshalError，不是io.EOF
var data MyStruct dec := json.NewDecoder(r) dec.DisallowUnknownFields() err := dec.Decode(&data) // ← 此处才触发校验
限制解析深度和键长：靠 json.Decoder 的 UseNumber() 和自定义 Token 扫描
UseNumber() 本身不省内存，但它把数字转成 json.Number 字符串，避免了浮点数解析开销和精度问题；真正控深控长得自己读 token。
- 用
decoder.Token()逐个消费 token，每读一层 object/array 就计数，超过阈值（如 100 层）直接return fmt.Errorf("nesting too deep") - 遇到
json.Stringtoken 时，检查len(token)是否超限（如 > 64KB），超限就中断 - 不要依赖
MaxBytesReader，它只限总字节数，拦不住“1 字节键名 + 1GB 值”这种攻击
生产环境必须搭配 http.MaxBytesReader + 超时控制
内存暴涨往往始于网络层：客户端持续发流式 JSON，服务端边读边解，没上限就会缓存全部数据。仅靠 JSON 解析层控制远远不够。
-
http.MaxBytesReader必须包裹原始http.Request.Body，且阈值要小于 Go runtime 的 GC 触发阈值（建议 ≤ 10MB） -
http.Request.Context().WithTimeout()要早于json.NewDecoder创建，否则超时后 goroutine 仍卡在Read - 别在 handler 里用
io.ReadAll把整个 body 读进内存再解码——这是最常见踩坑点
复杂点在于：深度限制、键长限制、总字节数限制、超时控制四者必须协同生效，漏掉任意一环都可能被绕过。实际部署时，建议用封装好的中间件统一注入这四层防护，而不是每个 handler 自行拼接。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
