直接用 syscall.mmap 风险高：windows 不可用，linux/macos 需手动页对齐、校验文件大小、匹配打开权限与 prot_* 标志，映射超长或越界会触发 sigbus；推荐用 mmap-go 库屏蔽平台差异、自动处理页对齐与错误，并强制 flush() 才落盘。
直接用 syscall.Mmap 会出 SIGBUS 或 panic，别硬刚
Go 标准库没封装跨平台 mmap，syscall.Mmap 是裸系统调用，参数稍错就 invalid argument 或运行时 SIGBUS。Windows 下它根本不可用（只返回 ENOSYS），Linux/macOS 还得手动对齐页边界、校验文件大小、匹配 os.OpenFile 权限和 PROT_* 标志。最常踩的坑是：映射长度写死 1024 * 1024 * 1024，但文件实际只有 300MB——内核直接拒绝。
- 必须先调
f.Stat()拿真实Size()，再传给syscall.Mmap - 只读映射只能用
os.Open+syscall.PROT_READ；写入必须用os.OpenFile(f, os.O_RDWR, 0)+syscall.PROT_READ | syscall.PROT_WRITE - 想写入并扩大文件？得先
syscall.Ftruncate(int(f.Fd()), newSize)，Mmap不会自动扩容 - 映射后切片越界访问、或向只读区域写入，触发的是硬件异常
SIGBUS，不是 Go 的panic，无法 recover
用 github.com/edsrzf/mmap-go 才算真正开箱即用
这个库屏蔽了平台差异：Linux/macOS 走 mmap(2)，Windows 走 CreateFileMapping + MapViewOfFile，自动处理页对齐、错误转换、len/cap 设置，还提供 mm.Len() 和 mm.IsWritable() 防越界。返回的 []byte 可直接下标访问，不用 unsafe.Slice 手动构造。
-
mmap.Open("file.dat", mmap.RDONLY)适合只读大日志、索引文件，macOS 下有额外优化 -
mmap.Map(file, mmap.RDWR, 0)要求file是os.O_RDWR打开的，否则写操作直接SIGBUS -
mm.Bytes()返回的切片已设好长度，禁止append或重切超出mm.Len() - 多 goroutine 并发读同一块映射区，无需加锁；并发写必须自己加文件锁（
syscall.Flock）
Flush() 不是可选项，不调就等于没写
mmap-go 默认用 MAP_SHARED，修改内存会反映到 page cache，但不会自动刷盘。断电、崩溃或进程被 kill，未 Flush() 的数据全丢。而 defer mm.Close() 或 mm.Unmap() 只释放映射，不触发同步。
- 写入后必须显式调
mm.Flush()，等价于msync(MS_SYNC) - 用
mmap.RDONLY打开的映射，Flush()直接返回错误（不可写） - 频繁小写入别每改一次都
Flush()，攒批后统一刷，否则 I/O 开销反超WriteAt - 若只是临时缓存（如解压中间态），需
MAP_PRIVATE，但该库不暴露 flag 控制，得退回syscall.Mmap自行构造
映射整文件 ≠ 性能最优，分段按需才是常态
映射几十 GB 文件可能成功，但不等于安全：32 位环境虚拟地址空间易耗尽；随机跳读会引发密集缺页中断，磁盘抖动严重，性能反而不如 bufio.Reader 顺序读。mmap 的优势在稀疏访问（如查第 1GB 和第 99GB 的某几 KB），而非扫全量。
- 用
os.Stat获取文件大小，按固定块（如 64MB）切分逻辑区间 - 每次只
mmap.Map当前需要访问的块，用完立刻mm.Unmap() - 避免缓存整个
[]byte，改用copy(dst, mm[off:off+n])局部读取 - 顺序遍历大文件，优先选
bufio.NewReader(f).Read；仅当需随机定位、零拷贝解析时才上 mmap
关键点不在“能不能映射”，而在“映射后怎么管生命周期”：文件描述符不能提前关闭（runtime.KeepAlive 有时必要）、映射区不能越界访问、写入后必须 Flush()、大映射要防 /proc/sys/vm/max_map_count 限制。这些细节漏掉一个，轻则 panic，重则数据静默损坏。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
