make([]int, 0, n) 比 make([]int, n) 更省内存，因其预分配底层数组但长度为0，append在容量内增长不触发扩容；而后者立即分配n个元素，易造成冗余内存与GC压力。
Go 里大部分内存分配问题，不是你写得不够“优雅”，而是没意识到 make、append 和逃逸分析在暗中联手给你加堆分配。
为什么 make([]int, 0, n) 比 make([]int, n) 更省内存？
关键不在“长度”或“容量”本身，而在后续是否触发扩容。用 make([]int, n) 会立刻分配 n 个元素的底层数组；而 make([]int, 0, n) 只预分配底层数组，长度为 0，后续 append 在容量内增长时完全不重新分配。
- 适用场景：你知道最终元素数量（比如解析固定大小的 JSON 数组、批量读取文件行数已知）
- 错误现象：用
make([]int, 0)然后反复append上千次 → 多次底层数组复制，GC 压力明显上升 - 注意：
append超出容量后仍会扩容，且 Go 的扩容策略（小于 1024 时翻倍，之后按 1.25 倍增长）会导致实际分配比预期多
sync.Pool 真的能帮你省内存？什么时候反而更糟？
sync.Pool 不是缓存，它是“临时对象回收站”——只对生命周期短、创建开销大、且能安全复用的对象有效。乱塞东西进去，反而增加 GC 扫描负担和 goroutine 局部性干扰。
- 适合：频繁创建销毁的
[]byte缓冲区、自定义结构体（不含指针或指针可安全重置） - 危险操作：往
sync.Pool放含未清空字段的 struct、放带 finalizer 的对象、或在 HTTP handler 中直接Get()后不Put() - 性能影响：Pool 对象在 GC 时被批量清理，如果 Put 频率远高于 Get，池子会膨胀；反之，如果 Get 总是 miss，等于白加一层间接调用
字符串转字节切片时，[]byte(s) 和 unsafe.String + unsafe.Slice 的区别在哪？
[]byte(s) 每次都分配新底层数组并拷贝内容，是安全但昂贵的操作；而基于 unsafe 的转换只是重解释内存头，零分配——但前提是字符串内容不会被修改，且你确保底层数据生命周期可控。
立即学习“go语言免费学习笔记（深入）”；
- 必须用拷贝的场景：你要把结果传给会修改底层数组的函数（比如
bytes.ToUpper），或该[]byte生命周期超出原字符串 - 可用 unsafe 的场景：仅作只读解析（如 HTTP header 解析、协议二进制字段提取），且字符串来自常量、
io.ReadFull读到的稳定缓冲区等 - 兼容性风险：Go 1.20+ 才有
unsafe.String和unsafe.Slice；老版本需手写reflect.StringHeader/reflect.SliceHeader，但 Go 1.21 起禁止写这些 header 字段
最常被忽略的一点：逃逸分析报告（go build -gcflags="-m -l"）里显示 “moved to heap” 的变量，往往不是因为用了指针，而是闭包捕获、接口赋值、或者返回局部变量地址——这些地方改起来比换一个 make 参数隐蔽得多。
