Go 中 error 是值而非异常，业务错误须显式返回并处理，仅在程序无法继续时用 panic；应使用 errors.Is/As 判断错误，%w 包装增强上下文，避免字符串匹配或忽略错误。
Go 中 error 类型不是异常，别用 panic 处理业务错误
Go 的 error 是值，不是控制流机制。把业务逻辑错误（如用户输入非法、数据库记录不存在）交给 panic，会导致调用栈中断、难以 recover，且掩盖了本该显式处理的失败路径。
常见错误现象：panic: record not found 被顶层 recover 拦截后吞掉，日志里只留一行空 panic，根本看不出是哪个 SQL 查询失败。
- 仅在程序无法继续运行时用
panic（如配置文件缺失、监听端口被占用） - 所有 I/O、网络、解析、校验类操作，必须返回
error并由调用方决定如何响应 - 避免在库函数中
log.Fatal或os.Exit，这会剥夺使用者的错误处置权
用 errors.Is 和 errors.As 判断错误类型，而不是字符串匹配
早期 Go 项目常写 if strings.Contains(err.Error(), "timeout")，这种写法脆弱：错误消息一变就失效，且无法跨包复用语义。
Go 1.13 引入的 errors.Is 和 errors.As 支持对包装错误（wrapped error）做语义化判断：
立即学习“go语言免费学习笔记（深入）”；
if errors.Is(err, context.DeadlineExceeded) {
// 处理超时
}
var netErr net.Error
if errors.As(err, &netErr) && netErr.Timeout() {
// 更细粒度的网络超时判断
}
- 自定义错误应实现
Unwrap() error方法，或直接用fmt.Errorf("wrap: %w", err) - 第三方库返回的错误若未包装（如某些旧版 PostgreSQL 驱动），可先用
errors.Unwrap尝试降级 - 不要依赖
err == someErrVar做判断——除非你明确控制了错误变量的唯一性（如var ErrNotFound = errors.New("not found")）
不要忽略 error，但也不要无脑 if err != nil 后全盘返回
忽略错误（_ = doSomething()）是 Go 最常见 bug 来源；但另一种倾向是每层都原样返回，导致上层拿到的错误堆栈浅、上下文丢失。
关键在于区分「错误传播」和「错误增强」：
- 底层调用失败，但当前函数语义上可以兜底（如缓存未命中则查 DB），就不该把底层错误透传上去
- 需要传递错误时，优先用
%w包装：return fmt.Errorf("fetch user %d from db: %w", id, err) - 导出函数的错误应尽量包含动作 + 对象 + 原因（如
"decode JSON body: invalid character 'x'"），而非仅"invalid input" - HTTP handler 等入口处可统一用中间件捕获并转为 HTTP 状态码，但中间业务层不应自己写
http.Error
测试中主动构造和断言错误，尤其是包装链
很多 Go 项目只测“成功路径”，等线上遇到 io.EOF 或自定义 ErrValidation 才发现处理逻辑没覆盖。
单元测试要验证错误是否被正确包装、是否能被 errors.Is 识别、是否含预期字段：
func TestFetchUser(t *testing.T) {
svc := &Service{repo: &mockRepo{err: errors.New("db timeout")}}
_, err := svc.GetUser(123)
if !errors.Is(err, context.DeadlineExceeded) {
t.Fatal("expected wrapped timeout error")
}
}
- mock 对象应支持返回各种预设错误（
io.EOF、sql.ErrNoRows、自定义错误等） - 对返回错误的函数，至少写一个 “error path” 测试用例
- 使用
testify/assert.ErrorIs或原生errors.Is断言，别用assert.EqualError比对字符串
错误处理真正难的不是语法，而是每次调用前想清楚：这个错误发生时，调用方需要知道什么？它能否重试？要不要告警？有没有更友好的降级方式？这些决策藏在每一行 if err != nil 后面。
