io.LimitReader不能直接限制*os.File读取长度，因其仅约束后续Read调用且不改变文件偏移；必须使用其返回值、弃用原文件，且LimitReader不支持Seek。
io.LimitReader 为什么不能直接限制 *os.File 的读取长度？
因为 io.LimitReader 返回的是一个新 io.Reader，它只对「后续调用 Read」生效，不改变原 Reader 的内部状态（比如文件偏移）。如果你对一个已打开的 *os.File 套一层 io.LimitReader，但之后又直接从原文件读——限制就完全失效了。
常见错误现象：io.LimitReader(f, 1024) 后没用返回值，还是调 f.Read(buf)；或者把限制 reader 和原文件混着用，结果读出远超预期的字节。
- 必须用
io.LimitReader的返回值做后续读操作，原Reader要彻底弃用 - 对
*os.File使用时，注意它本身支持Seek，但LimitReader不封装Seek方法——调用会 panic - 如果需要 seek + 限长，得自己包装或改用
io.SectionReader
怎么安全地读取 HTTP 响应体前 N 字节？
HTTP 响应体是典型的流式 io.ReadCloser，没有长度预知，io.LimitReader 是最轻量的截断手段。但它不会自动关闭底层连接，这点极易被忽略。
使用场景：防止恶意大响应耗尽内存、快速提取响应头/签名、做内容类型探测。
立即学习“go语言免费学习笔记（深入）”；
- 务必用
io.LimitReader(resp.Body, n)替换resp.Body，再传给io.Copy或io.ReadAll -
io.LimitReader读完 N 字节后，后续Read返回0, io.EOF，但resp.Body.Close()仍需手动调用 - 别依赖
LimitReader来“提前终止”连接——它只是不读，TCP 连接还在收包，服务端可能继续发数据
示例：
limited := io.LimitReader(resp.Body, 8192)<br>data, _ := io.ReadAll(limited)<br>resp.Body.Close() // 必须关
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
LimitReader 和 io.ReadFull / bufio.Reader 混用会怎样？
io.LimitReader 是个薄包装，它不缓冲、不预读、不重试。一旦和需要多次 Read 的工具混用，行为容易偏离直觉。
常见错误现象：用 io.ReadFull(limitedReader, buf) 期望读满 len(buf)，但实际只读了部分就返回 io.ErrUnexpectedEOF（因为限长提前耗尽）；或者用 bufio.NewReader(limitedReader) 后，Peek/ReadString 触发内部缓冲，悄悄突破限制。
-
io.ReadFull在限长不足时返回io.ErrUnexpectedEOF，不是io.EOF——要区分处理 -
bufio.Reader构造时会一次性从底层读最多bufio.MinRead（通常 512B），这步不受LimitReader约束，可能直接越界 - 若需带缓冲的限长读，建议先用
LimitReader包装，再用bufio.NewReaderSize(..., n)控制缓冲区大小
读取超过限制后，err 是什么？怎么判断是否“刚好读完”？
io.LimitReader 的核心逻辑简单：每调一次 Read，先扣减剩余字节数，再转发读请求。扣到 0 后，所有后续 Read 都返回 0, io.EOF。
关键点：它不关心你传的 buf 多大，只按「还能读多少」来截断。所以一次 Read 可能返回少于 len(buf) 的字节数，且不报错——这是正常行为，不是 bug。
- 返回
n < len(buf)且err == nil：说明限制还剩，但底层 Reader 当前只能提供这么少（比如网络延迟、文件末尾） - 返回
n == 0且err == io.EOF：明确表示限制已用完 - 返回
n > 0且err == io.EOF：说明这次读到了限制边界，刚好读完最后一批字节
真正难处理的是「限制中途遇到底层 error」——比如磁盘 I/O 错误，这时 LimitReader 会透传该 error，剩余字节数不变。下次读仍会尝试，直到耗尽或再出错。
