Go标准库不原生支持mmap，需用第三方包如github.com/edsrzf/mmap-go；它跨平台、安全、提供io.ReaderAt接口，避免syscall.Mmap的资源泄漏和Windows兼容问题。
Go 里 mmap 不是标准库原生支持，得用 mmap 第三方包
Go 标准库没有提供跨平台的内存映射接口，syscall.Mmap 虽然存在，但只封装了底层系统调用，缺少自动清理、错误抽象和 Windows 兼容处理。直接用它容易漏掉 syscall.Munmap 导致资源泄漏，或在 Windows 上因页对齐/句柄管理出错而 panic。
推荐使用 github.com/edsrzf/mmap-go（轻量、维护活跃、覆盖 Linux/macOS/Windows）：
go get github.com/edsrzf/mmap-go
它的 mmap.Map 类型实现了 io.Reader 和 io.ReaderAt，还能直接转 []byte，比裸 syscall 安全得多。
读取超大文件时，别一次性 mmap.Map 整个文件
映射几十 GB 文件会成功，但不等于安全：进程虚拟地址空间可能被撑满（尤其 32 位环境），且 mmap 本身不加载数据到物理内存，真正访问时才触发缺页中断——如果随机跳读，会造成大量磁盘抖动，性能反而不如顺序 os.Read。
更合理的做法是按需映射分段：
- 用
os.Stat获取文件大小，按固定块大小（如 64MB）切分逻辑区间 - 每次只
mmap.Map当前需要访问的块，用完立刻Unmap - 避免跨块缓存整个
[]byte，改用copy(dst, mm[off:off+n])局部读取
示例关键片段：
mm, err := mmap.Map(file, mmap.RDONLY, 0)
if err != nil {
panic(err)
}
defer mm.Unmap() // 注意：这里只卸载当前映射，不是整个文件
<p>// 只读取第 10GB 开始的 1MB
offset := int64(10 <em> 1024 </em> 1024 <em> 1024)
n := 1024 </em> 1024
data := make([]byte, n)
copy(data, mm[offset:offset+int64(n)])
mmap.Map 的 prot 和 flags 参数影响实际行为
第三个参数 prot 控制内存页权限：mmap.RDONLY 最常用；若需修改并同步回磁盘，得用 mmap.RDWR 并确保文件以 os.O_RDWR 打开；mmap.COPY（写时复制）极少用，且 Windows 不支持。
第四个参数 flags 决定映射类型：
-
mmap.ANONYMOUS：创建匿名映射（不关联文件），和读文件无关 -
mmap.SHARED（默认）：修改会写回文件，多进程可共享视图 -
mmap.PRIVATE：修改不落盘，仅本进程可见（适合只读场景下避免意外写）
多数只读场景传 mmap.RDONLY | mmap.SHARED 即可，不必动 flags。
Windows 下路径、权限、文件锁容易导致 mmap.Map 失败
Windows 对内存映射限制更严格：文件必须以 os.O_RDONLY 或 os.O_RDWR 打开，且不能被其他进程以独占模式锁定（比如 Excel 正在编辑的 .csv）；路径中含中文或长路径（>260 字符）时，需启用 \? 前缀并用 syscall.UTF16FromString 转换。
常见报错：
-
operation not supported→ 检查打开文件时是否用了os.O_CREATE或os.O_TRUNC -
access is denied→ 文件被占用，或当前用户无读权限（尤其 NTFS ACL） -
invalid argument→ offset 或 length 未按系统页大小（通常 4KB）对齐
建议在 Windows 上先用 os.Open 成功后再 mmap，不要复用已关闭的 *os.File。
真正麻烦的不是映射本身，而是边界对齐、跨平台页大小差异、以及“以为映射了就等于数据在内存里”这种误解。实测中，顺序读大文件时，mmap 和 buffered os.ReadFile 性能差距往往不到 10%，但 mmap 的调试成本高得多——除非你明确需要随机访问 + 零拷贝，否则别为了“炫技”硬上。
