io.LimitReader仅适用于精确截断前N字节且不需重试、不混用扫描器的场景；禁用于HTTP体防护、多次重试或需并发安全的场合，因其一次性计数、无日志、不关连接。
io.LimitReader 什么时候该用，什么时候不该用
当你需要从一个 io.Reader 中「只读前 N 字节」，且不希望后续读取超出这个边界时，io.LimitReader 就是正确选择。它不是用来做“流控”或“超时”，也不是替代 io.ReadFull 或缓冲区切片——它只干一件事：在累计读满 n 字节后，让后续所有 Read 调用返回 io.EOF。
常见误用场景：
- 想限制 HTTP 请求体大小却直接包装
http.Request.Body后没及时Close——底层连接可能被提前断开，导致客户端收不到完整响应 - 用在需要多次重试的 Reader（比如网络抖动重连）上——
LimitReader是一次性的，重试时不会重置计数器 - 和
bufio.Scanner混用时没注意扫描器内部会预读，可能触发提前 EOF
怎么正确包装并确保长度严格生效
io.LimitReader 本身不校验输入长度是否合理，也不处理底层 reader 的并发安全问题。它的行为完全取决于你传入的 n 和原始 Reader 的实现。
-
n为负数时，Read直接返回0, io.EOF；为 0 时，首次Read就返回0, io.EOF - 如果原始
Reader返回的n比请求长度还大（比如一次读了 1024 字节但你只想要前 100），LimitReader会截断并丢弃多余字节——这点容易被忽略 - 必须在业务逻辑中显式检查返回的
err是否为io.EOF，不能只看n是否为 0 - 若需精确控制“最多读 N 字节，且必须读满”，应组合使用
io.LimitReader+io.ReadFull
示例：
立即学习“go语言免费学习笔记（深入）”；
limited := io.LimitReader(r, 1024) n, err := io.ReadFull(limited, buf[:1024]) // 注意：这里 buf 长度要 ≥ 1024
和 http.MaxBytesReader 的关键区别在哪
http.MaxBytesReader 看起来像加强版 io.LimitReader，但它专为 HTTP server 设计，做了两件事：记录日志 + 主动关闭连接。而 io.LimitReader 完全静默，也不会干预底层连接状态。
-
http.MaxBytesReader在超限时返回http.ErrBodyReadAfterClose并调用ResponseWriter.Close，适合防御恶意大请求 -
io.LimitReader只返回io.EOF，适合内部数据解析（如解析上传文件头、读取配置片段） - 不要用
io.LimitReader替代http.MaxBytesReader做请求体防护——它不会阻止客户端继续发包，服务端仍需接收并丢弃后续数据
读完后如何判断是否真的读到了上限
io.LimitReader 不暴露当前已读字节数，也没有 “remaining” 方法。你只能靠外部计数或错误类型推断。
- 如果最后一次
Read返回n < len(buf)且err == io.EOF，不一定说明达到了限制——原始 reader 本身就结束了 - 真正能确认“被限流截断”的唯一方式：在调用
Read前确保底层 reader 还有更多数据可读（比如已知总长 > 你设的 limit），再观察是否提前 EOF - 更稳妥的做法是封装一层带计数的 wrapper，或者改用
io.MultiReader+io.LimitReader组合，在 limit 后接一个 sentinel reader 来捕获越界尝试
复杂点在于：限制行为发生在字节流层面，而 Go 的 io.Reader 接口是 push-based 的，没有 rewind、peek 或 length query 能力——这意味着你永远无法在不消费数据的前提下预知是否会被截断。
