Go中channel传递值类型会完整拷贝数据，包括struct等大结构体，导致显著性能开销。
channel 传递值类型时会完整拷贝数据
go 中所有 channel 操作都是值拷贝——哪怕你传的是
或
，底层也按字段逐字节复制。对
、
、
这类小值类型，拷贝开销几乎可忽略；但若发送的是大结构体（比如含 1mb 字段的
），每次
常见错误现象：goroutine 大量阻塞在
占比高；或接收端解包后发现字段被意外修改（其实是多个 goroutine 共享了同一块底层数组，见下一条）。
值类型（
、
）：直接栈拷贝，安全且快
引用类型（
、
、
）：只拷贝 header（指针+长度+容量等），不拷贝底层数组/哈希表本身
注意：
的 header 拷贝后，发送方和接收方仍指向同一底层数组——这就是数据竞争根源
[]byte 通过 channel 传递时共享底层数组是默认行为
切片不是“深值”，它只是三个字段的结构体：
（指针）、
、
。当你执行
指针值被复制，指向的仍是原数组。若发送方后续继续写
，而接收方还没读完前一次发的
，就会看到脏数据。
使用场景：生成组合字符串、批量编码、日志行缓冲等循环复用同一底层数组的典型模式。
错误写法：
正确做法：每次发送前创建独立副本，如
性能权衡：
比直接传
多一次堆分配，但换来确定性行为；若数据量小（sync.Pool 管理副本
用指针替代值传递能规避拷贝但引入新风险
把
或
发给 channel，只拷贝 8 字节指针，零拷贝。但必须确保：发送方不再修改该对象，且接收方消费完后不继续持有（否则可能引发 use-after-free 或 GC 延迟）。
容易踩的坑：
发送方在
出作用域（如函数返回），此时指针可能指向已回收栈内存 → 接收端读取 panic 或乱码
多个 goroutine 同时读写同一指针目标 → 仍需额外同步（
或原子操作）
GC 无法及时回收被 channel 缓冲区或接收方长期持有的对象 → 内存泄漏迹象
建议仅在明确生命周期可控、且对象体积 > 1KB 时采用；小对象不如直接传值或切片副本。
缓冲通道不会降低单次拷贝成本，但影响整体吞吐
中的
只决定缓冲区长度，不影响每次
性能影响关键点：
缓冲区过小（如
）：接近无缓冲行为，频繁阻塞/唤醒，上下文切换开销主导
缓冲区过大（如
）：channel 内部
数组占用大量连续内存，且
索引更新、
移动元素成本上升
最佳实践：根据平均批次大小设缓冲，例如每批发 64 个
，缓冲设为 64 或 128；避免盲目调大
真正影响拷贝成本的，永远是你要发的值本身——类型、大小、是否复用底层数组。channel 只是管道，不是魔法压缩器。
[]bytestruct{}intstringboolstructch 都会触发一次完整内存拷贝，cpu 和 gc 压力明显上升。ch ，pprof 显示 runtime.memmoveint[32]byte[]bytemap[string]int*T[]bytedatalencapch ，实际拷贝的是这三个字段，datares[0] = 1resres := make([]byte, N); for ... { res[i] = x; ch → 所有接收端看到的可能是最后一次迭代的结果send := make([]byte, len(res)); copy(send, res); ch make + copyres*[]byte*MyBigStructch 后立即让 xsync.Mutexmake(chan T, N)N 或 的数据拷贝逻辑。缓冲的作用是解耦发送与接收时机：发送方不必等待接收方就绪，从而减少 goroutine 阻塞切换次数。110000bufsendx/recvxmemmove[]byte