Go标准库不提供开箱即用的mmap接口，需用syscall.Mmap或封装库如mmap-go；后者自动处理页对齐、平台差异和错误转换，支持随机读写但需手动Flush保证持久化，且跨平台需注意Windows的64KB对齐限制。
Go 里 mmap 不是标准库原生支持，得靠 syscall.Mmap 或封装库
Go 标准库没有像 Python 的 mmap 模块那样开箱即用的内存映射接口。真正能用的是底层 syscall.Mmap（Linux/macOS）或 syscall.VirtualAlloc（Windows），但直接调用它容易出错——比如忘记对齐页边界、传错保护标志、漏掉 syscall.Munmap 导致资源泄漏。
更现实的做法是用成熟封装，比如 github.com/edsrzf/mmap-go。它屏蔽了平台差异，自动处理页对齐和错误转换，且 API 简洁：
mm, err := mmap.Open("bigfile.dat")
if err != nil {
log.Fatal(err)
}
defer mm.Close() // 必须调用，否则 munmap 不触发
-
mmap.Open()默认以只读方式打开并映射整个文件；若需写入，得显式传mmap.RDWR - 映射后
mm实现了io.ReaderAt和io.WriterAt，可直接用mm.ReadAt(buf, offset)随机读，不用 seek - 写操作不会自动 flush 到磁盘，需调用
mm.Flush()（对应msync），否则重启后可能丢失
大文件随机读写时，mmap 比 os.File.ReadAt 快，但不是万能加速器
当文件远大于物理内存（比如 50GB 文件在 16GB 内存机器上），mmap 的优势在于内核按需分页加载：你只访问某段偏移，内核才把对应磁盘页载入内存，避免一次性读全文件。而 os.File.ReadAt 每次调用都走系统调用+内核缓冲区拷贝，小量随机读时开销明显。
- 适合场景：频繁跳转读写固定位置（如数据库索引、日志偏移查找）、需要低延迟随机访问
- 不适合场景：顺序扫描整个大文件（此时
bufio.Reader+Read更省内存和 CPU） - 注意：映射超大文件（>100GB）可能触发内核
vm.max_map_count限制，报错cannot allocate memory，需调高该值
mmap 写入后不 Flush，数据可能卡在 page cache 里
Go 封装库（如 mmap-go）默认使用 MAP_SHARED，意味着修改会反映到文件，但内核不保证立即落盘。如果程序崩溃或断电，未刷入的数据就丢了。
立即学习“go语言免费学习笔记（深入）”；
- 必须在关键写入后调用
mm.Flush()，它等价于msync(addr, length, MS_SYNC) - 如果只是临时缓存、不强求持久化，可用
MAP_PRIVATE（但 Go 封装库通常不暴露此选项，得自己调syscall.Mmap） - 频繁
Flush会拖慢性能，可折中：批量写完再 flush，或用runtime.SetFinalizer做兜底（不推荐，finalizer 不保证及时执行）
跨平台时小心 Windows 的 FILE_MAP_WRITE 和内存对齐要求
Windows 对内存映射更严格：文件大小必须是 64KB 的整数倍才能用 CreateFileMapping，否则 mmap.Open 会返回 The parameter is incorrect. 错误。
- 常见坑：用
os.Truncate截断文件后没补零到 64KB 对齐，导致后续 mmap 失败 - 解决方案：映射前检查
fi.Size() % 65536 != 0，若不满足，先os.WriteAt补零（或换用syscall.CreateFileMapping手动控制） - macOS/Linux 无此限制，但所有平台都要求映射起始地址和长度按页对齐（通常是 4KB），封装库已处理，自己调
syscall.Mmap时必须手动对齐
最麻烦的不是语法，是理解 mmap 本质：它只是把文件“挂”进虚拟地址空间，读写行为最终由内核页表和 page cache 控制。没搞清这点，就容易在数据一致性、OOM、跨平台失败上反复踩坑。
