syscall.mmap映射普通文件无法跨进程共享内存，因linux内核仅同步文件内容而非物理页；正确方案是用unix.shmopen+unix.mmap创建posix共享内存对象。
syscall.Mmap 单独映射普通文件无法实现跨进程共享内存，这是内核语义限制，不是代码写错的问题
为什么 syscall.Mmap 映射文件必然失败
常见错误现象：A 进程写入后，B 进程读不到新值、读到零、panic 或 SIGBUS；两个进程都调用成功，但数据不一致。
-
syscall.Mmap接收的是普通文件 fd，Linux 对其MAP_SHARED映射仅保证“文件内容同步”，不保证多个进程看到同一物理页——它本质是带缓存的文件视图，不是共享内存对象 - 即使都设
syscall.MAP_SHARED，ext4/xfs 默认启用日志（journal），每次写都落盘或刷 page cache，延迟高且非原子 - 映射前未调
syscall.Ftruncate(fd, size)，mmap直接返回EINVAL，但 Go 里常被忽略，导致后续操作崩溃 - Go 的
os.File不暴露底层 fd，必须用syscall.Open或unix.Open获取 raw fd 才能传给syscall.Mmap
真正可用的路径：用 unix.ShmOpen + unix.Mmap
POSIX 共享内存对象由内核管理，不落盘、无文件路径、生命周期可控，是唯一可落地的方案（Linux/macOS）。
- 名称必须以
/开头且不含其他/，如"/myshm"；不能是相对路径、不能含点号、不能是文件路径 - 创建方调
unix.ShmOpen("/myshm", unix.O_CREAT|unix.O_RDWR, 0600)；加入方只用unix.ShmOpen("/myshm", unix.O_RDWR, 0)（不带O_CREAT） -
unix.Ftruncate(fd, size)必须在unix.Mmap前执行，且size需对齐页边界（通常 ≥4096） -
unix.Mmap的flags必须含unix.MAP_SHARED，prot至少为unix.PROT_READ | unix.PROT_WRITE - 映射后需用
unsafe.Slice(unsafe.Pointer(&data[0]), len)转为切片；不能直接copy到未初始化变量，否则 panic
同步机制不能复用 Go 标准库原语
sync.Mutex、sync/atomic 在跨进程场景完全无效——它们依赖单进程虚拟地址空间和 runtime 状态。
- 跨进程锁必须用 POSIX 信号量：
unix.SemOpen("/mysem", unix.O_CREAT, 0600, 1)，配合unix.SemWait/unix.SemPost - 也可以在共享内存内手动放置
pthread_mutex_t（需按 ABI 对齐并初始化），但移植性差、易出错 - 若只读不写，或写入有明确顺序（如 producer 写完再通知 consumer），可省略锁，但必须用内存屏障或轮询+标志位协调可见性
-
unix.ShmUnlink("/myshm")应在最后一个进程退出前调用，否则对象残留；它不立即释放，而是等所有 fd 关闭后自动清理
更简单、更可靠的替代方案
除非吞吐 >100MB/s 且延迟压到微秒级，否则别碰共享内存——net.UnixConn 和 os.Pipe 已足够快，且无同步陷阱。
-
net.UnixConn在本地 loopback 上实测吞吐超 100MB/s，延迟稳定在几十微秒，API 简洁、自动 cleanup、天然支持 goroutine 并发 -
os.Pipe是内核 pipe buffer，零拷贝发生在 kernel space，用户态只需Read/Write，无需处理 fd 生命周期或页对齐 - 若进程间结构化数据通信为主，用 JSON over Unix domain socket 比手撸共享内存 + 序列化更安全、更易调试
共享内存的复杂点不在映射本身，而在跨进程同步的精确控制——稍有不慎就是数据错位或死锁，而这些 bug 往往只在高负载、多核、特定调度路径下才暴露。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
