go错误应使用Error接口而非字符串拼接，需封装底层错误、携带结构化信息、支持errors.is/as判断，并区分控制流与业务错误，避免panic滥用，日志中须展开错误链。
用 error 接口而不是字符串拼接错误
Go 的错误本质是值，不是异常；error 是接口，不是类型。很多人一上来就写 errors.New("failed to open file") 或 fmt.Errorf("read %s: %w", path, err)，这没错，但容易导致错误链断裂或丢失上下文。
真正健壮的做法是：封装底层错误、携带结构化信息、支持判断和展开。比如自定义错误类型时，必须实现 Error() 方法，并考虑嵌入 Unwrap()（Go 1.13+）来支持 errors.Is() 和 errors.As()。
- 不要用
err == io.EOF判断，改用errors.Is(err, io.EOF) - 不要靠字符串匹配错误信息（如
strings.Contains(err.Error(), "timeout")），它脆弱且不跨版本 - 若需携带额外字段（如请求 ID、重试次数），定义结构体并实现
Unwrap()，而非拼接进Error()字符串
区分控制流错误和业务错误，别全塞进 error 返回值
不是所有“失败”都该走 error 返回路径。比如解析 json 时字段缺失，可能是合法的空值场景；http handler 中用户传了非法参数，应返回 400 而非让上层 panic；数据库查不到记录，有时是预期行为（如查询用户详情不存在），不该等同于系统故障。
关键判断标准：这个“错”是否需要调用方立即决策？是否影响后续流程？如果答案是否定的，就该用明确的返回值（如 user, found := db.GetUser(id)）或状态码代替 error。
立即学习“go语言免费学习笔记（深入）”；
- 避免把
nil作为“成功”信号后又在下一行 panic —— 这等于把错误处理推给调用方，却没提供足够信息 - 对第三方库返回的
error，先用errors.Is()分类，再决定是透传、包装、还是吞掉（仅限明确已知可忽略的情形） - HTTP handler 中，建议统一用中间件捕获未处理的
error，转为标准响应，而不是每个 handler 都手写if err != nil { return ... }
日志中打印错误时，别只打 err.Error()
很多服务上线后查问题卡在“只看到一行 failed to write: context canceled”，完全不知道是哪个 goroutine、哪个请求、哪次重试触发的。根本原因是日志只取了错误的摘要字符串，丢掉了堆栈、上下文和原始错误链。
Go 1.17+ 的 fmt.Errorf("%w", err) 会保留堆栈（如果底层错误支持），但日志库未必能自动展开。真正有效的做法是：用支持错误展开的日志库（如 zerolog 或 zap），并在写日志时显式调用 errors.Unwrap() 或使用其内置错误字段。
- 别写
log.printf("write failed: %v", err)——%v通常只输出顶层Error()，不展开 - 用
log.Printf("write failed: %+v", err)（github.com/pkg/errors）或logger.Err(err).Msg("write failed")（zerolog）才能看到完整链路 - 生产环境禁止用
panic替代错误处理，尤其在 HTTP handler 或 goroutine 中 —— 它不会被标准 recovery 捕获，且无上下文
测试错误路径比测试成功路径更难，但更值得投入
多数人只测 err == nil 分支，但真实系统崩溃往往发生在第 3 层依赖返回超时、第 5 次重试失败、或并发竞争导致状态不一致时。Go 没有 checked exception，错误路径天然容易被忽略。
有效策略是：用接口隔离外部依赖，然后在测试中注入可控的错误实现；对关键错误分支（如重试逻辑、降级开关、连接池耗尽）写白盒测试，验证是否按预期处理而非静默失败。
- 对
io.Reader、http.RoundTripper、database/sql/driver.Conn等接口，自己实现返回特定错误的 mock，比如io.ErrUnexpectedEOF或自定义的tempError - 避免在测试里写
if err != nil { t.Fatal(err) }—— 这只会掩盖错误处理逻辑是否正确 - 用
testify/assert或原生assert.Equal(t, true, errors.Is(err, mypkg.ErrTimeout))显式断言错误类型，而非只检查非空
错误架构最常崩在边界叠加处：超时 + 重试 + 上下文取消 + 日志采样率限制。这些地方没法靠单测全覆盖，得靠混沌测试或线上小流量验证。但至少，别让第一个 panic 出现在生产环境。