go 中无法直接用 try-catch，但可通过 defer + recover 在循环内捕获 panic，使程序跳过异常项继续下一次迭代；关键在于将 recover 逻辑置于每次循环迭代的独立作用域中（如在 for 循环体内使用匿名函数或封装为辅助函数）。
go 中无法直接用 try-catch，但可通过 defer + recover 在循环内捕获 panic，使程序跳过异常项继续下一次迭代；关键在于将 recover 逻辑置于每次循环迭代的独立作用域中（如在 for 循环体内使用匿名函数或封装为辅助函数）。
在 Go 中，panic 会立即中断当前 goroutine 的执行流，若不显式恢复（recover），程序将终止。与 Java 的 try-catch 不同，Go 的错误处理强调显式错误返回（如 error 类型），而 panic/recover 仅适用于真正异常、不可恢复的场景（如空指针解引用、越界访问等）。但当需在循环中容忍个别操作失败并继续执行时，可借助 defer + recover 实现类似“跳过失败项”的效果——前提是 recover 必须在 panic 发生的同一 goroutine 且同一函数调用栈中生效。
⚠️ 原代码的问题在于：arr 是长度为 5 的切片（[]int{5,6,7,8,9}），却试图通过 arr[6] = i 写入索引 6，触发运行时 panic（index out of range）。更严重的是，defer 被放在 for 循环外部（实际在 main 函数作用域注册），导致 recover() 只会在 main 函数结束时执行，而此时 panic 已经导致程序崩溃，无法捕获。
✅ 正确做法是：将 defer + recover 移入每次循环迭代内部，确保每个迭代拥有独立的 panic 捕获上下文。以下是推荐写法：
package main
import "fmt"
func main() {
arr := []int{5, 6, 7, 8, 9}
fmt.Println("初始切片:", arr)
for i := 6; i < 10; i++ {
// ✅ 每次迭代都新建一个 defer 作用域
defer func(index int) {
if r := recover(); r != nil {
fmt.Printf("索引 %d 处发生 panic: %v，已跳过，继续下一迭代\n", index, r)
}
}(i) // 立即传入当前 i 值，避免闭包变量捕获问题
// 尝试越界写入 —— 这里会 panic
arr[i] = i // panic: index out of range [6] with length 5
}
fmt.Println("循环结束后切片:", arr) // 注意：此行不会执行，因 panic 未被及时捕获
}❌ 上述写法仍有缺陷：defer 在 main 函数退出时才执行，而 panic 发生后 main 立即终止，defer 根本来不及运行。
✅ 真正有效的方案是：用匿名函数包裹单次迭代逻辑，并在其中调用 recover：
package main
import "fmt"
func main() {
arr := []int{5, 6, 7, 8, 9}
fmt.Println("初始切片:", arr)
for i := 6; i < 10; i++ {
// ? 关键：用立即执行函数（IIFE）创建独立作用域
func(index int) {
defer func() {
if r := recover(); r != nil {
fmt.Printf("⚠️ 迭代 i=%d 失败: %v，已忽略，继续下一轮\n", index, r)
}
}()
// 此处执行可能 panic 的操作
arr[index] = index // 触发 panic
}(i)
}
fmt.Println("✅ 循环全部完成，最终切片:", arr)
}? 输出示例：
初始切片: [5 6 7 8 9] ⚠️ 迭代 i=6 失败: runtime error: index out of range [6] with length 5，已忽略，继续下一轮 ⚠️ 迭代 i=7 失败: runtime error: index out of range [7] with length 5，已忽略，继续下一轮 ⚠️ 迭代 i=8 失败: runtime error: index out of range [8] with length 5，已忽略，继续下一轮 ⚠️ 迭代 i=9 失败: runtime error: index out of range [9] with length 5，已忽略，继续下一轮 ✅ 循环全部完成，最终切片: [5 6 7 8 9]
? 更优雅的实践建议：
-
优先避免 panic：对切片操作应先检查边界（
if index ），或使用 <code>append动态扩容； -
用 error 替代 panic：将易错逻辑封装为返回
(value, error)的函数，配合if err != nil { continue }； -
慎用 recover：仅用于顶层错误兜底（如 HTTP handler）、测试模拟或极少数必须“吞掉” panic 的场景；生产代码中滥用
recover会掩盖真实 bug。
总结：Go 中实现“循环内容错继续”，核心是确保 recover() 与 panic() 处于同一函数调用栈，且 defer 绑定在可能 panic 的最小作用域内。永远记住：panic 不是错误处理机制，而是异常终止信号；健壮性应来自预防，而非事后抢救。
