Go切片扩容在len=1024时由翻倍转为25%增长（newcap=cap+cap/4，向上对齐），该策略自1.18稳定；共享底层数组的slice扩容可能使其他slice失联，需用make预设容量或append(nil,s...)隔离。
小切片扩容走的是“原地 double”策略
Go 运行时对 len(s) 的 slice，扩容时默认新容量设为 2 * cap(s)，只要底层数组后续还有足够空闲空间，就直接复用——不分配新底层数组，也不拷贝数据。这是典型的“原地 double”行为。
这种策略快，但有个关键前提：底层数组得够长。比如你从一个长度为 5、容量为 10 的 slice 开始追加，前几次扩容都可能落在同一块内存里；但一旦 cap 达到 1024，策略就变了。
- 触发条件是
len(s) ，不是cap(s) - 即使
cap(s) == 1000，只要len(s) == 900，下一次append仍可能 double 到 2000——前提是底层数组总长度 ≥ 2000 - 如果底层数组只剩 50 个可用元素，哪怕
len(s) == 10，也会立刻分配新底层数组
大切片扩容改用“渐进式增长”算法
当 len(s) >= 1024 时，Go 不再简单翻倍，而是按公式 newcap = cap(s) + cap(s)/4 计算（即每次增加 25%），并向上取整到内存对齐边界（通常是 8 字节倍数）。这能避免大内存块被频繁重分配，降低碎片和 GC 压力。
注意：这个阈值是 len，不是 cap。所以一个 cap=2000 但 len=500 的 slice，依然走小切片逻辑；而一个 len=1024、cap=1024 的 slice，下次扩容就切换算法。
- 实际增长量可能略大于 25%，因为要满足内存对齐（例如
cap=1024→newcap=1280） - 该策略从 Go 1.18 起稳定，之前版本略有差异，但 1024 阈值一致
- 如果你手动调用
make([]T, 0, N)预设大容量，就能跳过多次小步扩容，直接进入“大”模式
底层数组共享导致的意外截断问题
扩容是否新建底层数组，直接影响原有 slice 是否还能访问旧数据。尤其当多个 slice 共享同一底层数组时，某个 slice 的扩容可能“悄悄”把其他 slice 的数据覆盖掉——这不是 bug，是预期行为，但极易误判。
典型现象：s1 := make([]int, 3, 5); s2 := s1[1:]; append(s1, 1, 2, 3, 4) 后，s2 可能突然变短或内容错乱，因为 s1 扩容触发了新底层数组分配，而 s2 还指向旧地址。
- 只要任意一个共享底层数组的 slice 发生扩容且触发新分配，其他 slice 就与它“失联”
-
append是唯一可能触发扩容的操作；copy、slice[i:j]都不会 - 用
reflect.ValueOf(s).Pointer()可以临时检查底层数组地址是否变化，适合调试
如何预估扩容开销并主动控制
不能只看 len 和 cap，得结合使用场景判断是否需要干预。比如日志缓冲区、网络包拼接这类写入频率高、长度波动大的场景，盲目依赖自动扩容容易引发抖动。
更稳妥的做法是：用 make([]T, 0, hint) 显式指定容量，并让 hint 略大于预期最大长度。这样既避免小步扩容的多次拷贝，又防止大切片算法在临界点附近反复触发 25% 增长。
- 如果预期最终长度在 800 左右，设
cap=1024比cap=800更好——卡在阈值下，享受 double 策略 - 如果预期超 2000，直接设
cap=2048或更高，跳过大阈值初期的多次小增长 - 用
runtime.ReadMemStats对比不同hint下的Mallocs和HeapAlloc，比纯理论推演更可靠
真正难处理的不是扩容规则本身，而是多个 slice 共享底层数组时，谁先扩容、谁后扩容、扩容是否触发新分配——这些细节在并发写入或闭包捕获中极难追踪。建议对关键路径的 slice 做显式隔离，比如用 append([]T(nil), s...) 强制深拷贝，别依赖“应该不会扩容”这种假设。
