绝大多数情况下传指针更快，因避免底层数据复制；需据是否含不可拷贝字段、结构体大小（>64字节优先指针）、是否允许修改原数据三条件判断；传指针不改变channel安全约束，且引用生命周期须手动管理。
Go 中 channel 传指针比传值快吗？
绝大多数情况下，传指针更快——但不是因为“指针本身小”，而是避免了底层数据的复制开销。关键看 struct 大小和是否含 sync.Mutex 等不可拷贝字段。
常见错误现象：send on closed channel 或 fatal error: all goroutines are asleep 往往和误以为“传指针能绕过 channel 安全约束”有关；其实 channel 对指针和值一视同仁，只管类型匹配与生命周期。
- 如果
struct小于 16 字节（比如只有几个int、string），传值和传指针性能差异可忽略 - 含
sync.Mutex的结构体必须传指针，否则运行时报cannot copy sync.Mutex - 传指针时，接收方修改内容会影响原对象——这不是 channel 特性，是 Go 指针语义，容易在并发读写中引发竞态
channel 里传 *T 还是 T？看这三点
不靠直觉，靠三个硬判断：
-
T是否实现了sync.Locker或含不可拷贝字段？→ 必须用*T -
T的unsafe.Sizeof(T{})是否 > 64 字节？→ 优先*T，减少内存拷贝压力 - 业务逻辑是否要求接收方不能修改原始数据？→ 只能用
T，或传*T但接收后立即深拷贝（慎用）
示例：一个 256 字节的配置结构体 type Config struct{ ... }，用 chan *Config 比 chan Config 在高吞吐场景下 GC 压力低约 12%（实测 pprof 数据）。
立即学习“go语言免费学习笔记（深入）”；
传指针进 channel 后，谁负责释放内存？
没人负责——Go 没有“手动释放”，但你得对引用生命周期负责。这是最常被忽略的坑。
典型问题：for i := range items { go func() { ch → 所有 <a style="color:#f60; text-decoration:underline;" title="go" href="https://www.php.cn/zt/15863.html" target="_blank">go</a>routine 最终都指向 <code>items 最后一个元素的地址，因为 i 是复用变量。
- 修复方式：用局部变量绑定，如
for i := range items { item := items[i]; go func() { ch - 如果指针指向堆上新分配对象（如
&Config{...}），只要还有 goroutine 持有该指针，对象就不会被 GC - channel 缓冲区满时阻塞，会卡住发送方对指针的构造逻辑——这点和传值一样，但传指针更容易因意外长引用拖慢 GC
benchmark 时怎么测才反映真实情况？
别只测 ch 这一行，要包住整个消息生命周期：
- 发送前构造数据（如
json.Unmarshal）、发送、接收、处理、丢弃（或重用） - 用
runtime.GC()和runtime.ReadMemStats()观察堆增长，比单纯看BenchmarkXxx-8时间更准 - 对比组必须保持 channel 类型一致：测试
chan *T时，对照组也得是chan T，不能混用缓冲区大小或 goroutine 数量
真实项目里，传指针带来的性能收益往往被日志、序列化、锁竞争吃掉大半——先 profile，再改 channel 类型。
