Go错误处理与资源管理
内容提要
Go语言将错误视为普通值，通过显式返回和检查处理，无异常机制。支持错误包装（%w）、哨兵错误和errors.As类型匹配。defer保证资源清理，按LIFO顺序执行，需注意循环中defer堆积和闭包引用捕获问题。命名返回值配合defer可包装错误，panic仅用于不可恢复情况，recover在defer中恢复。
延伸解读
错误处理哲学：显式优于隐式
Go 语言没有异常机制，错误作为普通值显式返回，调用者必须处理。这种设计虽然冗长，但让错误路径清晰可见，避免了隐式控制流带来的意外。与 Java 或 Python 的异常相比，Go 的错误处理更强调程序员对每个失败点的主动思考，代价是代码量增加，但换来的是可预测性和可读性。
错误包装的取舍：%w 与 %v
使用 %w 包装错误可以保留原始错误链，便于调用者通过 errors.Is 或 errors.As 进行判断；而 %v 则会将错误转换为普通字符串，切断链条。在跨 API 边界时，若不想暴露内部错误类型，可故意使用 %v 隐藏细节。选择哪种方式取决于是否需要下游代码对错误进行程序化检查。
defer 的陷阱与正确用法
defer 在循环中会堆积，直到函数返回才执行，容易导致资源长时间占用。解决方法是把循环体封装为独立函数，使 defer 在每次迭代结束时触发。此外，defer 闭包捕获变量是引用语义，若需保存当时值，应通过参数传递。理解这些细节能避免常见的资源泄漏和逻辑错误。
panic 与 recover 的边界
panic 仅用于不可恢复的编程错误，如数组越界或状态不一致，不应替代常规错误处理。recover 只能在 defer 中生效，用于在 API 边界（如 HTTP 处理器）将 panic 转换为错误，防止单个请求导致整个服务崩溃。在 panic 展开过程中，defer 仍会执行，确保资源清理不遗漏。
Q&A
Go语言如何处理错误？
Go语言将错误视为普通值，函数返回错误作为最后一个返回值，调用者通过显式的if err != nil检查来处理，没有异常机制。
Go中错误包装的%w和%v有什么区别？
%w用于包装错误，保留原始错误的链，使得errors.Is和errors.As可以穿透包装层；%v只是格式化错误消息，不保留链，导致无法匹配原始错误。
errors.Is和errors.As分别用于什么场景？
errors.Is用于检查错误链中是否包含特定的哨兵错误值；errors.As用于提取错误链中特定类型的错误，以便访问其字段。
在Go中，defer语句的执行顺序是怎样的？
defer语句按后进先出（LIFO）顺序执行，即最后注册的defer最先执行。
在循环中使用defer有什么问题？如何解决？
在循环中直接使用defer会导致所有延迟调用堆积到函数返回时才执行，资源无法及时释放。解决方法是把循环体包装成一个函数，使defer在每次迭代结束时执行。
defer闭包捕获变量是按值还是按引用？
defer闭包捕获变量是按引用，即看到的是变量最终的值，而不是defer执行时的值。如果需要捕获当时的值，可以将变量作为参数传递给闭包。
如何利用命名返回值在defer中包装错误？
通过命名返回值，在defer函数中检查并修改返回值，例如将错误包装上更多上下文，避免在每个返回语句重复包装。
panic和recover在Go中如何使用？
panic用于不可恢复的错误，recover只能在defer中调用，用于捕获panic并恢复执行，通常用于API边界将panic转换为错误。
