JetBrains ĺŽ˜ć–šćˇąĺşŚćŒ‡ĺ—ďźšĺŚ‚ä˝•ĺœ¨ Go ä¸äź˜é›…ĺœ°ĺ¤„ç†é”™čŻŻďźŸäťŽĺş•ĺą‚ĺŽŸç†ĺˆ°çŽ°äťŁćœ€ä˝łĺŽžčˇľ
内容提要
Go语言将错误视为普通值，通过error接口处理。核心技巧包括：用fmt.Errorf和%w包装错误保留链条；用errors.Is、As及泛型AsType检查错误类型；用errors.Join聚合多错误；用context.WithCancelCause追溯取消原因。最佳实践是避免忽略错误、提供上下文、慎用panic，并注意log.Fatal会跳过defer清理。
延伸解读
错误包装的上下文价值
文章强调，在错误向上传递时，应使用fmt.Errorf配合%w包装错误，以保留原始错误链和类型信息。直接拼接字符串会丢失结构化信息，导致上层无法用errors.Is或errors.As进行精确判断。实践中，即使只添加函数名也能显著提升日志的可诊断性，避免出现“database error”这类无上下文线索的模糊信息。
errors.AsType的优势与适用场景
Go 1.26引入的errors.AsType[E]是errors.As的泛型替代方案，它通过类型参数直接指定目标错误类型，避免了反射和运行时panic风险，并能在编译期捕获类型错误。文章建议新代码优先使用AsType，尤其在需要连续检查多种错误类型时，其变量作用域更清晰。但As并未弃用，旧代码仍可正常工作。
panic与recover的边界
Go的panic/recover机制并非try-catch的替代品，仅适用于不可恢复的严重错误，如硬编码正则表达式编译失败或内存耗尽。业务错误应通过返回值显式传递，以保证控制流清晰。文章警告，滥用panic会导致中间函数无法感知错误，且Go没有类似Java的throws声明，使得错误流向不透明。
错误处理中的常见陷阱
文章列举了多个易犯错误：忽略错误（赋值给_）、传递错误时不添加上下文、错误信息过于笼统、使用不恰当的错误类型、遗漏错误日志，以及误用log.Fatal（会跳过defer清理）。建议在main函数最外层使用log.Fatal，并确保不依赖defer。此外，应优先选择错误处理规范的第三方库。
Q&A
Go语言中错误处理的基本理念是什么？
Go语言将错误视为普通的值（Errors are values），错误是程序正常控制流的一部分，函数遇到错误时将其作为返回值返回，由调用方检查并处理。
如何在Go中包装错误并保留原始错误链？
使用fmt.Errorf配合%w格式化动词来包装错误，例如：fmt.Errorf("open failed: %w", err)。这样会保留原始错误，并支持后续通过errors.Unwrap等函数解包。
errors.Is、errors.As和errors.AsType有什么区别？
errors.Is用于判断错误链中是否包含特定错误值；errors.As用于将错误链中的错误赋值给指定类型的变量；errors.AsType是Go 1.26引入的泛型版本，类型安全且避免反射，推荐在新代码中使用。
如何合并多个错误并处理合并后的错误？
使用errors.Join函数可以合并多个错误，例如：errs = errors.Join(errs, err)。合并后的错误不能直接用errors.Unwrap解包，但可以通过类型断言获取其Unwrap() []error方法，返回错误切片。
如何追溯context取消的原因？
使用context.WithCancelCause创建可携带原因的取消上下文，调用cancel时传入自定义错误，之后可通过context.Cause(ctx)获取该错误。
在Go中何时应该使用panic而不是返回错误？
panic应仅用于不可恢复的严重错误，如硬编码正则表达式编译失败或内存耗尽。对于可预见的业务错误，应返回错误值，而不是使用panic。
Go错误处理中有哪些常见陷阱？
常见陷阱包括：忽略错误（赋值给_）、传递错误时不添加上下文、错误信息过于笼统、使用不恰当的错误类型、遗漏错误日志、使用log.Fatal跳过defer清理等。
如何针对特定类型的错误（如网络错误）进行处理？
对于网络错误，可以使用errors.As检查是否为net.OpError，并调用其Temporary()方法判断是否为临时性错误，从而决定是否重试。
