值传递时内存分配量取决于结构体大小，小结构体（≤16字节）拷贝快且可能寄存器优化，大结构体（如[10000]int）每次调用拷贝完整数据；含slice/map等仅拷贝header，嵌套指针仅拷贝8字节；需指针传参的场景包括修改原字段、结构体过大（>64字节）、含不可拷贝字段、方法集要求或接口实现；但指针可能引发逃逸至堆，增加GC压力，应实测而非臆断。
值类型传参时到底分配多少内存
Go 中函数调用默认是值传递，但「值」的大小直接决定栈上拷贝开销。结构体越小（如 int、[4]byte），拷贝越快；一旦结构体字段多或含大数组（比如 [1024]int），每次调用都会在栈上复制完整数据。
关键判断点：用 unsafe.Sizeof 查看实际大小。例如：
type BigStruct struct {
Data [10000]int
ID int64
}
fmt.Println(unsafe.Sizeof(BigStruct{})) // 输出 80008 字节 → 每次传参会拷贝约 80KB
- 小结构体（≤ 16 字节）：通常比指针还快，编译器可能做寄存器优化
- 含 slice/map/chan/string 的结构体：只拷贝 header（24 或 32 字节），不拷贝底层数组，但要注意这不代表“无开销”——底层数据仍共享
- 嵌套结构体中含指针字段：拷贝的是指针值本身（8 字节），不是目标对象
什么时候必须用指针传参
不是为了“省内存”才用指针，而是语义和行为需要。以下情况不用指针会出错或低效：
- 要修改原结构体字段（如
user.SetAge(30)）→ 值传参会改副本，原对象不变 - 结构体太大（> 64 字节建议警惕），且函数高频调用 → 栈空间浪费 + 缓存不友好
- 结构体含 sync.Mutex 等不可拷贝字段 → 编译报错：
cannot assign to struct containing sync.Mutex - 方法集需要满足接口：如果只有
*T实现了某接口方法，那只有*T类型变量能赋值给该接口
指针传参的隐藏成本：逃逸分析与堆分配
你以为传 *T 就一定省内存？不一定。如果编译器判定该指针生命周期超出栈帧（比如被返回、存入全局 map、传给 goroutine），T 本体就会从栈逃逸到堆 —— 这反而增加 GC 压力和内存碎片。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
验证方式：加 -gcflags="-m -l" 编译，观察输出中是否含 ... escapes to heap。
- 常见逃逸场景：返回局部变量地址、把指针存进切片/映射、闭包捕获局部变量
- 避免无谓逃逸：若只是读取且结构体不大，值传参反而更高效（栈分配快，无 GC 负担）
- 注意
new(T)和&T{}都强制堆分配，而T{}默认栈上构造
性能敏感场景下的实操建议
别猜，先测。在真实负载下用 go tool pprof 看内存分配热点，而不是凭经验改指针。
- 对只读小结构体（如
Point{x,y int}），保持值传递；它更缓存友好，也避免逃逸 - 对写操作或大结构体，用指针；但检查是否真逃逸了——有时加
//go:noinline辅助分析更准 - 避免混合风格：一个结构体既有值方法又有指针方法，易引发混淆和意外拷贝
- 注意 interface{} 装箱：传值给
interface{}会拷贝整个值；传指针则只拷贝指针，但若值本身已逃逸，意义不大
最常被忽略的一点：结构体字段顺序影响内存对齐。把大字段（如 [64]byte）放前面，小字段（bool, int8）放后面，能显著减少 padding —— 这比纠结传值还是传指针更能压内存。
