初始化切片应根据场景选择：nil切片（var s []int）安全但需注意==nil判断；空切片（[]int{}）非nil；预知大小时用make([]int, 0, N)避免多次扩容。
怎么初始化切片才不踩空指针或扩容坑
Go里nil切片和空切片行为不同，直接append一个nil切片是安全的（会自动分配底层数组），但用len()/cap()判断是否为空时，nil和[]int{}结果一致，而用== nil比较时只有前者为真——这在接口传参、JSON序列化或条件分支里容易出错。
-
var s []int→nil切片，len(s) == 0且cap(s) == 0，但s == nil为true -
s := []int{}→ 非nil空切片，len/cap都是0，但s == nil为false - 预知大小时优先用
make([]int, 0, N)：避免append过程中多次扩容（比如N=1000，一次分配完，而不是从2→4→8…翻倍到1024）
为什么append后原切片有时“变”了，有时又没变
关键看底层数组有没有被重新分配。当append导致容量不足时，Go会申请新数组、复制旧数据、返回指向新数组的切片——这时原变量（如果没重新赋值）仍指向旧底层数组；但如果原切片是某个数组的子视图，而append恰好复用了剩余容量，就可能意外改写原数组其他部分。
- 示例：
arr := [3]int{1,2,3}; s := arr[:2]; s = append(s, 99)→arr变成[1 2 99]（因为cap(s) == 3，足够容纳） - 同上但
s := arr[:1]，再append(s, 99, 100)→ 底层换新数组，arr不变 - 函数内
append不会影响调用方的切片变量（因为切片本身是值传递），但会影响它指向的底层数组（引用传递）
截取切片s[i:j:k]三个参数到底在控制什么
两参数s[i:j]只设长度，容量默认为cap(s) - i；三参数s[i:j:k]显式限制容量上限为k - i，这是防止子切片无意中“撑爆”父切片剩余空间的安全机制。
-
original := []int{0,1,2,3,4,5}; s := original[2:4]→len=2,cap=4（从索引2到末尾共4个元素） -
s2 := original[2:4:4]→len=2,cap=2（上限卡死在索引4，所以容量=4−2=2） - 后续对
s2做append，一旦超2就会强制分配新底层数组，彻底隔离修改风险
删除元素别手写循环，用append拼接最稳
Go没有内置delete切片元素的函数，常见错误是遍历中用append覆盖自身，或手动移动元素导致越界/漏删。正确做法是把“删掉的位置”前后两段用append拼起来，语义清晰、边界安全。
- 删索引
i处元素：s = append(s[:i], s[i+1:]...) - 删多个连续索引（如i到j）：
s = append(s[:i], s[j:]...) - 注意
...必须写，否则append会把整个s[i+1:]当单个参数（类型不匹配报错） - 如果要删的是最后一个元素，
s = s[:len(s)-1]比append更轻量
切片真正难的不是语法，而是时刻意识到它背后那个共享的、可能被多处修改的底层数组——哪怕你只写了s[0] = 1，也得想清楚这一行会不会悄悄改掉别人正在用的数据。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
