是的，Go值传递会完整拷贝结构体，引发内存与CPU暴涨；超64字节、含大字段或高频调用时应改用指针传参，并注意可变性与对齐填充问题。
大结构体传参时 CPU 和内存暴涨，是不是值传递在偷偷拷贝？
是的，Go 的值传递会完整复制整个结构体。如果结构体包含大量字段、嵌套结构或大数组（比如 []byte 字段本身不大，但指向的底层数组很大），每次函数调用都会触发一次内存分配+逐字节拷贝——这不是“看起来慢”，而是实打实的 memcpy 开销。
常见错误现象：pprof 显示 runtime.memmove 占比高；GC 频率异常上升；函数内联失败（go tool compile -gcflags="-m" 提示 cannot inline: unhandled op STRUCTLIT 等）。
- 结构体大小超过 128 字节时，编译器大概率放弃寄存器传参，改用栈拷贝，性能落差明显
- 即使结构体含指针字段（如
*sync.Mutex），只要结构体本身大，拷贝开销仍在——指针值被复制，但指向的对象不复制 - 方法接收者用值类型（
func (s MyStruct) Foo()）和函数参数用值类型，拷贝行为完全一致
什么时候该改用指针传参？看三个硬指标
别凭感觉，直接查结构体大小和字段构成。用 unsafe.Sizeof 和 reflect.TypeOf 检查，比猜靠谱得多。
- 结构体
unsafe.Sizeof(T{}) > 64（保守阈值，实际 32–128 之间需结合调用频次判断） - 含可导出字段且字段类型本身较大（如
[1024]int64、map[string]*big.Int） - 该结构体在 hot path 上被高频调用（如 HTTP handler 内、循环体中、goroutine 启动参数）
注意：改用指针后，接收方能修改原结构体内容——如果业务逻辑依赖不可变性，得加注释或封装只读接口，否则容易引入隐蔽 bug。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
结构体里有 slice/map/chan/function，值传递还安全吗？
安全，但「安全」不等于「无开销」。这些类型底层都是小结构体（通常 24 字节以内），值传递只拷贝头信息，不拷贝底层数组或哈希表数据。
-
slice拷贝的是ptr+len+cap三元组，原 slice 和副本共享底层数组 -
map拷贝的是hmap*指针，副本和原 map 操作同一张哈希表 -
chan拷贝的是hchan*指针，同样共享通道状态 - 所以这类字段不会导致大拷贝，但可能引发竞态——比如多个 goroutine 通过不同副本写同一个 map
典型陷阱：func process(data MyStruct) { data.items = append(data.items, x) } —— 看似没改原结构体，但 append 可能扩容，导致底层数组地址变化，原 data.items 不受影响；而如果 items 是 map，data.items["k"] = v 就真改了原 map。
想零拷贝又不想暴露可变性？用只读包装 + 接口约束
直接暴露 *MyStruct 容易被误改。更稳妥的方式是定义只读接口，内部用指针实现，但禁止写操作。
type ReadOnlyData interface {
GetID() int
GetName() string
// 不提供 SetXXX 方法
}
type myStruct struct {
id int
name string
data []byte // 大字段，但只读访问
}
func (m *myStruct) GetID() int { return m.id }
func (m *myStruct) GetName() string { return m.name }
调用方拿到的是接口值，底层仍是指针，零拷贝；同时无法调用未导出的字段或方法，天然防误改。比单纯加文档注释或靠约定更可靠。
真正容易被忽略的点：结构体对齐填充（padding）也会放大拷贝体积。一个含 int8 + int64 + int8 的结构体，unsafe.Sizeof 可能是 24 而不是 10——字段顺序要按大小倒排才能压缩 padding，这点在性能敏感场景必须手算验证。
