go 中 chan 不能直接做双向内存映射，它只是协程间通信的抽象管道，数据通过拷贝传递，不暴露内存地址，也不支持 mmap 或共享内存语义。
Go 中 chan 不能直接做双向内存映射，别被“通道”字面意思误导
Go 的 chan 是协程间通信的抽象管道，底层不暴露内存地址，也不支持 mmap 或共享内存语义。所谓“双向传输”仅指可读可写（如 chan int），但数据仍经拷贝传递；它和操作系统级的内存映射（如 mmap）完全无关。如果你需要进程间共享内存 + 通知机制，得组合用其他手段。
想让两个 goroutine 安全地读写同一块内存？用 sync.Mutex + 普通变量更直接
Channel 适合解耦生产者/消费者模型，但若只是多个 goroutine 频繁读写同一结构体字段（比如计数器、状态标志），走 chan 反而引入额外调度开销和复制成本。此时裸指针 + 锁更轻量：
var (
sharedData struct {
counter int
mu sync.Mutex
}
)
// 写
sharedData.mu.Lock()
sharedData.counter++
sharedData.mu.Unlock()
// 读
sharedData.mu.Lock()
val := sharedData.counter
sharedData.mu.Unlock()
-
chan传递结构体时默认拷贝整个值，大对象性能差；指针传chan *T能避免拷贝，但需自行保证所指内存生命周期 -
sync/atomic对简单类型（int32,uintptr）更高效，无需锁，但不适用于复合结构 - 别用
chan去模拟“共享内存访问”，它不是为这个设计的
真要跨进程共享内存并通知变化？Linux 下用 mmap + sync.Cond 或信号量
Go 标准库不提供跨进程共享内存封装，得调用系统调用。典型做法是：syscall.Mmap 创建映射区，再用 sync.Cond（配合 sync.RWMutex）或 semaphore 实现变更通知。注意几个硬坑：
-
syscall.Mmap返回的是[]byte，你得手动按结构体布局解析（用unsafe+reflect或encoding/binary序列化） - 映射文件必须已存在且大小固定（
ftruncate预分配），否则读写越界会 panic - 不同进程的
Cond无法共用——必须用 POSIX 信号量（sem_open）或文件锁（flock）同步 - Windows 下对应是
CreateFileMapping，API 和语义差异大，别指望跨平台零修改
误把 chan 当共享内存用的典型错误现象
常见症状包括：goroutine 卡死、数据“丢失”、压测时 CPU 突增但吞吐不上升。本质是混淆了通信（communication）和共享（sharing）两种并发模型：
- 往
chan发一个大结构体，收端拿到的是副本，改它不影响发端数据 → 不是共享 - 多个 goroutine 同时向同一个
chan发送，但没控制速率，导致缓冲区满后阻塞 → 表现像“写冲突”，实则是流控问题 - 用
close(ch)后继续 send → panic: send on closed channel；而共享内存不会因“关闭”失效 - 期望 Channel 有“内存可见性保证”（类似 volatile）→ 实际上 Go 内存模型只保证
chan操作本身同步，不延伸到所传数据内部字段
真正需要双向共享内存的场景极少，多数时候是设计过度。先确认是否真的绕不开 mmap —— 很多所谓“高性能共享”需求，用带缓冲的 chan + 批量处理就能满足。
