io.limitreader不能直接限制文件总大小，因为它仅对流式读取做字节计数，不感知文件长度、不干预底层reader生命周期、不支持seek或close，且只实现read方法。
io.LimitReader 为什么不能直接限制文件总大小
io.LimitReader 本身不感知文件长度，它只对「流式读取」过程做字节计数。如果你用它包装一个 *os.File，然后调用 ReadAll 或反复 Read，它会在累计读到指定字节数后返回 io.EOF —— 但前提是底层 reader 真的提供了那么多数据。如果文件本身比限制小，它不会补零或报错，只是正常读完就结束。
常见误用是以为它能“截断大文件”或“强制只读前 N 字节并关闭源”，其实它不干预底层 reader 的生命周期，也不做 seek 或 close 操作。
- 它返回的是
io.Reader，不是新文件句柄，也不改变原文件状态 - 多次调用
Read时，计数是累积的；重置需重新构造io.LimitReader - 若底层 reader 在限制到达前已返回
io.EOF（比如文件只有 100B，你限 200B），io.LimitReader也立刻返回io.EOF
如何安全地用 io.LimitReader 防止内存爆炸
典型场景：HTTP 请求体、上传文件流、日志管道等不可信输入。目标不是“精确截断”，而是“绝不让超过 N 字节进内存”。这时要配合 io.ReadFull、io.CopyN 或显式循环读取，避免误用 io.ReadAll 导致越界。
错误写法：
data, _ := io.ReadAll(io.LimitReader(r, 1024*1024)) // 危险！若 r 实际返回超限数据，io.ReadAll 会 panic
正确做法是控制每次读取量，或用更稳的封装：
- 用
io.CopyN(dst, io.LimitReader(r, limit), limit)，它在复制满 limit 后停止，且返回实际字节数 - 手动循环读取到固定 buffer，检查每次
n, err中的err == io.EOF或err == io.ErrUnexpectedEOF - 若需完整数据且必须限制大小，先用
io.LimitReader包装，再传给bytes.Buffer.ReadFrom并检查最终长度
io.LimitReader 和 http.MaxBytesReader 的区别在哪
http.MaxBytesReader 是 io.LimitReader 的 HTTP 专用增强版，它不只是限制字节数，还会在超限时主动返回 http.StatusRequestEntityTooLarge 响应，并记录日志。更重要的是：它会 wrap 整个 http.Request.Body，并在 Close() 时确保底层 body 被关闭 —— 这点 io.LimitReader 完全不管。
所以别用 io.LimitReader 替代 http.MaxBytesReader 处理 HTTP 请求体，除非你手动管理 Close 且自己处理超限响应逻辑。
-
io.LimitReader(r, n)→ 纯字节计数器，无协议语义 -
http.MaxBytesReader(w, r, n)→ 自动设置响应头、状态码、关闭 body，专为 HTTP 设计 - 两者都不可重用：一旦计数耗尽，后续读取始终返回
0, io.EOF
什么时候不该用 io.LimitReader
当你需要随机访问、seek、或者依赖底层 reader 的其他方法（如 ReadAt、Stat、Seek）时，io.LimitReader 就不合适了。它只实现了 Read 方法，其余都 panic。
例如想读 zip 文件前几个字节判断格式，又怕整个 zip 加载进内存 —— 这时应该用 io.MultiReader + io.LimitReader 组合，或直接用 bytes.NewReader(data[:min(len(data), 100)])（如果数据已部分加载）；而不是指望 io.LimitReader 支持 Seek。
- 它不实现
io.Seeker、io.ReaderAt、io.Closer - 无法用于需要
stat获取文件大小的场景（得提前os.Stat） - 和
bufio.Reader叠加时注意缓冲区可能预读超出限制，建议LimitReader包在外层
真正难的不是调用 io.LimitReader，而是判断该在哪里切断、切断后怎么处理残留数据、以及是否要关掉上游 reader。这些边界问题不写测试很容易漏。
