syscall.Mmap 单独调用无法实现跨进程共享内存通信，因其仅映射普通文件，内核不保证多进程映射到同一物理页；必须配合 shm_open 创建 POSIX 共享内存对象，再 mmap 映射，才能确保写入对其他进程可见。
不能直接用 syscall.Mmap 实现跨进程共享内存通信——它只映射普通文件，Linux 内核不保证多进程映射到同一物理页，写入对另一进程不可见。
为什么 syscall.Mmap 单独调用总是失败
常见错误现象：syscall.Mmap 返回成功，进程 A 写了数据，进程 B 读到空值、旧值或乱码。
根本原因：普通文件（如 os.Open 打开的）被两个进程各自 mmap 后，只是各自建立了独立的文件映射实例；即使都用 MAP_SHARED，内核也不会强制它们共享物理页。写操作只刷新本进程页缓存，不触发跨进程可见性。
关键区别：
-
shm_open创建的是 POSIX 共享内存对象（内核级 backing store），所有打开它的进程天然共享同一块物理内存 -
os.Open+syscall.Mmap映射的是普通文件，MAP_SHARED仅保证“写回磁盘”，不提供跨进程内存一致性
必须用 shm_open + mmap 组合（Linux/macOS）
这是目前唯一可落地的路径。Windows 完全不支持 shm_open，需换方案（如 CreateFileMapping）。
进程 A（创建者）必须按顺序执行：
- 调用
syscall.ShmOpen("/myshm", syscall.O_CREAT|syscall.O_RDWR, 0600) - 立刻调用
syscall.Ftruncate(fd, size)—— 必须在mmap前，否则mmap返回EINVAL - 再调用
syscall.Mmap(fd, 0, size, syscall.PROT_READ|syscall.PROT_WRITE, syscall.MAP_SHARED)
进程 B（加入者）必须：
- 用相同名称调用
syscall.ShmOpen("/myshm", syscall.O_RDWR, 0)—— 不带O_CREAT，否则可能覆盖 - 建议也调用
Ftruncate并校验大小，避免长度不一致导致越界访问 -
Mmap参数（长度、prot、flags）必须与 A 完全一致
示例片段（省略错误检查）：
fd, _ := syscall.ShmOpen("/go_shm", syscall.O_CREAT|syscall.O_RDWR, 0600)
syscall.Ftruncate(fd, 4096)
data, _ := syscall.Mmap(fd, 0, 4096, syscall.PROT_READ|syscall.PROT_WRITE, syscall.MAP_SHARED)
同步机制不能靠 sync.Mutex 或 atomic
常见误用：sync.Mutex 字段含运行时指针和状态，放到 mmap 区域里会 panic；atomic.CompareAndSwapUint32 只在单进程地址空间内原子，跨进程完全无效。
正确做法：同步原语本身也得驻留在共享内存中，并由 OS 保证跨进程语义：
- POSIX 信号量：
sem_open("/mysem", syscall.O_CREAT, 0600, 1)，然后sem_wait/sem_post - System V 信号量：
syscall.Semget+syscall.Semop（需手动初始化、注意权限和键冲突） - 不能把
pthread_mutex_t直接放在 mmap 区域里初始化——它依赖进程私有状态，跨进程未定义行为
实际项目中几乎没人这么干
原因很实在：要手写 shm_open + mmap + sem_open + munmap + shm_unlink 全套系统调用，还要处理页对齐、资源泄漏、进程意外退出导致的死锁、macOS 名称必须以 / 开头、Linux 需链接 -lrt 等细节。
更现实的选择：
-
gRPCover Unix socket：grpc.Dial("unix:///tmp/my.sock")，零 TLS 开销、结构化协议、自带流控 - 原生
net.ListenUnix+json.Encoder/Decoder：轻量、易调试、吞吐足够大多数服务间通信 - 嵌入式键值库如
bbolt：单文件、MVCC、支持 mmap 只读视图，适合共享状态而非高频低延迟场景
除非你在做高频量化交易中间件或实时音视频帧交换，否则共享内存带来的复杂度远超收益——它不是“更快的 IPC”，而是“更难正确实现的 IPC”。
