高频函数调用中，参数拷贝和局部变量逃逸是主要性能拖累；小结构体（≤48字节）传值更快，含切片/map或超64字节应传指针；接口参数有开销，优先用泛型；逃逸需以go build -gcflags="-m -l"验证。
高频函数调用中，参数拷贝和局部变量逃逸是两个最常被低估的性能拖累点——它们不报错、不 crash，但会让吞吐掉 15–30%，GC 压力悄然升高。
什么时候该传指针而不是值？
不是“大就传指针”，而是看拷贝成本是否超过解引用开销。Go 编译器对小结构体（≤48 字节）做寄存器优化，传值反而更快；而一旦结构体含 []byte、map 或字段总大小超 64 字节，值传递就会触发整块内存复制。
-
type User struct { ID int; Name string; Tags []string }：即使Name和Tags是引用类型，结构体头（16–24 字节）+ 切片头（24 字节）+ map header（24 字节）叠加后极易突破阈值，应传*User - 方法接收者同理：
func (u User) Save()每次调用都拷贝u；改用func (u *User) Save()只传地址 - 注意陷阱：传
*User本身不逃逸，但若函数内又对局部变量取地址并返回（如return &u.Name），那个局部字段仍会逃逸
为什么 io.Reader 参数比 *bytes.Buffer 慢？
接口参数本质是 iface 结构体（2 个指针字段），传参时需复制整个 iface，且动态类型检查带来额外开销。实测在 HTTP 中间件或 JSON 解析循环中，比直接传具体类型慢 15–30%。
- 仅当需要多态时才用接口：比如插件系统支持
io.Reader、io.StringReader、*bytes.Buffer多种输入源 - 否则优先用泛型约束：
func decode[T ~[]byte | ~string](data T)，编译期单态化，零运行时开销 -
error是特例：因errors.New返回静态不可寻址值，日常使用无需规避接口
如何确认变量是否逃逸到堆？
别猜，用编译器输出说话。执行 go build -gcflags="-m -l"（加 -l 禁用内联，否则逃逸信息混在调用方里）：
Go语言（Golang）1.26.0
下载
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
- 看到
&x escapes to heap：说明你对局部变量取了地址且该地址可能被外部持有 - 看到
leaking param: y：参数y被赋给了全局变量、闭包或返回值，生命周期超出当前函数 - 看到
make([]T, 0, N) moved to heap：切片底层数组逃逸了，常见于append后返回 slice
典型误操作：fmt.Sprintf("%v", bigStruct)、map[string]interface{}{} 循环构造、方法内 return &localField —— 这些都会把本可栈分配的对象推上堆。
小结构体传值，大结构体传指针，但别忘了防误改
传指针省拷贝，但代价是可能意外修改原数据。尤其在并发场景下，*User 被多个 goroutine 共享时，字段修改需加锁或转为不可变设计。
- 若函数只读大结构体，且调用方能确保生命周期安全，用指针没问题
- 若函数要修改其中部分字段，考虑拆出独立小结构体传值（如
func updateName(u *User, name string)→func updateName(name *string)） - 更彻底的解法：用
sync.Pool复用大对象，但注意池中对象不能含未清空的map或slice，否则污染后续使用
真正难的不是知道该传指针还是值，而是判断“这个变量到底会不会被外部持有”——逃逸分析的结论永远依赖上下文，同一行代码在不同调用链中可能逃逸也可能不逃逸。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
