预分配容量是提升slice性能最直接有效的方式，90%以上性能问题源于未设cap；make([]T, 0, N)比[]T{}快因避免多次扩容拷贝，复用需buf[:0]重置len而非重建，截取s[i:j]为O(1)指针操作，copy为O(n)内存拷贝。
预分配容量是提升 slice 性能最直接有效的方式，90% 以上的性能问题都源于没设 cap。
为什么 make([]T, 0, N) 比 []T{} 快得多
因为 Go 的 append 在 len == cap 时必须扩容：分配新底层数组 + 全量拷贝旧数据。从空 slice 开始追加 1000 个元素，可能触发 10 次以上扩容（0→1→2→4→8→16→32→64→128→256→512→1000），每次都是 O(n) 拷贝；而 make([]int, 0, 1000) 一次分配到位，全程零拷贝。
- 错误写法：
var s []int或s := []int{}→ 初始cap = 0，第一次append就 malloc - 推荐写法：
s := make([]int, 0, 1000)→len = 0,cap = 1000，前 1000 次append安全无开销 - 若无法精确预估，按常见负载的 P95 设（如 128 或 256），比盲目用 0 更稳妥
如何安全复用 slice 避免 GC 压力
高频循环中反复 make 大 slice（如 HTTP 请求缓冲区）会显著增加 GC 压力。复用的关键不是“新建”，而是“重置长度、保留底层数组”。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 正确清空：
buf = buf[:0]—— 只改len，cap和底层数组不变 - 错误清空：
buf = []byte{}或buf = make([]byte, 0)—— 丢弃原底层数组，强制新分配 - 高并发场景可用
sync.Pool：var bufPool = sync.Pool{New: func() interface{} { return make([]byte, 0, 1024) }}，取用后s = s[:0]，用完Put - ⚠️ 注意：复用前提是你确认没有其他 goroutine 或 map 正在引用该底层数组，否则会脏读或竞争
什么时候该用 copy，什么时候该用切片截取 s[i:j]
两者成本天差地别：s[i:j] 是纯指针操作（O(1)），copy 是内存拷贝（O(n)）。选哪个，取决于你是否需要数据隔离。
立即学习“go语言免费学习笔记（深入）”；
- 直接截取（零拷贝）：
header := data[:4]→ 适合解析协议头、临时提取 token 等只读场景 - 必须拷贝（独立副本）：
dst := make([]byte, len(src)); copy(dst, src)→ 用于传给其他 goroutine、存入 map、或父 slice 即将被重用 - 危险操作：
append([]byte{}, s...)→ 每次都新建 slice 并扩容，比copy还慢，应杜绝 - 小技巧：
copy不保证全量复制，实际复制长度是min(len(dst), len(src))，务必检查目标容量
真正难的不是记住规则，而是判断“这个 slice 的生命周期和共享范围到底是什么”。很多 bug 和泄漏，都发生在你以为它只是临时视图，其实它悄悄锁住了几 MB 的底层数组。
