append 删除元素易 panic 且引发内存泄漏；需校验索引、特殊处理末尾、复制底层数组保不可变性，并对指针切片显式置 nil 防 gc 漏检。
append 是最常用也最安全的删除方式，但直接写 append(s[:i], s[i+1:]) 会修改原切片、不检查边界、还可能引发 panic —— 别急着复制粘贴，先看清这几点。
用 append 删除指定索引元素时为什么 panic？
常见错误是没做索引校验就硬删：s = append(s[:i], s[i+1:])。一旦 i 超出 [0, len(s)) 范围，或 i == len(s)-1 时 s[i+1:] 变成越界访问，运行时直接崩溃。
正确做法必须前置判断：
-
i = len(s)→ 直接返回原切片或报错 -
i == len(s)-1→ 实际只需s = s[:i]，避免无效append - 若需保留原切片不可变，应先
make新底层数组再copy，而非复用原底层数组
删除指针切片（如 []*T）时为什么 GC 不回收对象？
用 append(s[:i], s[i+1:]) 删除后，原位置的指针仍保留在底层数组中（只是切片长度变小），GC 看不到它已被“逻辑删除”，导致内存泄漏。
安全做法是显式置 nil：
- 先保存待删元素：
old := s[i] - 再执行删除：
s = append(s[:i], s[i+1:]) - 最后手动清空原数组槽位：
if i （注意：这里要操作的是原底层数组，需用 <code>reflect或提前保留指针） - 更稳妥的是在删除前把
s[i]设为nil，再append，这样即使底层数组未被覆盖，GC 也能识别
二维切片里删某个 (i,j) 元素，为什么不能写 s = append(...)？
因为 s 是 [][]T 类型，而 append(s[i][:j], s[i][j+1:]) 返回的是 []T，类型不匹配。错误写法如 s = append(s[:i], ...) 是在删整行，不是删单个元素。
必须明确作用目标：
- 删某行某列的值 → 改
s[i]：s[i] = append(s[i][:j], s[i][j+1:]) - 删整行（第 i 行）→ 改
s本身：s = append(s[:i], s[i+1:]) - 删整列（所有行的第 j 列）→ 需遍历每行：
for k := range s { s[k] = append(s[k][:j], s[k][j+1:]) } - 所有操作前都得检查
i 和 <code>j
性能敏感场景下能不能 O(1) 删除？
可以，但要牺牲顺序：把最后一个元素挪到待删位置，再缩短长度。
典型写法：s[i] = s[len(s)-1]; s = s[:len(s)-1]。这确实快，但要注意：
- 如果切片元素是指针或包含指针字段，挪动会复制指针值，不等于深拷贝，通常没问题
- 如果元素是大结构体，赋值开销可能抵消时间优势
- 若业务逻辑依赖顺序（比如队列、有序列表），这种删法会导致语义错误
- 删最后一个元素时，该方法退化为
s = s[:len(s)-1]，和常规尾删一致
s[0:5]），就可能读到已被“删除”但尚未覆盖的数据。这种隐式共享，在并发或长期持有切片引用时尤为危险。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
