值类型赋值时发生完整内存拷贝，非引用传递；结构体越大、调用越频繁，CPU和内存带宽压力越显著；超32字节、需修改字段、高频读写等场景应改用指针。
值类型赋值时到底发生了什么
Go 中所有值类型（int、struct、[3]int 等）在赋值、传参、返回时都会发生**完整内存拷贝**，不是引用传递。这个行为本身没有“对错”，但一旦结构体变大或高频调用，拷贝开销会直接体现为 CPU 和内存带宽压力。
比如一个含 100 个 float64 字段的结构体，每次传参就拷贝 800 字节；若该函数每毫秒调用百次，仅这一处就产生 80MB/s 的无效内存复制。
- 基础类型（
int、bool）拷贝开销可忽略 -
struct拷贝量 =unsafe.Sizeof(T{})，和字段排列、填充（padding）强相关 -
[N]T数组是值类型，[]T切片是引用类型（只拷贝 header，24 字节） - 嵌套结构体逐层展开拷贝，不因“看起来像指针”而跳过
什么时候该用指针替代值传递
不是所有结构体都该加 *。核心判断依据是：**拷贝成本 > 解引用成本 + 潜在副作用风险**。常见需改用指针的场景：
- 结构体大小超过 32 字节（经验阈值，x86_64 下约 4 个寄存器宽度）
- 方法需要修改接收者字段（否则只能靠返回新结构体，更贵）
- 作为 map value 或 channel 元素频繁读写（避免每次取值都拷贝）
- 结构体含大数组字段（如
[1024]byte），即使总 size 小，局部拷贝仍重
反例：type Point struct{ X, Y int } 完全没必要传 *Point —— 拷贝 16 字节比解引用+缓存未命中更轻量。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
如何精准测量拷贝开销
别猜，用 go test -bench 对比。关键点：确保编译器没优化掉无用拷贝（加入副作用，如打印或累加字段）。
func BenchmarkStructCopy(b *testing.B) {
s := BigStruct{ /* ... */ }
b.ReportAllocs()
for i := 0; i < b.N; i++ {
_ = s // 强制拷贝
blackhole(s) // 防止被优化
}
}
<p>func BenchmarkStructPtrCopy(b <em>testing.B) {
s := &BigStruct{ /</em> ... <em>/ }
b.ReportAllocs()
for i := 0; i < b.N; i++ {
_ = </em>s // 解引用 + 拷贝（仍存在，但通常更小）
blackhole(*s)
}
}</p><p>func blackhole(v interface{}) {} // 防内联/优化</p>关注 Benchmark 输出的 ns/op 和 B/op。若指针版本 ns/op 显著下降且 B/op 不增，说明拷贝是瓶颈。
容易被忽略的隐式拷贝点
很多拷贝发生在看似“安全”的地方，开发者常无感：
- 从
map[string]MyStruct中取值：v := m["key"]→ 拷贝整个结构体 - range 遍历结构体切片：
for _, s := range slice→ 每次迭代拷贝一个元素 - 接口赋值：若
MyStruct实现了某接口，var i Interface = s会拷贝结构体到接口底层数据区 - 闭包捕获大结构体变量：哪怕只读，也会复制一份进闭包环境
这些地方改用指针或切片索引访问（slice[i]）能立竿见影。但注意：指针带来逃逸分析变化，可能使原本栈分配的对象升为堆分配 —— 用 go build -gcflags="-m" 确认。
