go性能瓶颈常是高频堆分配引发gc抖动，关键在让变量栈分配、复用内存、规避昂贵接口；用go build -gcflags="-m -m"查escapes to heap判断逃逸，如返回栈变量地址、循环取地址、接口赋值结构体字面量、闭包捕获逃逸变量均导致堆分配；预分配切片应选make([]int, 0, n)而非make([]int, n)。
Go里真正压垮性能的，往往不是算法复杂度，而是高频堆分配触发GC抖动。关键不在“少写new”，而在让编译器把变量留在栈上、复用已分配内存、绕过标准库里那些“方便但昂贵”的接口。
怎么看代码到底逃不逃逸
别靠猜，直接跑 go build -gcflags="-m -m"。重点盯日志里有没有 escapes to heap —— 出现就说明这个变量被编译器判为必须堆分配。
-
func f() *int { x := 1; return &x }：x 一定逃逸，因为返回了栈变量地址 -
for i := range s { g(&i) }：每次循环都可能新分配一个*int，i 的地址在循环中不断变化 -
var _ interface{} = struct{ x int }{}：结构体字面量赋给接口，强制堆分配（哪怕只有几个字节） - 闭包捕获局部变量且该闭包逃出函数作用域 → 那个变量必然逃逸
预分配切片比盲目 append 更省
用 make([]int, 0, n) 而不是 make([]int, n)，前者只预分配底层数组、长度为 0；后者立刻初始化 n 个零值元素，浪费内存且增加 GC 扫描负担。
- 适用场景：你知道最终元素数量（如解析固定长度 JSON 数组、批量读取已知行数的文件）
- 错误做法：
data := make([]int, 0); for i := 0; i → 至少触发 14 次扩容，每次都要拷贝旧数据 - 安全边界：append 超出容量后仍会按 Go 规则扩容（
sync.Pool 复用对象时最容易踩的坑
sync.Pool 不是缓存，它是“临时对象回收站”。Put 进去的东西随时可能被 GC 清掉，而且 Get 和 Put 不保证在同一个 goroutine。
- 必须清零：
buf := pool.Get().([]byte); buf = buf[:0]—— 只截断长度，不依赖 cap 判断是否够用 - 结构体含指针字段？Put 前手动置
nil，否则被引用的对象无法被 GC 回收 - 禁止放
http.Header或url.Values：底层是 map，并发读写不安全，Pool 也不做同步 - 别往里塞带 finalizer 的对象，或生命周期长于调用方的结构体
字符串转 []byte 到底要不要拷贝
[]byte(s) 总是分配新底层数组并拷贝内容；而 unsafe.String + unsafe.Slice（Go 1.20+）是零分配重解释，但要求你完全掌控内存生命周期。
- 必须拷贝：你要传给会修改底层数组的函数（如
bytes.ToUpper），或该[]byte生命周期超出原字符串 - 可 unsafe：仅作只读解析（如 HTTP header 提取、二进制协议字段读取），且字符串来自常量、
io.ReadFull读到的稳定缓冲区 - 老版本兼容：Go 1.21+ 禁止写
reflect.StringHeader字段，手写 unsafe 转换需格外谨慎
最常被忽略的点：逃逸分析报告里显示 moved to heap 的变量，往往不是因为你写了 new 或 make，而是某个看似无害的接口赋值或闭包捕获，悄悄把它推到了堆上。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
