strings.Builder扩容公式为cap×2+needed而非简单翻倍，初始cap为0，首次WriteString("a")后cap变为8，Grow(n)仅预留空间不分配n字节，Reset()不清空底层数组易致内存驻留。
strings.Builder扩容不是cap×2，而是cap×2+needed
很多人看到底层是[]byte就默认它和slice一样走「翻倍」策略，实际扩容公式是cap × 2 + needed，其中needed是本次WriteString或Write的字节数，不是固定值。
- 初始
cap为0，第一次WriteString("a")后cap变成8（硬编码在src/strings/builder.go） - 接着写入100字节，当前
cap == 8，不够，就按8×2+100 = 116分配新底层数组，不是16 - 如果提前
Grow(1024)，后续写入≤1024 - b.Len()字节就不会再扩容 - 实测时直接打印
b.Cap()比查文档更可靠——别信“翻倍”说法，看真实cap变化
Grow(n)不分配n字节，只确保剩余空间≥n
Grow(n)的作用是「预留」，不是「分配」。它检查的是b.Cap() - b.Len() >= n，不满足才触发扩容；满足就什么也不做。
-
b.Grow(1024)后只写入1字节，b.Cap()仍是1024——这没问题，但别以为还能再安全写1024字节 - 实际可用空间是
b.Cap() - b.Len()，不是n - 在循环里反复调用
b.Grow(1024)没意义：容量不会重置，也不会叠加 - 多次调用小值无副作用，但无意义；真正起作用的是最大一次调用
Reset()不清空底层数组，易致内存驻留
Reset()只清b.Len()，不释放b.buf底层数组。复用大容量实例拼很小字符串时，底层数组滞留，浪费内存、拖慢GC。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 长生命周期对象中反复
Reset()会导致内存驻留——尤其在HTTP handler或对象池中 - 拼接总长可控的小字符串（如生成固定结构JSON）时，
strings.Builder内存更紧凑；但若拼接模式极不规则（每次写入长度从1B到1MB波动），扩容次数可能略高于预设大cap的bytes.Buffer - 别在
defer里用Builder拼接日志——defer执行晚，实例生命周期被拉长，底层数组无法及时释放 -
String()返回的是只读字符串视图，调用后继续Write会强制重新分配内存（因为内部addr被设为nil）
Cap()和Len()的差值才是关键判断依据
b.Len()是已写入字节数（即最终字符串长度），b.Cap()是底层数组总容量。两者之差才是当前剩余空间。扩容是否发生，只取决于Cap() - Len()。
立即学习“go语言免费学习笔记（深入）”；
-
Cap()包含已写入内容占用的空间，不是“还能写多少” - 不能用
b.Cap() == 0判断是否为空——应该用b.Len() == 0 - 预估总长时，推荐设为预估长度的1.2–1.5倍，而非拍脑袋填1024
- 完全确定长度（如固定模板填充）时，
b.Grow(len(template) + len(data))最稳
实际写代码时，最容易被忽略的是：每次String()之后再Write，或者把Reset()和旧String()结果混用——这两处看似安全，却会让Builder退化成和+=差不多的性能。
