为什么值类型传递能减轻 GC 压力
go 的垃圾回收器（GC）主要管理堆上分配的对象。只要变量逃逸到堆，就会被 GC 跟踪；而栈上分配的值类型（如 int、Struct、小数组）生命周期明确，函数返回即销毁，不进 GC 队列。
指针（尤其是指向大结构体或切片底层数组的指针）容易触发逃逸分析失败，强制分配到堆——哪怕你只是想读个字段。
哪些场景下传值比传指针更合适
不是所有结构体都适合传值，关键看「大小」和「是否真需要修改原值」。Go 编译器对 ≤ 128 字节的结构体传值通常不额外开销（寄存器/栈足够），且避免了间接寻址成本。
-
struct字段总大小 ≤ 128 字节（可用unsafe.Sizeof验证），且方法不修改接收者 → 用值接收者 - 只读访问（如配置项、DTO、数学向量）→ 优先传值，避免暴露可变引用
- 频繁创建/销毁的临时对象（如解析中间结果、迭代器状态）→ 值类型天然无 GC 污染
- 切片本身是值类型（含三个字段：
ptr、len、cap），传[]byte不等于传底层数组指针，无需刻意加*
怎么判断你的 struct 是否逃逸了
别猜，用 Go 自带工具看。逃逸分析输出里出现 ... escapes to heap 就说明编译器把它扔堆上了，不管你是传值还是传指针——但传指针会显著提高逃逸概率。
- 运行
go build -gcflags="-m -l" main.go（-l关闭内联，让逃逸更明显） - 关注形如
./main.go:12:6: &x escapes to heap或./main.go:15:10: y does not escape - 如果结构体含
Interface{}、map、chan、大数组或指针字段，大概率逃逸——这时传值也没用，得重构字段
常见踩坑：以为“小”就安全，其实字段布局在作怪
结构体大小 ≠ 字段字节数之和。内存对齐会让实际尺寸翻倍，导致意外逃逸。比如一个只有两个 int64 的 struct 理论 16 字节，但如果中间插了个 byte，可能因对齐膨胀到 32 字节，再叠加其他字段就超 128 了。
立即学习“go语言免费学习笔记（深入）”；
- 用
unsafe.Sizeof和unsafe.Offsetof检查真实布局 - 把小字段（
bool、byte）集中放在 struct 开头或结尾，减少空洞 - 避免混用大小差异大的字段：比如
int64后紧跟bool，再跟String，极易拉高对齐要求 - 嵌套指针（如
*http.Request）直接让整个 struct 逃逸，哪怕它本身只有 8 字节
真正影响 GC 的不是“用了多少指针”，而是“有多少堆对象活着”。控制逃逸比纠结语法上的 * 更治本。字段排列、接口使用、闭包捕获——这些地方不动声色就把值推到堆上，比少写几个 * 重要得多。