make([]byte, 0, n) 更省内存，因其只分配底层数组不初始化元素，避免冗余零值填充和提前gc扫描，适合动态字节流构建；预估容量需适度，过大会浪费内存。
为什么 make([]byte, 0, n) 比 make([]byte, n) 更省内存
直接分配长度为 n 的切片会立即填充 n 个零值，不仅占用堆内存，还可能触发 GC 扫描；而预设容量不设长度，底层数组虽已分配，但 len 为 0，后续 append 只在需要时写入真实数据，避免冗余初始化和提前驻留。
- 适用于：构建动态字节流（如序列化、拼接日志）、读取不定长响应体
- 注意：
append超过容量会 realloc，所以预估要略宽松，但别过度（比如预估 1KB 却给 1MB） - 对比实测：处理平均 2KB 的 JSON 字段时，
make([]byte, 0, 2048)比make([]byte, 2048)减少约 30% 的堆分配次数
用 sync.Pool 复用临时对象时，哪些类型值得池化
不是所有对象都适合放进 sync.Pool —— 池化收益取决于对象大小、生命周期、复用频次。小对象（如 int、string）池化反而增加调度开销；大结构体或频繁创建销毁的中间载体（如 HTTP header map、JSON 解析 buffer、自定义 struct）才真正受益。
- 推荐池化：含指针字段的 struct（避免 GC 追踪压力）、
[]byte（尤其 > 1KB）、bytes.Buffer - 必须重置：从
Pool.Get()拿出的对象，使用前务必清空状态（例如buf.Reset()或手动置零字段），否则可能携带脏数据 - 风险点：Pool 中对象可能被 GC 回收，不能依赖其长期存在；也不适合存放含 finalizer 或需显式关闭的资源
strings.Builder 为什么比 fmt.Sprintf 和 + 拼接更省内存
fmt.Sprintf 每次调用都新建 strings.Builder 内部 buffer 并做一次完整格式解析；+ 拼接字符串在编译期优化有限，运行时会产生多个中间字符串对象；而 strings.Builder 显式管理底层 []byte，支持预设容量、追加不拷贝、最终只一次转换为 string。
- 典型场景：构造 SQL 查询、生成 HTML 片段、组装 API 响应体
- 关键用法：
var b strings.Builder; b.Grow(512)预分配，避免多次扩容；b.WriteString(s)替代+= s - 注意：
Builder.String()返回后，Builder不自动清空，重复使用前建议b.Reset()
逃逸分析提示：什么时候该看 go build -gcflags="-m"
编译器自动决定变量分配在栈还是堆，但有时它“保守”地让本可栈分配的变量逃逸到堆 —— 尤其涉及闭包、接口赋值、切片/映射操作、返回局部变量指针等情况。这类逃逸会放大 GC 压力，是内存优化的第一排查入口。
立即学习“go语言免费学习笔记（深入）”；
- 常用命令：
go build -gcflags="-m -m main.go（双-m显示更详细原因） - 典型逃逸信号：
... escapes to heap、moved to heap、allocates - 常见修复：避免将局部 slice 地址传给函数；减少 interface{} 参数（改用具体类型）；把大 struct 作为值传递而非指针（如果不会被修改）
sync.Pool 对象的 reset 逻辑，以及误以为预分配容量就等于“一定不逃逸”——后者仍需结合逃逸分析确认。 
