Go中new和&会增加GC负担，因指针字段导致结构体逃逸至堆、触发三色标记扫描；应优先值语义、合理排布字段、用-gcflags="-m -m"分析逃逸原因并验证优化效果。
为什么 new 和 & 会悄悄增加 GC 负担
Go 的 GC 是基于三色标记的并发垃圾回收器，它需要扫描所有堆上对象的指针字段。只要一个对象里有指针（哪怕只是 *int），整个对象就必须被纳入扫描范围——哪怕你只用它存个临时标志位。
常见错误现象：go tool trace 显示 GC mark 阶段耗时突增，runtime.ReadMemStats 中 NextGC 比预期小很多，但 HeapObjects 数量远超业务逻辑应有的规模。
- 结构体里只要有一个字段是指针类型（包括
string、slice、map、func），整个结构体就无法被编译器逃逸分析判定为栈分配，大概率落到堆上 -
new(T)总是分配在堆上，等价于&T{}，不看逃逸分析结果直接绕过栈优化 - 接口值（
interface{}）持有指针类型时，底层数据会被视为可扫描对象，即使原始类型本身没指针
哪些场景下该主动避免指针，改用值语义
不是所有地方都要“去指针”，关键看生命周期和复制成本。值语义更轻量，且能触发逃逸分析优化到栈上；但别为了省 GC 去复制几 MB 的结构体。
典型适用场景：小结构体（size ≤ 128B）、配置项、中间计算容器、事件参数、HTTP handler 中的请求上下文快照。
立即学习“go语言免费学习笔记（深入）”；
- 用
type Point struct{ X, Y int }而非type Point struct{ X, Y *int }—— 后者每个字段都是指针，强制堆分配 + 扫描开销翻倍 - 函数参数优先传值，如
func process(cfg Config)，而不是func process(cfg *Config)；除非Config大于 256B 或明确需修改原值 - 切片操作慎用
append返回新切片后继续传指针：若原切片已无其他引用，旧底层数组可能滞留堆中等待 GC，而新切片又带指针字段
go build -gcflags="-m -m" 看什么才有效
双 -m 是查看逃逸分析决策的最小有效方式。重点不是“有没有 escape”，而是“为什么 escape”——尤其是那些你以为能栈分配却落堆的对象。
常见误导信号：... escapes to heap 后跟着 flow: ... → ... → ... 这一串箭头才是关键路径。它暴露了哪个变量/字段/返回值把整个对象拖下了水。
- 看到
leaking param: p，说明函数参数p被返回或写入全局变量/闭包/通道，导致调用方传入的对象无法栈分配 - 出现
moved to heap: xxx且xxx是局部结构体，检查它是否嵌套了string或[]byte—— 它们虽是值类型，但底层含指针，容易引发连锁逃逸 - 如果
fmt.Sprintf或log.Printf出现在调用链中，它们接收interface{}，常导致本可栈分配的对象被迫堆化
struct 字段顺序真会影响 GC 扫描效率
Go 的内存布局按字段声明顺序排列，GC 扫描器按偏移遍历对象。如果指针字段集中在前半部分，扫描器可能提前结束；但如果它们散落在各处，扫描器就得跑完整块内存。
更实际的影响是：字段顺序影响逃逸分析结果。编译器倾向于把含指针的字段往后放，以提高前面纯数值字段的复用概率。
- 把所有指针字段（
*T、map[K]V、chan int）放在结构体末尾，数值字段（int、bool、[16]byte）放前面 - 避免在结构体中间插入
string字段，它占 16 字节但含 2 个指针；可考虑拆成data []byte+len int（仅当你完全控制使用逻辑时） - 用
unsafe.Sizeof(T{})对比不同字段顺序的结构体大小，确认没有因对齐填充意外增大
最麻烦的从来不是怎么写，而是改完之后没人验证逃逸是否真改善了。上线前务必用 go tool pprof -http=:8080 <binary> 抓一次运行时堆 profile，过滤掉 runtime.mallocgc 的调用栈，看高频分配点是不是你刚动过的结构体。
