Go 中通过切片技巧（如 xs = append(xs[:i], xs[i+1:]...)）删除元素在官方 gc 编译器中正常运行，但在 gccgo 中可能触发越界 panic；根本原因在于二者对多值赋值中索引求值顺序的实现差异，而 gccgo 更严格符合语言规范。
go 中通过切片技巧（如 `xs = append(xs[:i], xs[i+1:]...)`）删除元素在官方 gc 编译器中正常运行，但在 gccgo 中可能触发越界 panic；根本原因在于二者对多值赋值中索引求值顺序的实现差异，而 gccgo 更严格符合语言规范。
在 Go 官方推荐的《Slice Tricks》中，删除切片中第 i 个元素的经典写法是：
xs = append(xs[:i], xs[i+1:]...)
但当需要同时清零原底层数组末尾残留指针（防止内存泄漏，尤其在 []*T 场景下）时，部分开发者会尝试将两个操作合并为一条语句，例如：
xs, xs[len(xs)-1] = append(xs[:i], xs[i+1:]...), 0
这段代码在 gc（即 go build / go run）下能顺利输出 [0 1 3 4]，但在 gccgo 下却会 panic：
panic: runtime error: index out of range
原因在于：Go 语言规范并未规定多值赋值中左右侧表达式的求值顺序，而 gccgo 和 gc 采用了不同的实现策略。
- gc 先计算右侧 append(...) 得到新切片 xs'，再用 xs'[len(xs')-1] 赋值（此时 len(xs') == len(xs)-1，索引合法）；
- gccgo 则严格按“左侧标识符求值优先”原则，在执行 append 前就先计算 xs[len(xs)-1] —— 此时 xs 尚未更新，长度仍为 5，i=2，xs[i+1:] 即 xs[3:] 合法，但关键问题在于：赋值左侧的 xs[len(xs)-1] 中的 xs 是原始切片，其长度未变，看似无害；然而 append(xs[:i], xs[i+1:]...) 的执行可能引发底层数组扩容或复用，导致后续对 xs 的访问行为不可预测。更本质的是，该写法隐含了对 xs 状态的竞态依赖，属于未定义行为（undefined behavior）。
正如 Go 官方 Issue #23188 所确认：gccgo 的 panic 实际上更贴近语言规范精神——它拒绝了这种依赖求值顺序的脆弱表达式，而 gc 的宽容反而掩盖了潜在风险。
✅ 正确、可移植、符合规范的写法应分步执行，明确控制状态变更顺序：
package main
import "fmt"
func main() {
xs := []int{0, 1, 2, 3, 4}
i := 2
// 步骤1：执行删除，获得新切片
xs = append(xs[:i], xs[i+1:]...)
// 步骤2：若需清理原底层数组末尾（如 []*T），显式操作旧容量边界
// 注意：此时 xs 的 len 已变为 4，但 cap 可能仍为 5
// 若需置零原最后一个有效位置（即旧切片末尾），应使用原始容量信息：
if cap(xs) > len(xs) {
// xs[len(xs)] 指向被删除元素后、当前 len 之外的第一个位置（原末尾）
// 对于 []*T，此处应设为 nil
// 这里以 int 为例，设为 0（实际中仅对指针类型有意义）
xs[len(xs)] = 0 // ← 清理被“暴露”出的旧元素位置
}
fmt.Println(xs) // [0 1 3 4]
}⚠️ 重要提醒：
- xs[len(xs)-1] = 0 在删除后已无意义（因为 len 已减小），真正需要清理的是原底层数组中被移除元素所在位置，即 xs[i]（删除前）或等效的 xs[len(xs)]（删除后，若 cap > len）；
- 对于 []*T 类型，务必在删除后将对应位置设为 nil，否则可能导致 GC 无法回收目标对象；
- 永远不要依赖多值赋值中左右侧表达式的执行时序——这不属于 Go 规范保证的行为，跨编译器必然不一致。
总结：追求简洁不应牺牲可移植性与安全性。使用分步操作不仅兼容 gc 和 gccgo，也更清晰、更易测试、更符合 Go “explicit is better than implicit” 的设计哲学。
