make([]byte, 0, n) 更省内存，因只预分配容量不初始化，避免冗余零值填充；而 make([]byte, n) 立即分配并初始化 n 字节，易造成双倍内存开销。
为什么 make([]byte, 0, n) 比 make([]byte, n) 更省内存
因为后者会立即分配并初始化 n 个字节（全零），而前者只预分配底层数组容量，不触发初始化，实际写入前不占真实堆内存。尤其在频繁构造临时缓冲（如 HTTP body、JSON 序列化）时，差异明显。
- 典型场景：读取文件后做字符串处理，用
make([]byte, 0, stat.Size())配合io.ReadFull或bytes.Buffer.Grow - 错误做法：直接
make([]byte, stat.Size())再os.ReadFile—— 等于分配两份内存 - 注意：
cap()足够但len()为 0 的切片，在append时仍可能触发一次扩容（如果初始cap不足）
sync.Pool 什么时候真能减内存，什么时候反而增负担
sync.Pool 只对「生命周期短、创建开销大、结构稳定」的对象有效，比如 *bytes.Buffer、*json.Decoder。它不解决泄漏，也不适合持有含指针或外部资源的值。
- 有效用法：HTTP handler 中复用
bytes.Buffer，用完调pool.Put(buf)，入口处buf := pool.Get().(*bytes.Buffer)并buf.Reset() - 危险信号：池中对象包含
io.Reader、net.Conn或未清空的 map/slice —— 可能导致 goroutine 泄漏或数据污染 - 性能陷阱：如果
Get()命中率长期低于 30%，说明对象复用不充分，Pool 反而增加 GC 扫描压力
pprof 发现 runtime.mallocgc 占比高，下一步该看什么
别急着改代码，先确认是不是逃逸分析没过 —— 大量本该栈分配的对象被抬到堆上。用 go build -gcflags="-m -m" 看关键函数的逃逸报告。
- 高频逃逸源：闭包捕获局部变量、返回局部 slice 指针、interface{} 包装非接口类型（如
fmt.Sprintf("%v", x)中的x是 struct） - 验证方式：把疑似逃逸的变量改成传参（而非返回）、用具体类型替代
interface{}、拆分大 struct 为小字段传值 - 注意：CGO 调用、反射、
unsafe.Pointer会强制逃逸，这类地方只能接受，别硬优化
map 和 string 的隐式内存放大问题
Go 的 map 底层哈希表不会自动缩容，即使删掉 90% 的 key，内存也不会还给系统；string 的底层数据和原 []byte 共享底层数组，可能导致长生命周期 string 拖住整个大 buffer。
立即学习“go语言免费学习笔记（深入）”；
- map 缩容方案：没有内置方法，必须重建 ——
newMap := make(map[K]V, len(oldMap))，再遍历复制 - string 截断风险：从大文件中
string(buf[100:200])，会导致整个buf无法回收；应改用string(append([]byte(nil), buf[100:200]...)) - 检查手段：用
pprof的top alloc_space看哪些 map 实例长期驻留，结合runtime.ReadMemStats观察HeapInuse与HeapAlloc差值
真正难的不是知道这些技巧，而是每次重构后得重新跑 pprof 看 heap profile —— 同一个改动，在不同负载下可能效果相反。
