append不赋值就等于没追加，因go中切片是值传递，append返回新header（ptr、len、cap），原变量不变；必须s=append(s,x)才生效，扩容仅在len==cap时触发，策略为分段+内存对齐，未扩容时默认共享底层数组。
append 不赋值就等于没追加，扩容策略不是翻倍而是分段+对齐，共享底层数组是默认行为而非 bug。
append 后原切片变量没变？这是值传递不是 bug
Go 的 append 返回一个新切片（新 header），原变量不会自动更新。它只是把 ptr、len、cap 三个字段打包返回，调用方必须显式接收：
- 错误写法：
append(s, x)—— 编译器会警告 “result of append not used”，s长度和内容都不变 - 正确写法：
s = append(s, x)或s = append(s, 1, 2, 3) - 函数内修改也要返回：
func add(s []int, x int) []int { return append(s, x) }，调用方必须接住返回值 - 传参时也是 header 副本：函数里
append不影响调用方的s，但s[i] = y会影响，因为 ptr 指向同一底层数组
扩容触发条件很明确，但新 cap 不能靠猜
扩容只在 len(s) == cap(s) 时发生，此时 runtime 按规则分配新底层数组并拷贝数据。新容量计算分段且带内存对齐：
cap ：新 <code>cap = cap * 2（如 512 → 1024）-
cap ≥ 1024：新cap = cap + cap/4，再向上对齐到 8 字节边界（如 2048 → 2560，3000 → 3760） - 一次追加多个元素时，runtime 先估算最小需容量，再套策略，可能跳档（如
cap=2追加 3 个元素，直接扩到 4） - 不要依赖扩容后
cap精确等于某值——Go 只保证“足够大”，具体值是实现细节
未扩容时共享底层数组，隐式修改很危险
只要没扩容，append 返回的新切片和原切片共用同一底层数组。这提升性能，但也导致数据互相污染：
- 典型错误：
s1 := []int{1,2}; s2 := append(s1, 3); s2[0] = 99→fmt.Println(s1)输出[99 2] - 存进 map 后再
append更危险：map value 是 header 副本，若未扩容，仍指向原数组，后续修改污染其他 key - 调试技巧：用
fmt.Printf("%p", &s[0])打印首元素地址，两次调用间变了说明底层数组已迁移 - 需要隔离时，别用
s[:0]（仍复用原底层数组），安全做法是newS := append([]int(nil), oldS)
nil 切片能 append，但混合使用容易逻辑错乱
var s []int 是合法的 nil 切片，append(s, x) 安全有效，但行为和已分配切片不同：
- nil 切片首次
append会自动分配底层数组（初始 cap 通常为 1） - 问题出在混合使用：函数参数允许
nil，调用方有时传make([]int, 0, 100)，有时传nil，导致底层数组生命周期不可控 - 统一做法：函数入口先标准化 ——
if s == nil { s = make([]int, 0) }，再后续append - 预分配有明确预期时，优先用
make([]int, 0, expectedCap)，避免首次分配小数组再反复扩容
真正容易被忽略的不是扩容公式，而是每次 append 前是否检查了 len(s) == cap(s)，每次截取后是否主动 copy 或 append([]T(nil), ...) 切断引用，以及每次传参前是否明确决策过“要不要隔离”。这些判断没有捷径，只能在每一步写清楚。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
