seek的offset是相对于whence指定基准点的偏移量，非绝对位置；误用whence（如该用seek_end却用seek_set）会导致定位错误，负偏移在文本模式下易出错，二进制模式更安全。
Seek 的 offset 参数为什么经常出错
因为 offset 是相对于基准点计算的，不是绝对文件偏移量。传负数不报错，但容易读到意外位置——比如想从末尾倒退 10 字节，却误用 os.SEEK_SET 当成从开头 -10 字节，结果 panic：invalid argument。
- 必须搭配
whence参数使用：os.SEEK_SET（文件开头）、os.SEEK_CUR（当前位置）、os.SEEK_END（文件末尾） - 对只读文件调用
Seek写模式（如os.O_WRONLY打开）没问题；但若文件本身不可写，Seek不会报错，后续Write才失败 - Windows 下，用
os.SEEK_END定位时，offset = 0指向 EOF，offset = -1才是最后一个字节（Linux 同样行为）
如何安全地定位到文件末尾前 N 字节
这是日志截断、追加校验等场景的常见需求。直接 f.Seek(-n, os.SEEK_END) 看似简洁，但若文件长度 Read 返回 0 或 error。
- 先用
f.Stat()获取文件大小，显式判断边界：fi, _ := f.Stat() if fi.Size()
- 不要依赖
Seek返回值做逻辑分支——它返回新位置，但不保证该位置可读/可写；务必在Seek后立即尝试一次Read或Write并检查 error
Seek 在 mmap 场景下是否生效
完全不生效。os.File.Seek 只影响基于系统调用的 Read/Write，而 mmap（如通过 golang.org/x/sys/unix.Mmap）是内存映射，文件偏移与虚拟内存地址无关。
- 如果你用
mmap读文件，Seek调用不会改变 mmap 区域内容或起始地址 - 混用
mmap和普通Read很危险：内核缓冲区和 mmap 页面可能不同步，尤其在写入时 - 需要随机访问大文件？优先考虑
mmap+ 指针算术；需要流式读写+跳转？坚持用Seek+Read
并发调用 Seek + Read 是否线程安全
不安全。Go 的 *os.File 内部维护一个文件描述符和当前偏移量（由内核管理），多个 goroutine 对同一 *os.File 并发 Seek 或 Read 会相互覆盖偏移，导致读到错乱数据。
- 要么加互斥锁（
sync.Mutex）保护每次Seek+Read组合 - 要么为每个 goroutine 分配独立的
*os.File（os.Open多次打开同一路径，内核会维护各自偏移） - 注意：
os.OpenFile用os.O_APPEND标志时，每次Write前内核自动Seek到 EOF，此时并发Write是安全的，但Seek本身仍不安全
Seek 直接操作底层 fd（比如用 syscall.Lseek）都会让 *os.File 的内部缓存失效——这点很容易被忽略。
