go中文件读写位置由内核维护，必须用os.file.seek显式移动，不可用unsafe.pointer偏移；并发场景应优先使用线程安全的readat/writeat，避免seek+read/write导致的位置冲突。
用 os.File.Seek 控制读写位置，不是靠指针算术
Go 里没有 C 那种裸指针偏移操作，*os.File 的“位置”由内核维护，必须通过 Seek 显式移动。直接对文件描述符做 unsafe.Pointer 偏移不仅无效，还会破坏 runtime 对文件状态的跟踪。
常见错误是试图用 uintptr(unsafe.Pointer(&f)) + offset 模拟偏移——这改的是结构体地址，不是文件游标。
-
Seek第一个参数是相对偏移量（字节），第二个是起始基准：io.SeekStart（从开头）、io.SeekCurrent（当前位置）、io.SeekEnd（结尾） - 返回值是实际到达的绝对偏移（从开头算），可用于校验或链式定位
- 如果文件以
os.O_RDONLY打开，写操作会失败；反之只读模式下Seek仍可执行，但后续Write会报bad file descriptor
ReadAt 和 WriteAt 是真正的“随机访问”接口
它们不依赖当前文件偏移，而是每次调用都指定绝对位置，适合多 goroutine 并发读写同一文件的不同区域，也避免反复 Seek 的系统调用开销。
注意：这两个方法底层调用的是 pread/pwrite 系统调用（Linux/macOS），天然线程安全，不会干扰其他 goroutine 的 Read/Write 位置。
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
-
ReadAt返回实际读取字节数，可能小于len(p)（比如越界或 EOF），但不会自动填充剩余部分 -
WriteAt写入长度严格等于len(p)，若位置超出当前文件大小，会触发“空洞”（sparse file），文件大小不变，直到该区域被真正写入数据 - 若需扩展文件并填零到目标位置，得先
Seek到末尾、Write足够零字节，再WriteAt
并发读写同一文件时，Seek + Read/Write 不安全
因为 Seek 改变的是共享的文件偏移量，两个 goroutine 先后 Seek 再 Read，很可能读到对方覆盖后的位置，结果错乱。
典型现象：日志文件中某次写入内容出现在错误偏移，或读出乱码、截断数据。
- 解决方案一：用
ReadAt/WriteAt替代，显式传入 offset，彻底规避共享状态 - 解决方案二：加互斥锁保护
Seek+Read/Write组合，但性能差，且锁粒度难控制 - 解决方案三：每个 goroutine 单独打开文件（
os.OpenFile），这样每个句柄有独立偏移，但要注意文件描述符耗尽和一致性问题（如多个 writer 写同一区域）
小心 WriteAt 在文件末尾外写入导致的“空洞”和磁盘占用异常
在位置 10MB 处 WriteAt([]byte{'a'}, 10*1024*1024)，文件大小不会变成 10MB+1，而是保持原样；但 stat 显示的 Size 可能跳变，且某些文件系统（如 ext4）会分配块，导致磁盘空间意外增长。
验证方式：ls -lsh 查看实际磁盘占用（第一列），对比 ls -l 的逻辑大小（第五列）。
- 用
os.Truncate可收缩文件，但无法清除已分配的空洞块；真正清空需用fallocate -d（Linux）或重写有效数据 - 若业务需要稀疏文件（如数据库预分配），这是预期行为；否则应确保写入前文件已足够大，可用
Truncate或Seek+Write填零扩展 -
WriteAt返回nil不代表数据已落盘，需配合file.Sync()或os.Sync()强制刷盘
ReadAt/WriteAt，要顺序流式处理才用 Seek 配合 Read/Write，并且永远别碰 unsafe 去动文件句柄。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
