值拷贝性能影响取决于结构体大小、调用频率和内存布局：≤16字节几乎无感，＞64字节高频调用可能拖慢30%–50%；应结合unsafe.Sizeof()与场景选传值或指针。
值拷贝对性能影响大不大，取决于结构体大小、调用频率和内存布局——小结构体（≤16 字节）几乎无感，大结构体（＞64 字节）高频调用时，拷贝开销可能拖慢 30%–50%。
怎么快速判断一个结构体该传值还是传指针
别猜，用 unsafe.Sizeof() 看真实字节数，再结合使用场景做决策：
- ≤16 字节（约 2 个 machine word）：如
type Point struct{ X, Y int }，值接收者更安全、缓存友好，且避免逃逸 - 16–64 字节：性能差异通常＜10%，优先按语义选——需修改字段或已有指针方法，就统一用
*T - ＞64 字节：比如含
[1024]byte、多个 slice 或嵌套结构体，必须用指针传参/方法接收者，否则栈空间暴涨、CPU 缓存失效 - 含
slice、map、chan的结构体：即使很小，也建议用指针——不是为性能，而是防语义混淆（这些字段本身是引用头，值拷贝后仍共享底层数组）
为什么有时传指针反而变慢了
指针不是银弹。它省了拷贝，但可能引入新瓶颈：
- 逃逸到堆上：用
go build -gcflags "-m"检查，若变量从栈逃逸，会增加 GC 压力，尤其在短生命周期对象高频创建时 - 缓存局部性下降：值类型连续存放在栈上，CPU 缓存命中率高；指针跳转访问可能触发多次 cache miss
- 解引用开销：虽然单次极小，但在 tight loop（如每秒百万次调用）中会累积
- 并发风险被掩盖：传指针让意外修改更隐蔽，调试成本上升——这不是性能问题，但会让“性能优化”变成 bug 温床
实操中容易踩的三个坑
很多性能问题其实源于误解或疏忽，而不是结构体本身有多大：
立即学习“go语言免费学习笔记（深入）”；
-
误以为 “小结构体一定安全”：比如
type User struct{ Name string; Tags []string; Meta map[string]interface{} }，string和map字段虽小，但它们的头部（16–24 字节）被复制，而底层数组/哈希表仍共享——看似值传递，实则有隐式引用副作用 -
在循环里反复传值大结构体：如
for _, v := range items { process(v) }，若v是 200 字节结构体，每次迭代都拷贝，不如提前取地址：for i := range items { process(&items[i]) } -
返回值也拷贝：函数返回大结构体（如
func LoadConfig() Config）同样触发一次完整拷贝；若后续要多次读写，不如直接返回*Config，并确保调用方理解所有权语义
最常被忽略的一点：性能权衡不能脱离基准测试。同一结构体，在不同 Go 版本、不同 CPU 架构、不同负载模式下表现可能相反。用 go test -bench=. 跑真实数据，比凭经验拍板靠谱得多。
