append(slice, otherslice)编译失败是因为append函数要求第二参数为零个或多个t类型值，而非[]t；正确写法是slice = append(slice, otherslice...)。
append 返回新切片，不赋值就等于没操作；slice 不是数组，扩容逻辑藏在 cap 里；合并两个切片必须用 ... 展开。
为什么 append(slice, otherSlice) 编译失败？
因为 append 的签名是 func append(slice []T, elems ...T) []T —— 第二个及之后的参数必须是零个或多个 T 类型值，不是另一个 []T。直接传 otherSlice 类型不匹配。
- 正确写法：
slice = append(slice, otherSlice...)（注意...） - 错误写法：
append(slice, otherSlice)→ 编译报错：cannot use otherSlice (type []int) as type int in argument to append - 如果漏掉
...，Go 不会自动解包，也不会隐式转换，这是明确的设计约束
扩容时容量翻倍？不一定，但行为可预测
append 触发扩容时，新容量不是固定翻倍，而是按当前 cap 分段计算：小于 1024 时通常翻倍；≥1024 时按 1.25 倍增长（源码中为 cap += cap / 4）。关键是你不能依赖具体倍数，但可以观察到：容量增长是单调递增、无回退的。
- 初始
make([]int, 0, 4)→cap=4，追加第 5 个元素时扩容，新cap通常是 8 - 若从
[10]int切出s := arr[0:5]，则cap(s) == 10，追加到第 6 个元素才扩容 - 频繁小量追加（如循环中每次
append(s, x)）会导致多次分配，性能下降明显
共享底层数组导致的“静默污染”
多个切片可能指向同一底层数组，append 后若未触发扩容，修改仍会影响原数组或其他切片 —— 这不是 bug，是设计使然，但极易被忽略。
- 示例：
arr := [5]int{1,2,3,4,5}; s1 := arr[:3]; s2 := arr[2:]; s1 = append(s1, 99)→arr[2]变成 99，s2[0]也变成 99 - 判断是否安全：检查
len(s) ，成立才说明还有余量，<code>append可能复用底层数组 - 想彻底隔离？用
copy创建新底层数组：newS := make([]int, len(s)); copy(newS, s)
预估容量能省掉多少次内存分配？
如果你知道最终长度，make([]T, 0, expectedLen) 初始化比默认 []T{} 少 90% 以上分配次数。比如要收集 1000 条日志，用 make([]string, 0, 1000)，基本一次分配搞定；用空切片起步，大概率经历 10+ 次 realloc + copy。
- 实测差异：1000 元素下，预分配耗时约 3μs，动态增长约 45μs（含复制开销）
- 但别过度优化：如果预期长度误差 >2×，预分配反而浪费空间；
cap只是上限，不会影响len或遍历 - 真正该警惕的，是把
cap当作“可用空间”误用 —— 它只是底层数组剩余长度，不是你能随意写的缓冲区
... 或调 make，而是理解：每个 slice 都是带指针的三元组，而 append 是一个有副作用的纯函数 —— 它返回新切片，但旧切片变量不变，且底层可能复用也可能换掉。所有“意外行为”，几乎都来自对这三点的忽视。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
