os.Open + io.Seek 是唯一靠谱方案，因为Go无fseek等开箱即用随机读取抽象，bufio.Scanner等流式读取器会破坏偏移或缓冲一致性，而os.File原生支持io.Seeker且可控可预测。
为什么 os.Open + io.Seek 是唯一靠谱方案
Go 没有类似 C 的 fseek 那样“开箱即用”的随机读取抽象，os.File 本身支持 Seek，但必须搭配底层文件句柄操作——这意味着不能用 bufio.Scanner 或 encoding/json.Decoder 这类封装好的流式读取器，它们会破坏偏移位置或内部缓冲。直接用 os.Open 打开文件后调用 Seek，再用 Read 或 ReadAt，才是可控、可预测的方式。
常见错误是先用 bufio.NewReader 包一层再 Seek，结果返回 io.Seeker is not supported 或读到错位数据——因为 bufio.Reader 内部缓存了未消费字节，Seek 无法同步更新它的缓冲区状态。
-
os.File实现了io.Seeker，可安全Seek -
os.OpenFile时需确保 flag 包含os.O_RDONLY（只读即可，无需os.O_RDWR） - 若文件可能被并发写入，需额外加锁或确认写入已 flush，否则
Seek后读到的是脏数据
ReadAt 和 Seek+Read 怎么选
ReadAt 不改变文件当前偏移量，适合单次读取；Seek+Read 会移动偏移量，适合连续多次读取不同位置。性能上差异不大，但语义更清晰：如果你只读一段，用 ReadAt；如果后续还要在附近读几段，用 Seek 更自然。
注意：ReadAt 的 offset 是从文件开头算起的绝对偏移，不是相对当前指针；而 Seek 的 whence 参数常用 io.SeekStart（绝对）、io.SeekCurrent（相对）。
立即学习“go语言免费学习笔记（深入）”；
- 用
ReadAt：适合无状态、单次读取，比如从日志文件中提取某行附近的 1KB 数据 - 用
Seek+Read：适合需要多次跳转的场景，比如解析固定格式二进制文件的 header + payload + footer - 两者都要求 offset 不越界，否则
ReadAt返回0字节且不报错，Seek则返回EOF错误
读取中间片段时如何避免内存爆炸
“大文件”意味着不能全量加载进内存。ReadAt 或 Read 都只读指定长度，但缓冲区大小仍由你控制。别用 io.ReadAll 或 bytes.Buffer.Grow 无脑扩容，而是预估片段大小，分配固定切片。
例如要读取 1MB 片段，就 make([]byte, 1，然后传给 <code>ReadAt。如果实际读到的字节数少于预期（比如接近文件尾），ReadAt 返回的 n 就是真实长度，不要假设填满。
- 永远检查
ReadAt返回的n和err，尤其当 offset 接近文件末尾时 - 避免用
strings.NewReader或bytes.NewReader包装大块数据再处理——这等于又拷贝一次 - 若需解析文本片段（如 JSON 片段），用
json.NewDecoder(bytes.NewReader(buf[:n]))，而不是先转成string（避免 UTF-8 解码开销和内存重复）
Windows 下 Seek 失败的隐藏原因
在 Windows 上，用 os.Open 打开的文件默认以 FILE_SHARE_READ 打开，但如果文件正被其他进程以独占方式写入（比如某个日志轮转工具正在重命名并新建同名文件），Seek 可能返回 syscall.ERROR_ACCESS_DENIED，而非直观的 EBADF 或 EINVAL。
这不是 Go 的 bug，而是 Windows 文件系统语义：即使你只读，只要目标文件被另一个进程以 CREATE_ALWAYS 或 TRUNCATE_EXISTING 方式打开过，就可能阻塞后续的 seek 操作。
- 用
os.Stat检查文件是否存在且大小稳定，可提前规避部分问题 - 生产环境建议加
time.Sleep重试（最多 2–3 次），比直接 panic 更健壮 - Linux 下基本没这个问题，但跨平台代码里仍需统一处理
Seek错误
f, err := os.Open("huge.log")
if err != nil {
log.Fatal(err)
}
defer f.Close()
buf := make([]byte, 1<<20) // 1MB
n, err := f.ReadAt(buf, 100*1024*1024) // 从第 100MB 开始读
if err != nil && err != io.EOF {
log.Fatal(err)
}
data := buf[:n] // 真实读到的字节数
真正麻烦的从来不是怎么跳到那里，而是跳过去之后，那段数据到底算不算“有效”——比如它是否落在一个完整的 UTF-8 字符边界上，或者是否截断了某个 JSON 对象的括号。这些得靠业务逻辑自己判断，标准库不会替你猜。
