go 中 error 是值而非异常，需显式返回；panic 仅用于不可恢复错误，业务错误必须返回 error；应使用 errors.is 判断嵌套错误、fmt.errorf("%w") 保留错误链、结构化 apperror 统一 http 错误响应。
Go 里没有 try-catch，error 是值，不是异常
Go 不支持传统意义上的“异常抛出与捕获”，error 是一个接口类型，通常由函数显式返回。你不能用 throw 或 catch，也不能靠 panic 来替代常规错误处理——除非真出了不可恢复的程序状态（比如空指针解引用、切片越界）。
常见误操作是把所有错误都用 panic 包裹，再用 recover 统一兜底。这在 Web 服务中极易掩盖真实问题：HTTP handler 中 panic 若未被中间件捕获，会导致整个 goroutine 崩溃且无日志；即使捕获了，也丢失了原始调用栈和上下文。
- 业务逻辑错误（如参数校验失败、数据库记录不存在）必须返回
error，而非触发 panic -
panic仅用于程序无法继续运行的场景（例如配置加载失败、依赖服务完全不可达且无降级策略） - Web 框架如
net/http默认不 recover panic，需手动加中间件或使用封装好的框架（如 Gin 的gin.Recovery()）
HTTP handler 中如何统一返回结构化错误
直接 http.Error(w, "xxx", http.StatusBadRequest) 虽然快，但前后端协作成本高：前端要解析纯文本，后端难加 traceID、状态码映射、i18n 支持。更合理的做法是定义统一响应体，并让错误可被中间件识别。
建议用自定义 error 类型配合 interface 判断：
立即学习“go语言免费学习笔记（深入）”；
type AppError struct {
Code int
Message string
TraceID string
}
func (e *AppError) Error() string { return e.Message }
func (e *AppError) StatusCode() int { return e.Code }
- handler 中遇到业务错误时，直接 return
&AppError{Code: http.StatusNotFound, Message: "user not found"} - 中间件检查
err是否实现了StatusCode()方法，从而决定 HTTP 状态码和 JSON body 格式 - 避免用字符串匹配判断错误类型（如
strings.Contains(err.Error(), "not found")），易错且不可维护
context.WithTimeout + errors.Is 处理超时与嵌套错误
Web 请求常依赖下游服务（DB、RPC、HTTP client），超时控制必须配合错误判断。Go 1.13+ 引入的 errors.Is 和 errors.As 是处理这类嵌套错误的关键。
例如 HTTP client 超时后返回的 context.DeadlineExceeded，会被包装多层：
if errors.Is(err, context.DeadlineExceeded) {
// 正确：能穿透 net/http、net/url 等标准库的错误包装
}
// 错误写法：err == context.DeadlineExceeded → 总是 false
- 所有 I/O 操作务必传入带 timeout 的
context.Context，并在 handler 开头设置 deadline - 用
errors.Is(err, os.ErrNotExist)判断文件不存在，而不是检查 error 字符串 - 自定义 error 可实现
Unwrap() error方法，让errors.Is能递归查找底层原因
日志与错误链：别只打 err.Error()
只记录 err.Error() 会丢失堆栈、原始错误类型和关键字段。尤其在微服务调用中，上游错误若没透传 traceID 或 code，下游排查将极其困难。
- 用
fmt.Errorf("failed to fetch user: %w", err)保留错误链，而非fmt.Errorf("failed to fetch user: %v", err) - 日志库（如 zap）应调用
logger.Error("db query failed", zap.Error(err))，而非zap.String("error", err.Error())—— 好的日志库会自动展开 error 链并打印 stack - 生产环境禁用
fmt.Printf("%+v", err)，它依赖 debug.PrintStack，性能差且不安全
错误处理最易被忽略的点，是把 “能运行” 当作 “处理得当”。一次未分类的 500、一条没 traceID 的日志、一个被吞掉的 io.EOF，都可能让线上问题延迟数小时才暴露。
