panic 由切片越界引发，主因是空切片执行 path[:len(path)-1] 导致索引 -1 非法；需在截取前校验 len(path) > 0，尤其递归回溯场景。
panic 信息里没提“扩容”，但实际是 append 触发的越界
Go 中 append 本身不会 panic，但它的返回值可能被后续操作误用。常见路径是：调用 append(path, node) 后，原地修改了 path（比如 path = path[:len(path)-1]），而没检查 len(path) 是否为 0。这时 path[:len(path)-1] 变成 path[:-1]，索引 -1 非法，直接触发 panic: slice bounds out of range。错误堆栈指向回溯行，不是 append 行——这是最易误判的点。
关键判断依据是 panic 第一行：panic: runtime error: slice bounds out of range [x] with length y 或更常见的是 slice bounds out of range（无具体索引）。只要看到这个，先别翻 append 调用处，直接搜 [:、:len(、[:cap( 这类切片截取操作。
哪些切片操作在扩容后特别危险
扩容本身安全，危险来自扩容后对原变量的“假设性操作”。以下写法在递归或循环中极易出事：
-
path = path[:len(path)-1]—— 必须前置if len(path) > 0校验，空切片时len(path)-1 == -1，Go 不支持负索引 -
last := path[len(path)-1]—— 同样需if len(path) > 0，否则访问path[-1] -
copy(dst, src)时 dst 容量不足但没校验 ——copy不 panic，但会静默截断；真正 panic 往往出现在后续用到被截断的 dst 的地方 - 把
append结果赋给另一个变量后，还继续用旧变量做切片操作 —— 旧变量可能已因底层数组搬迁失效（虽不 panic，但逻辑错）
如何快速确认是不是扩容引发的状态错乱
扩容不直接 panic，但它会改变底层数组指针，进而让其他持有旧切片头的变量行为异常。排查时盯住三点：
立即学习“go语言免费学习笔记（深入）”；
- 所有涉及
append的地方，检查是否紧接着用了path[i]或path[:n]，且没校验len(path) - 多个函数共用同一切片变量（如递归参数），确认每次修改前都做了长度防御，尤其回溯场景
- 用
fmt.Printf("len=%d cap=%d ptr=%p\n", len(s), cap(s), &s[0])打印关键点的切片元信息 —— 如果某次append后ptr变了，而后续操作仍基于旧ptr假设，就可能越界
注意：append 返回新切片，原变量不变；如果你写 s = append(s, x)，那之后所有对 s 的操作都基于新切片，没问题；但如果你漏掉赋值（如只写 append(s, x) 丢弃返回值），再操作 s，就完全和扩容无关。
最容易被忽略的边界：空切片的 “-1” 操作
这是递归回溯代码里最高频的 panic 根源。例如 DFS 路径收集：
func dfs(node *Node, path []int) {
path = append(path, node.Val)
if node.Left == nil && node.Right == nil {
result = append(result, append([]int(nil), path...))
return
}
if node.Left != nil {
dfs(node.Left, path)
}
if node.Right != nil {
dfs(node.Right, path)
}
path = path[:len(path)-1] // ⚠️ 这里没判空！
}
当 path 初始为 []int{}，第一次 append 后长度为 1，进入子节点后再次 append，再回溯……但某次递归退出时，path 可能刚被清空（比如左右子都 nil，进一次 return 后立刻执行这行），此时 len(path) 是 0，len(path)-1 就是 -1。
修复只有一行：if len(path) > 0 { path = path[:len(path)-1] }。别信“我肯定不会传空切片进来”，递归入口参数可控，但中间状态不可控。
