append在for循环中触发扩容会导致底层数组地址变化，进而使已取的&s[i]指针失效，引发读旧值、panic等错误；应预分配容量、避免提前存地址、禁止并发append同一slice。
append 在 for 循环中触发扩容，底层数组地址会变
只要 append 导致当前 len(s) == cap(s)，就会分配新底层数组、拷贝数据、更新指针。这意味着循环中每次扩容后，&s[0] 地址大概率变化——哪怕只加一个元素。
常见错误现象：s[i] 在循环前取了地址或传给其他函数，但后续 append 触发扩容，原地址失效，导致读到旧值、空值或 panic。
- 用
fmt.Printf("data=%p\n", &s[0])在每次append后打印，能直观看到地址跳变 - 若循环中多次
append且未预分配，可能在第 3、4、8、16… 次迭代时突然扩容（取决于初始cap） - 即使
s是函数参数，只要在循环内append并重新赋值（s = append(s, x)），就等价于创建新切片
预分配容量不能完全避免循环中地址变化
make([]T, 0, N) 能消除「预期范围内」的扩容，但 runtime 不保证绝对不额外分配——尤其当 N 接近内存页边界，或底层 mallocgc 做了对齐调整时，实际分配的底层数组长度可能略大于 N，而后续 append 仍可能因对齐策略触发一次扩容。
性能影响明显：一次 KB 级扩容可能引发数万次元素拷贝，放在 hot loop 里就是毛刺来源。
- 启动程序加
-gcflags="-m"，看是否出现... escapes to heap，间接反映逃逸压力增大 - 用
runtime.ReadMemStats对比前后Alloc和TotalAlloc，确认是否发生非预期分配 - 若循环次数固定且已知，直接
make([]T, N, N)（长度=容量），比make([]T, 0, N)更稳——避免len从 0 增长时的首次小容量倍增
循环内引用 slice 元素时，别依赖 &s[i] 的长期有效性
Go 中切片是值类型，s = append(s, x) 返回的是新切片头（含新 array 指针）。即使没扩容，s 变量本身也被重新赋值，旧切片头即失效；一旦扩容，&s[i] 所指内存位置彻底作废。
典型踩坑场景：把 &s[i] 存入 map、传给 goroutine、或作为回调闭包变量，在后续迭代中访问——此时它可能指向已释放内存或错误偏移。
- 安全做法：在确定不再追加后，再取地址；或用索引
i+ 切片本身做延迟计算，而非提前存指针 - 若必须传地址，改用
unsafe.Slice(&s[0], len(s))（Go 1.21+）配合显式生命周期控制，但需自行确保不越界 - 对 map value 或 channel 发送，优先传
s[i]值拷贝，而非&s[i]指针——除非明确需要修改原 slice 内容且能保证无扩容
多个 goroutine 并发 append 同一个 slice 是未定义行为
即便你用 sync.Mutex 锁住整个循环体，只要锁粒度不够细（比如只锁 append 动作，没锁住后续对 s[i] 的读写），仍可能因扩容导致部分 goroutine 看到旧底层数组、部分看到新数组，进而引发数据竞争或 panic。
根本原因：扩容后原底层数组可能被 GC 回收，而某个 goroutine 还在通过旧指针访问它。
- 正确做法：每个 goroutine 使用独立
make([]T, 0, N)预分配的 slice，最后用append(dst, src...)合并 - 若必须共享，改用
chan []T或sync.Pool复用切片，避免跨 goroutine 直接操作同一变量 - 用
go run -race能捕获大部分此类问题，但无法覆盖 GC 后访问的极端情况
