Go网络流式解包必须在协议层校验长度、隔离缓冲区并提前截断，否则伪造大长度字段会导致OOM；net/http不拦截超大包因HTTP协议本身不限制body长度，http.Request.Body是裸io.ReadCloser，需手动用http.MaxBytesReader设防。
直接说结论：go 的网络流式解包不能靠“等完整包再处理”来防御，必须在协议解析层就做长度校验、缓冲区隔离和提前截断——否则一个伪造的 2gb content-length 或恶意分块头就能让服务瞬间 oom。
为什么 net/http 默认不拦超大包
HTTP 协议本身不强制要求 body 长度可预测：Transfer-Encoding: chunked 允许边发边定长，Content-Length 可被伪造，而 Go 的 http.Request.Body 是个裸 io.ReadCloser，不校验、不拦截、不设限。你调 json.NewDecoder(r.Body).Decode(&v)，它就真会一直读到 EOF 或崩溃。
-
http.MaxBytesReader是唯一可靠的首道闸门，但它必须手动包裹且赋值回r.Body，漏掉这步等于没设防 - 不设
MaxBytesReader时，r.ParseMultipartForm(32 << 20)里的 32MB 只是内存缓冲上限，超了会写临时磁盘——但攻击者可故意发 100 个 31MB 的 part，照样耗尽 fd 和磁盘空间 - 用
io.LimitReader替代MaxBytesReader是错的：它只限制总字节数，不阻止底层Read分配大 buffer（比如bufio.Scanner内部仍可能 malloc 10MB）
流式解包时如何安全读取单个消息边界
无论 HTTP、TCP 还是自定义二进制协议，核心是“不信任长度字段，不预分配大 buffer，不攒数据”。真实场景中，消息头里的长度只是建议值，不是承诺值。
- 对 JSON Lines 或 Protocol Buffer 流：用
json.Decoder或proto.UnmarshalStream，它们基于io.Reader，按需读、边解边丢，内存占用稳定在 KB 级 - 对固定头 + 变长体协议（如
[4]byte len + []byte payload）：先用io.ReadFull(conn, headerBuf)读头，检查len是否合理（比如 < 16MB），再用io.LimitReader(conn, int64(len))包一层传给后续解析，避免恶意放大 - 绝不用
make([]byte, maliciousLen)—— 攻击者只要发个0xffffffff当长度，你的make就直接 panic: runtime out of memory
multipart 表单上传的流式拆包陷阱
HTTP 文件上传最常被滥用：ParseMultipartForm 是默认雷区，它内部会把整个请求体读进内存或临时文件，完全不可控。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 必须跳过
r.ParseMultipartForm，改用multipart.NewReader(r.Body, boundary)手动逐 part 解析 - 每个
part的Header里有Content-Length，但它是可伪造的；真正安全的做法是用io.CopyN(dst, part, expectedSize)，而不是io.Copy(dst, part) - 对非目标字段（如
name、description），直接io.Copy(io.Discard, part)，别用part.FormValue()—— 后者会把整个字段内容加载进内存 - 如果目标 part 是文件，打开本地文件后立刻
defer f.Close()，别等所有 part 处理完才关
缓冲区复用与 sync.Pool 的真实代价
很多人以为用 sync.Pool 复用 []byte 就能防爆内存，但在流式解包高频小包场景下，它反而增加锁竞争和 GC 压力。
立即学习“go语言免费学习笔记（深入）”；
- 若单次读取平均耗时 < 10μs（比如千兆网卡上读 4KB 包），
sync.Pool.Get/Return的原子操作开销已超过内存节省收益 - 更稳的方案是：为每个连接或每个 handler 预分配一个固定大小 buffer（如
buf := make([]byte, 64*1024)），循环重用，不进 Pool - 如果必须用 Pool，只对 ≥ 128KB 的 buffer 复用才有意义；小 buffer 直接 new 更快
-
bufio.Reader和bufio.Scanner内部已有缓冲管理，不要再套一层 Pool，容易错位或 double-close
最容易被忽略的一点：所有流式解包逻辑都必须在 context.WithTimeout 或 context.WithDeadline 下运行，尤其当上游是不可信网络时。一个卡住的 Read 调用不会自己超时，除非你显式控制——否则协程堆积、fd 耗尽、OOM 都只是时间问题。
