Go错误处理应显式返回error并规范包装、透传、记录和终止，禁用泛滥的if err!=nil{return err}，统一用%w包装、AppError响应、errors.Is判断sql.ErrNoRows，日志必含%+v栈信息，panic仅用于致命初始化失败。
Go 的错误处理不是靠 panic/recover 拦截，而是靠显式返回 error 值并逐层判断——团队一旦放任自由处理，很快就会出现 if err != nil { return err } 泛滥、错误丢失上下文、日志无迹可寻、HTTP 接口返回 500 却没留线索等问题。规范的核心不是禁止什么，而是统一“错误何时包装、何时透传、何时记录、何时终止”。
用 fmt.Errorf + %w 包装错误时，只包装一次
常见错误是层层嵌套包装：fmt.Errorf("failed to read config: %w", fmt.Errorf("failed to open file: %w", err))。这会导致错误链冗长、重复、难以解析。
- 只在**职责边界处**包装：比如从 DAO 层返回原始
os.PathError，到 service 层应包装为业务语义错误fmt.Errorf("failed to load user profile: %w", err) - 必须用
%w（而非%s）才能保留原始错误供errors.Is/errors.As判断 - 不要在 defer、log、http handler 里二次包装——这些地方只该记录或响应，不该改写错误语义
HTTP handler 中不要直接 return err，要统一转成 HTTP 响应
Go 的 http.HandlerFunc 签名不支持返回 error，硬塞 return err 是语法错误；更常见的是在 handler 内部遇到 err != nil 就 http.Error(w, err.Error(), 500)，但这样丢失状态码语义和结构化信息。
- 定义统一的响应错误类型，例如
type AppError struct { Code int; Message string; Err error } - 所有 handler 内部用
if err != nil { respondError(w, &AppError{Code: http.StatusNotFound, Message: "user not found", Err: err}); return } - 避免在 handler 里调用
log.Printf——交给中间件或AppError的Error()方法统一记录（含 traceID、时间、路径）
数据库操作出错时，区分 sql.ErrNoRows 和其他错误
sql.QueryRow().Scan() 返回 sql.ErrNoRows 是正常业务流（比如查用户不存在），不是异常；但若返回 driver.ErrBadConn 或 context.DeadlineExceeded 就必须重试或告警。
立即学习“go语言免费学习笔记（深入）”；
- 永远用
errors.Is(err, sql.ErrNoRows)判断，而不是err == sql.ErrNoRows（因为可能被包装过） - 对非
sql.ErrNoRows的 DB 错误，优先检查是否可重试（如连接中断、事务冲突），再决定是返回 503 还是 500 - 不要把
sql.ErrNoRows包装成 “not found” 错误再抛给上层——它本身就是清晰、标准、可预测的信号
日志中记录错误，必须同时包含 err.Error() 和 fmt.Sprintf("%+v", err)
err.Error() 给人看，%+v 才能展开完整错误链、文件行号、调用栈。只打前者等于丢了一半线索。
log.Printf("failed to process order %d: %v (full: %+v)", orderID, err, err)
- 上线环境禁用
%+v？不行——至少在 warn/error 级别必须保留，否则线上排查等于盲人摸象 - 如果用了 zap/logrus，确保配置了
StacktraceKey并启用WithCaller(true) - 不要在日志里手动拼接
err.Error() + " at " + file + ":" + line——让%+v干这事，它更准
最难统一的其实是“什么时候该用 panic”。答案很窄：仅限程序无法继续运行的致命状态（如配置加载失败、DB 连接池初始化失败）。除此之外，所有业务错误都走 error 返回路径——哪怕看起来“不可能发生”，也要按常规错误流程走。否则，某天你发现一个 panic 被 recover 吞掉，而日志里连个痕迹都没有。
