go标准库无跨平台mmap支持，需用syscall或github.com/edsrzf/mmap-go；mmap返回的[]byte不可append、需显式unmap，适用于大文件随机读，不适用于小文件或顺序读。
Go 里 mmap 没有标准库支持，得用 syscall.Mmap 或第三方包
Go 标准库不提供跨平台的内存映射封装，os.File 的 ReadAt/WriteAt 走的是系统调用路径，不是真正的 mmap。真要 mmap，必须直连底层 syscall —— Linux/macOS 用 syscall.Mmap，Windows 得用 syscall.VirtualAlloc + syscall.CreateFileMapping 等组合，非常繁琐。
实操建议：
- 优先考虑
github.com/edsrzf/mmap-go：它封装了各平台差异，API 统一，且维护活跃；go get github.com/edsrzf/mmap-go即可引入 - 别自己手写 syscall.Mmap 调用：参数顺序、flag 含义（如
syscall.PROT_READvssyscall.MAP_SHARED）、页对齐检查都容易出错 - 注意该包返回的
mmap.MMap是[]byte，但底层指向虚拟内存，不能直接传给copy或json.Unmarshal等可能触发 GC 扫描的函数（见下一条）
mmap 映射后不能随意 append 或当普通切片用
映射出来的内存区域是固定大小、与文件强绑定的。你拿到的 []byte 是一个“视图”，底层数组头指向 mmap 地址，但它的 cap 并不反映真实可用空间，append 会 panic 或静默失败。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
-
runtime error: index out of range [x] with length y：试图越界写入映射区外 -
panic: runtime error: makeslice: cap out of range：对 mmap 返回的 slice 做append - 写入后文件没更新：忘了用
MAP_SHARED（Linux/macOS）或没调FlushViewOfFile（Windows）
正确做法：
- 只用
slice[i]、copy(dst, mm[:n])这类不改变底层数组结构的操作 - 写入前确认 flag 是
mmap.RDWR（对应PROT_READ|PROT_WRITE）且mmap.SHARED（否则修改不会落盘） - 写完记得调
mm.Flush()（mmap-go提供），尤其在程序退出前，避免脏页丢失
大文件随机读性能提升明显，但小文件或顺序读反而更慢
mmap 的优势在于避免内核态/用户态数据拷贝，适合频繁随机访问固定区域的大文件（比如数据库索引、日志检索）。但它有启动开销：首次访问会触发缺页中断，建立页表映射；而且整个映射区会占用进程的虚拟地址空间（虽不占物理内存，但 32 位进程易撞到 4GB 限制）。
使用场景判断：
- ✅ 适合：100MB+ 文件、需要按 offset 频繁跳读（如解析 protobuf message by tag）、多 goroutine 并发读同一块只读区域
- ❌ 不适合：小于 1MB 的文件（系统调用开销反超）、纯顺序流式读（
bufio.Scanner更轻量）、需加密/解压后再处理的场景（mmap 无法介入中间过程） - ⚠️ 注意：Linux 下
mmap默认启用MAP_POPULATE会预加载所有页，导致启动卡顿；生产环境建议用mmap.FLAG_NO_RESERVE或手动madvise(MADV_WILLNEED)
关闭映射必须显式调 mm.Unmap()，否则资源泄漏
Go 的 GC 不管理 mmap 分配的虚拟内存。不调 Unmap()，进程的 VMA（virtual memory area）条目会一直存在，Linux 下表现为 /proc/PID/maps 里持续增长，最终可能触发 ENOMEM。
实操要点：
- 务必在
defer mm.Unmap()，尤其在函数早 return 路径上 - 不要依赖
finalizer：GC 触发时机不确定，Unmap 太晚会导致文件被锁住（Windows）或 mmap 区域残留 - 如果映射用于长期服务（如配置热加载），每次 reload 必须先
Unmap旧的，再Mmap新的；重复映射同一文件不同 offset 不冲突，但同一 offset 多次映射会增加 VMA 数量
最常被忽略的一点：mmap 的生命周期和文件句柄无关。即使 os.File.Close() 了，只要 mm.Unmap() 没调，映射依然有效——这既是灵活性，也是泄漏温床。
