应避免用 unsafe.Pointer 零拷贝传递大结构体，因其破坏类型安全且干扰 GC；推荐 sync.Pool 复用、指针+接口明确所有权、binary 序列化替代 JSON。
用 unsafe.Pointer 零拷贝传递大结构体？别这么做
Go 的模块边界（module）本质是编译期的依赖管理单位，运行时没有“模块间内存隔离”这回事。所谓“模块间传递大数据”，实际是函数调用或接口实现中的值传递问题。直接上 unsafe.Pointer 不仅破坏类型安全，还会让 GC 无法追踪对象，极易引发 panic 或静默内存错误。真正该关注的是：怎么避免无谓的复制，同时不牺牲可维护性。
sync.Pool 能复用大对象，但要注意生命周期错位
如果多个模块频繁创建/销毁同构的大对象（比如 []byte 缓冲区、预分配的 JSON 解析结构体），sync.Pool 是最稳妥的复用方案。但它只解决“重复分配”，不解决“跨模块共享”。关键陷阱在于：
-
sync.Pool中的对象可能被 GC 清理，不能假设 Get() 一定返回非 nil - 对象从 Pool 取出后，若被长期持有（比如塞进 channel 或传给 goroutine），就违背了 Pool “短期复用”设计初衷，容易导致内存泄漏
- 不同模块若各自定义独立的
sync.Pool变量，反而造成资源割裂，应由最上游模块（如初始化入口）统一声明并导出
示例：模块 A 定义 var BufPool = sync.Pool{New: func() any { return make([]byte, 0, 4096) }}，模块 B 直接 import 并调用 BufPool.Get() —— 这比每次 make([]byte, n) 省 CPU，也比全局变量更可控。
接口 + 指针传递是默认推荐方式，但得明确所有权
Go 中传递大结构体的正统做法就是传指针（*BigStruct），配合接口抽象行为。这不是妥协，而是设计必然：GC 需要精确追踪堆上对象，而指针传递天然满足这点。重点在于厘清所有权归属：
立即学习“go语言免费学习笔记（深入）”；
- 如果接收方只是临时读取（如日志模块打印统计信息），用
func Process(s *BigStruct)即可，不需深拷贝 - 如果接收方要修改并长期持有（如缓存模块保存一份快照），必须显式深拷贝——用
github.com/jinzhu/copier或手写字段级复制，不能依赖浅拷贝 - 避免在接口方法签名中暴露具体大结构体指针（如
type Processor interface { Handle(*UserOrder) }），改用更窄接口（如Handle(OrderReader)），把数据访问封装在方法内
跨模块大对象序列化？优先选 encoding/binary 而非 json
当模块间通信必须走序列化（比如通过 RPC、消息队列），JSON 的可读性代价太高：字符串键名重复编码、浮点数转字符串再解析、无类型信息导致反射开销。对百 KB 以上对象，性能差距可达 3–5 倍。
更高效的选择：
- 二进制协议：
encoding/binary（固定结构）、gogoproto（兼容 protobuf，零分配反序列化） - 内存映射：
mmap+unsafe.Slice（仅限同一进程内多 goroutine 共享只读大数据，如模型权重） - 绝对避免：用
gob跨模块传递 —— 它依赖 Go 类型名和包路径，模块版本不一致时 decode 直接 panic
比如模块 A 把 type Metrics struct { Total int64; LatencyMs float64 } 写入文件，模块 B 用 binary.Read(f, binary.LittleEndian, &m) 读取，比 JSON 快且无 GC 压力。
真正难的不是“怎么传”，而是“谁负责释放”和“何时不再需要”。模块边界模糊时，最容易在 defer、channel 关闭、goroutine 退出这几个节点漏掉清理逻辑。建议所有大对象的生命周期都绑定到 context.Context，超时或取消时触发显式回收。
