go中随机读文件需先os.open打开，再用file.seek定位偏移量后read，或直接用readat指定offset读取；须校验offset边界、检查错误，避免越界静默失败。
用 os.Open + file.Seek 跳到任意位置开始读
Go 里没法像 Python 那样直接 f.read(1024) 从中间开始读，必须显式定位。核心是先打开文件，再用 Seek 移动到目标偏移量，最后用 Read 或 ReadAt 拿数据。
常见错误是忘记检查 Seek 返回值，或误以为 Seek 后自动重置读取位置（其实它只改内部指针，后续 Read 就从那开始）。
-
Seek的第二个参数必须是io.SeekStart、io.SeekCurrent或io.SeekEnd，写数字 0/1/2 会编译失败 - 如果文件是只读打开的（
os.Open），Seek没问题；但用os.OpenFile以os.O_WRONLY打开时，Seek可能失败（某些 OS 不支持写入模式下随机定位） - 示例：从第 1000 字节开始读 512 字节
file, _ := os.Open("data.bin")
file.Seek(1000, io.SeekStart)
buf := make([]byte, 512)
n, _ := file.Read(buf)
// buf[:n] 就是目标数据
ReadAt 更适合多线程/并发随机读
ReadAt 是无状态的：每次调用都独立指定偏移量，不依赖文件当前指针位置。适合多个 goroutine 同时读不同区域，避免 Seek + Read 的竞态风险。
但它不更新文件指针，所以不能链式读（比如想连续读两段，得分别调 ReadAt 两次并算好各自 offset）。
立即学习“go语言免费学习笔记（深入）”；
-
ReadAt返回实际读取字节数，可能小于请求长度（比如读到文件末尾），必须检查n和err - 如果 offset 超出文件长度，
ReadAt返回0, io.EOF，不是 panic，这点和Seek不同 - 性能上，
ReadAt在底层通常等价于lseek+read系统调用，和Seek+Read差不多，但省去手动同步指针的麻烦
file, _ := os.Open("data.bin")
buf := make([]byte, 512)
n, err := file.ReadAt(buf, 1000) // 直接读第 1000 字节起的内容
if err == io.EOF && n == 0 {
// offset 已超出文件末尾
}
注意 mmap 不是万能替代方案
有人会想到用 mmap（比如 golang.org/x/exp/mmap 或第三方库），觉得“内存映射=随机访问快”。但实际中容易踩坑：
- Windows 上
mmap映射大文件可能失败（受限于用户空间地址范围），而Seek+Read没这问题 - 映射后若文件被其他进程截断或删除，Go 程序可能 panic 或读到零值（取决于 OS 行为）
-
mmap占用虚拟内存，但不立即分配物理页；首次访问某页才触发缺页中断——这在高并发随机读场景下可能引发延迟毛刺 - 绝大多数业务场景下，
ReadAt的性能已足够，没必要引入 mmap 的复杂性和平台差异
随机读大文件时别忽略 os.Stat 和边界校验
真正上线时，随机 offset 常来自外部输入（比如 HTTP 请求参数），必须校验是否越界，否则 ReadAt 或 Seek 可能静默返回 0, io.EOF，导致逻辑错乱。
- 先用
os.Stat拿到Size()，再判断offset ，而不是靠读取结果反推 - 如果要读
n字节，需确保offset + n ，否则要主动截断请求长度 - 注意
int64和uint64混用：文件大小是int64，但某些哈希或分片逻辑可能用uint64算 offset，溢出会导致负数 offset，Seek会报invalid argument
边界检查这事看着琐碎，但线上遇到过因少判一行，导致服务把整个文件当空数据返回的事故。
