syscall.Mmap 映射失败主因是长度超文件大小或权限不匹配；需用 f.Stat() 校验大小，按读写需求选 os.Open/os.OpenFile 及对应 prot；Windows 需用 x/sys/windows；mmap-go 写入后须显式 Flush() 才落盘。
syscall.Mmap 映射失败：常见 panic 原因和校验步骤
直接调用 syscall.Mmap 时 panic "invalid argument" 多半不是代码写错，而是文件状态或参数不匹配。最常被忽略的是：映射长度必须 ≤ 文件当前大小，且文件句柄权限必须匹配 prot 参数。
- 先用
f.Stat()拿真实大小，别硬写1024 * 1024 * 1024这类常量 - 只读映射必须用
os.Open+syscall.PROT_READ；写入必须用os.OpenFile(..., os.O_RDWR)+syscall.PROT_READ | syscall.PROT_WRITE - 想写入并扩大文件？得先
syscall.Ftruncate(int(f.Fd()), newSize)，Mmap不会自动扩容 - Windows 下完全不能用
syscall.Mmap，得切到golang.org/x/sys/windows的CreateFileMapping+MapViewOfFile
mmap-go 封装库怎么用才不丢数据
用 github.com/edsrzf/mmap-go 能避开平台差异和页对齐问题，但默认行为容易让人误以为“写完就落盘”——其实不是。
-
mmap.Open("file.dat", mmap.RDWR)默认是MAP_SHARED，修改会反映到文件，但仅驻留在 page cache - 关键写入后必须显式调
mm.Flush()，等价于msync(MS_SYNC)，否则断电或崩溃即丢失 - 不要依赖
defer mm.Close()来刷盘——Close()只做munmap，不触发同步 - 若只是临时缓存（如解压中间态），可用
mmap.Open("tmp", mmap.RDWR|...)配合MAP_PRIVATE，但该库不暴露 flag 控制，得退回syscall.Mmap自行构造
随机读 vs 顺序扫描：mmap 真的更快吗
mmap 在大文件场景下不是银弹，性能优势高度依赖访问模式。乱用反而比 os.File.ReadAt 或 bufio.Reader 更慢。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 适合：频繁跳转访问固定偏移（如日志按行号查、数据库索引定位）——内核按需加载页，省去整块拷贝
- 不适合：顺序遍历整个 50GB 文件——缺页中断密集，TLB 压力大，
bufio.NewReader(f).Read更稳 - 小文件（syscall.Mmap 本身开销 ≈ 几次系统调用，得不偿失
- 超大映射（>100GB）可能撞
/proc/sys/vm/max_map_count，报cannot allocate memory，需提前sysctl -w vm.max_map_count=262144
写入后 SIGBUS 怎么定位和修复
SIGBUS 通常发生在尝试访问未映射内存区域，Golang 中最典型的是：用 unsafe.Slice 计算偏移越界，或映射后文件被截断。
立即学习“go语言免费学习笔记（深入）”；
- Go 1.21+ 推荐用
unsafe.Slice(unsafe.Add(unsafe.Pointer(&data[0]), offset), length)替代老式data[offset:offset+length]，但前提是offset + length - 映射期间别让其他进程或本进程调
f.Truncate(0)—— mmap 区域仍指向原物理页，但文件元数据已失效 - 多 goroutine 并发访问同一 mmap 区域？确保没跨线程
munmap；必要时加runtime.LockOSThread()绑定 goroutine 到 OS 线程 - 调试时可加
defer func() { if r := recover(); r != nil { log.Printf("panic: %v", r) } }()捕获 SIGBUS 导致的 panic（虽然 SIGBUS 默认不 panic，但越界写常触发）
实际用起来，最易被跳过的点是：映射前校验文件大小、写入后强制 Flush、以及访问前确认 offset 边界。这三个动作不加，mmap 很快从加速器变成定时炸弹。
