Go 中不能直接用 syscall.Mmap，因其不处理平台差异、页对齐、错误映射及生命周期管理，且 GC 不感知内存绑定，易致 SIGBUS 或 panic；Windows 无真正 mmap 支持，Linux/macOS 要求 offset 页对齐。
为什么 mmap 在 Go 里不能直接用 syscall.Mmap 就完事？
Go 标准库没封装 mmap，syscall.Mmap 是底层裸接口，不处理平台差异、页对齐、错误码映射，更不管理生命周期。直接调用容易 panic 或静默失败。
-
syscall.Mmap返回的[]byte底层数组和虚拟内存绑定，但 Go 的 GC 不知道这块内存不能动，若切片被回收或重用，可能触发 SIGBUS - Windows 上要用
VirtualAlloc+MapViewOfFile，不是mmap语义，syscall.Mmap在 Windows 是 stub，直接调用会报ENOSYS - Linux/macOS 要求
offset必须是页大小（通常 4096）整数倍，传错会返回EINVAL，而文件开头偏移为 0 是安全的，但读中间块时极易踩坑
推荐用 golang.org/x/exp/mmap（虽处 exp 下，但已稳定用于生产），它自动处理对齐、跨平台映射、并提供 Unmap 显式释放。
读大文件时，mmap 真比 os.ReadFile 快？
不一定。小文件（<1MB）用 mmap 反而更慢：多了系统调用开销、页表建立、缺页中断；真正受益的是随机访问 >100MB 的只读场景，比如日志索引、二进制数据库。
-
os.ReadFile会一次性malloc内存 +read(2)，适合顺序读、内存充足、文件可载入 -
mmap按需加载（lazy fault），首次访问某页才从磁盘拉，内存占用低，但随机跳读多时，缺页中断频繁，延迟毛刺明显 - 若文件被其他进程截断或删掉，
mmap区域会变成SIGBUS，而ReadFile早已经拿到副本，更“钝感”
示例：读取 2GB 日志中第 1.5GB 处的 1KB 数据
立即学习“go语言免费学习笔记（深入）”；
data, _ := mmap.Open("/var/log/app.log")
defer data.Unmap()
// 直接 slice 访问，无需 seek + read
chunk := data.Bytes()[1500*1024*1024 : 1500*1024*1024+1024]
mmap 写文件时，为什么改了内存但磁盘没更新？
因为默认是 MAP_PRIVATE（写时复制），修改只影响当前进程虚拟内存，不落盘。要持久化，必须：
- 创建时用
MAP_SHARED标志（mmap.OpenFlag中设mmap.RDWR | mmap.SHARED） - 修改后调用
msync—— Go 的golang.org/x/exp/mmap提供Flush()方法，本质是msync(MS_SYNC) - 不调
Flush，仅靠Unmap无法保证写入，内核可能延迟刷盘甚至丢数据（尤其断电）
常见错误现象：程序退出后文件内容仍是旧的，或另一进程读不到最新修改。
注意：msync 是阻塞系统调用，高频写时别每改一次就 flush，可批量改完再 flush，或依赖内核后台回写（但不可靠）。
用 mmap 做进程间共享内存靠谱吗？
可以，但别绕过同步机制。Linux/macOS 下 mmap + MAP_SHARED + 同一个文件路径，确实能让多个进程看到同一块内存，但：
- 文件必须存在且有读写权限，且所有进程用相同
offset和length映射，否则视图错位 - Go 的
runtime不保证对共享内存的原子操作（如int64写），需用sync/atomic或mutex配合unsafe.Pointer手动操作 - Windows 上需用
CreateFileMapping+OpenFileMapping，语义不同，x/exp/mmap不支持跨进程共享，得换方案（如github.com/edsrzf/mmap-go）
最易忽略的一点：没有文件锁或信号量，纯靠内存地址通信，一旦某个进程 panic 未清理状态，其他进程可能读到脏/中间态数据。实际项目中，建议只用 mmap 共享只读数据，读写协调仍走管道或 socket。
