结构体变大后性能下降主因是值拷贝开销剧增。含slice/map等字段或≥64字节时，应改用指针传参；小结构（如Point）值传参更高效；需权衡拷贝成本与解引用开销。
为什么结构体变大后性能突然下降
Go 中所有值类型（包括 struct）传参、赋值、返回时都会完整拷贝。当结构体字段增多（比如含多个 []byte、map[string]interface{} 或嵌套结构），一次拷贝可能达 KB 级，频繁调用（如循环内、HTTP handler 中）会显著抬高内存分配和 CPU 开销。
典型现象：pprof 显示 runtime.memmove 占比飙升，GC 压力增大，但逻辑本身没做重操作。
- 不是所有结构体都该改——小结构（
int、time.Time、3 字段以内且无 slice/map）拷贝开销可忽略 - 关键看「是否被高频传递」：函数参数 > 返回值 > 局部赋值
- 注意逃逸分析：
go build -gcflags="-m" main.go看是否因值拷贝导致本可栈分配的变量逃逸到堆
什么时候必须用指针传参而不是值传参
核心判断标准：该结构体是否在 ≥2 个不同作用域间被读写，且单次拷贝成本 > 函数调用开销（通常 ≈ 10–20 字节是分水岭）。
以下情况强烈建议改为 *T：
立即学习“go语言免费学习笔记（深入）”；
- 结构体含任何 slice、map、channel、func、interface{} 字段（它们底层含指针，值拷贝只复制头信息，但语义上常需共享）
- 结构体大小 ≥ 64 字节（x86-64 下 cache line 为 64 字节，跨 cache line 拷贝更慢）
- 作为方法接收者且方法内修改字段（否则编译器可能优化掉部分拷贝，但不可依赖）
反例：一个只读的 type Point struct{ X, Y int } 传参用值更高效，指针反而多一次解引用。
如何安全地把值类型转为指针而不破坏 API 兼容性
直接把函数签名从 func f(v MyStruct) 改成 func f(v *MyStruct) 是破坏性变更。稳妥做法分三步：
- 新增指针版本函数（如
fPtr），原函数内部转为调用它：func f(v MyStruct) { fPtr(&v) } - 对导出结构体添加
Clone()方法，方便使用者显式控制拷贝时机：func (s MyStruct) Clone() *MyStruct { c := s; return &c } - 若结构体已广泛使用，可通过 embedding + 接口抽象过渡，例如定义
type Reader interface{ GetX() int }，让旧代码继续用值，新代码用指针实现
注意：指针传参不等于线程安全——如果多个 goroutine 同时读写同一 *T，仍需加锁或用 sync/atomic。
哪些“看似值类型”的操作其实不拷贝
Go 运行时对部分场景做了隐式优化，不必盲目加指针：
-
for range遍历 slice 时，迭代变量是拷贝，但底层数据未复制：for _, v := range mySlice { /* v 是每个元素的拷贝 */ }—— 若mySlice元素本身很大，应遍历索引：for i := range mySlice { use(&mySlice[i]) } - 接口赋值（
var i interface{} = myStruct）会触发一次拷贝，但后续通过接口调用方法不会重复拷贝 - 小数组（如
[4]int）传参仍是值拷贝，但编译器可能将其拆成寄存器传参，实际比指针更快
真正要警惕的是「看不见的拷贝」：比如 JSON 反序列化到 struct 后立刻传给 5 个函数，每个都按值接收——这等于做了 5 次完整拷贝。
