LimitReader 限制总读取字节数且不回退文件指针，SectionReader 实现指定区间内可 seek 的随机读；组合时须先 SectionReader 再 LimitReader，否则 panic。
LimitReader 适合控制单次读取上限，但不改变底层 Reader 行为
io.LimitReader 的作用很直接：它把一个 io.Reader 包裹起来，让后续所有 Read 调用加总不超过指定字节数。它不预加载、不缓冲、不 seek，只是在每次 Read 返回前扣减剩余额度。
常见错误是以为它能“截断文件流”或“自动跳过超限部分”——其实不会。LimitReader 读完限额后，下一次 Read 就返回 0, io.EOF，但原始文件指针（比如 *os.File）位置已随实际读取推进，不会回退。
- 适合场景：HTTP 响应体限流、日志片段提取、防止恶意大 payload 消耗内存
- 注意
LimitReader本身不实现io.Seeker，无法和SectionReader混用（除非原 Reader 支持） - 如果底层 Reader 是网络流（如
http.Response.Body），限额用尽后连接可能仍保持打开，需手动Close
示例：limited := io.LimitReader(file, 1024*1024) —— 后续从 limited 最多读 1MB，哪怕 file 还有几十 GB 剩余
SectionReader 用于随机读取文件某一段，依赖底层支持 Seek
io.SectionReader 是真正意义上的“切片式读取”：它固定起始偏移和长度，在这个区间内提供可重复、可 seek 的读能力。但它要求底层 io.Reader 实现 io.Seeker，否则 panic。
立即学习“go语言免费学习笔记（深入）”；
典型误用是拿它包装 os.Stdin 或 HTTP body —— 这些不支持 seek，运行时会报 panic: reflect.Value.Interface: cannot return value obtained from unexported field or method（本质是类型断言失败）。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 必须确保传入的
r是*os.File或其他实现了Seek的 Reader -
SectionReader自身实现了io.ReaderAt和io.Seeker，可以反复读同一段，也可以Seek(0, 0)重置 - 构造时的
off和n是逻辑偏移与长度，不校验是否超出文件真实大小；越界读只返回实际可用字节 +io.EOF
示例：section := io.NewSectionReader(file, 100, 512) —— 从第 100 字节开始读最多 512 字节，section.Read(buf) 和 section.ReadAt(buf, 0) 都合法
LimitReader 和 SectionReader 组合使用要小心顺序
两者组合不是简单叠加，顺序决定语义：LimitReader(section, n) 是“在 section 区间内再限流”，而 SectionReader(limit, off, n) 会 panic —— 因为 LimitReader 不实现 Seek。
真正安全的组合只有一种：先 SectionReader 定范围，再用 LimitReader 控制单次读量。否则你会遇到奇怪的 io.ErrUnexpectedEOF 或提前 EOF。
- 错误写法：
io.NewSectionReader(io.LimitReader(f, 1e6), 100, 512)→ panic - 正确写法：
io.LimitReader(io.NewSectionReader(f, 100, 512), 256)→ 先限定读 [100, 611]，再限制总共最多读 256 字节 - 性能影响：嵌套包装不增加开销，但每层都引入一次函数调用和状态检查，高频小读场景可考虑直接用
ReadAt
大文件读取时，别忽略 os.OpenFile 的 flag 和 syscall 层行为
用 SectionReader 精确读大文件，底层 *os.File 的打开方式会影响实际表现。比如默认 os.Open 使用 O_RDONLY，但若文件被其他进程 truncate，ReadAt 可能返回 0, nil（不是 EOF），导致逻辑卡住。
更隐蔽的问题是 page cache 和 direct I/O：Linux 下普通 read() 走 page cache，而大文件随机读容易引发大量换页；若需稳定延迟，得用 syscall.Open(..., syscall.O_DIRECT, ...)，但这要求 offset 和 buffer 都对齐到 512 字节边界。
- 生产环境建议：用
os.OpenFile(path, os.O_RDONLY, 0)显式声明 flag，避免继承意外权限 - 调试时加
lsof -p PID看 fd 状态，确认是否真在读预期 offset -
SectionReader的Size()方法返回的是构造时传入的n，不是文件真实剩余大小，别拿来判断 EOF
复杂点在于：你写的“精确读取”逻辑，可能在 mmap、buffer cache、磁盘调度多个层面被重排或截断。IO 包只是暴露了 syscall 的一层薄封装，真正的边界永远在内核里
