Go错误处理核心是结构化语义：需用哨兵错误、自定义类型（含Unwrap）、%w包装、显式状态码映射，禁字符串匹配、裸panic及敏感信息泄露。
error 接口实现与哨兵错误的混用问题
很多 Go 框架（如 Gin、Echo）早期直接暴露 errors.New 创建的字符串错误，或在包顶层定义像 ErrNotFound 这样的哨兵变量。这看似简单，但实际协作中容易踩坑：不同模块定义同名哨兵错误导致 == 判断失效；跨服务传递时丢失上下文；HTTP 中间件无法统一注入状态码。
推荐做法是把哨兵错误封装为导出的变量，且类型必须唯一可识别：
- 避免直接用
errors.New("not found")，改用自定义类型：type ErrNotFound struct{ Code int } - 实现
Error()方法时固定返回字符串，但保留结构体字段供外部提取元信息 - 框架层（如 Gin 的
c.Error()）应只接收error，不依赖具体类型，靠errors.As()解包判断
fmt.Errorf + %w 包装链的中断风险
当框架中间件调用业务逻辑后层层包装错误时，fmt.Errorf("failed to process: %w", err) 是标准做法。但容易忽略两点：一是底层错误本身未实现 Unwrap()（比如某些第三方库返回的裸字符串错误），导致 errors.Is(err, myErr) 失效；二是 HTTP handler 里直接 log.Printf("%v", err) 会丢失包装层级，只打出最外层消息。
验证是否支持完整包装链：
立即学习“go语言免费学习笔记（深入）”；
- 用
errors.Unwrap()循环解包，确认能抵达原始错误 - 测试
errors.Is(err, os.ErrNotExist)是否仍为 true（即使被多层包装） - 框架日志中间件应调用
fmt.Sprintf("%+v", err)而非%v，才能打印堆栈和包装路径
HTTP 状态码与 error 的绑定方式变迁
旧式框架常靠全局 map 映射错误类型到状态码（如 map[error]int{ErrUnauthorized: 401}），但扩展性差、易冲突。现代实践转向「错误携带状态」：让自定义错误类型内嵌 HTTP 状态字段，并在统一错误处理器中提取。
例如：
type HTTPError struct {
Code int
Err error
}
func (e *HTTPError) Error() string { return e.Err.Error() }
func (e *HTTPError) StatusCode() int { return e.Code }
// 中间件中：
if errors.As(err, &httpErr) {
c.AbortWithStatusJSON(httpErr.StatusCode(), gin.H{"error": httpErr.Error()})
}
注意：不要在业务层硬编码 c.JSON(404, ...)，否则错误无法被上层统一拦截和审计。
panic/recover 在框架中的误用边界
框架开发者有时用 recover() 捕获 panic 并转成 HTTP 500，这是合理场景。但常见错误是：在普通业务 handler 里滥用 defer/recover 替代错误检查——这掩盖了本该显式处理的 error，且无法触发 errors.Is() 或日志上下文注入。
真正需要 recover 的只有两类情况：
- 第三方库内部 panic（如模板渲染、JSON 序列化失败）
- 框架自身路由匹配或中间件链执行时的不可恢复崩溃
业务函数里出现 panic("should not happen") 或 recover()，基本说明错误路径没走 error 返回约定，属于设计倒退。
