syscall.Mmap panic 常因 length 超文件大小或打开模式错误；需 Stat 校验大小，写入前用 Ftruncate 预分配；Windows 须用 x/sys/windows 替代；MAP_SHARED 才持久化，需 MS_SYNC 刷盘；Munmap 必用原始切片且仅一次；mmap 适合大文件随机访问，小文件或顺序读优先用 bufio。
syscall.Mmap 在 Go 中映射大文件时为何 panic: invalid argument
常见原因是传入的 length 超出文件实际大小，或文件未以 O_RDWR（写入场景）或 O_RDONLY（只读场景）打开且未设置 os.File.Stat().Size() 校验。Go 的 syscall.Mmap 不会自动截断或扩展文件，它严格要求映射长度 ≤ 文件当前大小（除非用 ftruncate 预分配）。
- 映射前务必用
fi, _ := f.Stat(); length := fi.Size()获取真实大小，别硬写常量 - 若需写入并扩大文件，先调
syscall.Ftruncate(int(f.Fd()), newSize)，再Mmap - Windows 下不支持
syscall.Mmap，得用golang.org/x/sys/windows的CreateFileMapping替代 -
prot参数：只读映射用syscall.PROT_READ；写入必须含syscall.PROT_WRITE，且文件句柄需可写
为什么 mmap 后修改内存没反应到磁盘文件
因为默认是私有映射（syscall.MAP_PRIVATE），所有修改只在内存副本生效，不会回写。要持久化，必须用 syscall.MAP_SHARED，且确保底层文件系统支持（如 ext4、NTFS 可以，某些网络文件系统或 tmpfs 可能不行）。
- 用
syscall.MAP_SHARED代替syscall.MAP_PRIVATE - 写完后建议显式调
syscall.Msync(b, syscall.MS_SYNC)强制刷盘，避免因系统延迟导致数据未落盘 - 注意：即使
MAP_SHARED，如果文件被其他进程 truncate 或 unlink，你的映射区域可能变成“幽灵页”，读写会触发SIGBUS
如何安全释放 mmap 内存避免资源泄漏
Go 没有自动 GC 映射内存，syscall.Munmap 必须手动调，且只能对原始 Mmap 返回的字节切片底层数组调用，不能对子切片或 copy 出来的副本操作。
- 务必在
defer或明确退出路径中调syscall.Munmap(data)，其中data是Mmap返回的原始[]byte - 不要对
data[100:200]这类子切片调Munmap—— 会 panic: “invalid argument” - 如果映射后做了
unsafe.Slice或指针转换，仍要用原始切片变量去Munmap - 多次
Munmap同一块内存会 crash，确保只释放一次
syscall.Mmap 和 bufio.NewReader 对比：什么场景该选 mmap
mmap 不是万能加速器。它省去了内核态/用户态拷贝，适合随机访问、多进程共享、超大文件（GB+）且访问稀疏的场景；但小文件、顺序遍历、需要解析逻辑（如按行 split）时，bufio 更简单稳定。
立即学习“go语言免费学习笔记（深入）”；
- 适合 mmap：日志文件随机查某 offset、内存数据库索引文件、图像像素块跳转访问
- 不适合 mmap：逐行读 CSV、流式解压、频繁
Read(p []byte)小 buffer - 性能陷阱：映射 10GB 文件只读前 1KB，仍会占用虚拟内存地址空间（但物理内存按需加载）；若系统 RAM 不足，可能引发 OOM Killer 杀进程
- 跨平台兼容性差：Linux/macOS 原生支持好；Windows 需额外 syscall 包；Android/iOS 不可用
真正难的是权衡：是否值得为 20% 的随机访问提速，承担多一倍的错误处理代码和平台限制。多数业务场景，先用 os.Open + io.ReadAt，真卡住了再切 mmap。
