go中自定义错误类型用于结构化传递错误上下文，而非模拟异常；panic/recover不应用于业务错误，因违背设计哲学且破坏错误链；需用指针接收者实现error接口并提供unwrap方法以支持errors.is/as，日志应保留结构化字段。
Go 里没有异常处理，自定义错误类型不是用来“捕获异常”的，而是为了结构化地表达和传递错误上下文。 把它当成 Java 的 try/catch 或 Python 的 raise/except 去理解，会直接踩坑。
为什么不能用 panic/recover 模拟异常来配合自定义错误？
很多人刚学 Go 时想“模拟异常流程”，比如在出错时 panic 一个自定义错误，再用 recover 捕获。这违背 Go 的设计哲学：
-
panic是为真正不可恢复的程序错误准备的（如空指针解引用、栈溢出），不是业务错误的出口 - 一旦
panic，调用栈会立即展开，中间所有 defer 都执行，但你无法控制传播路径 —— 无法做 error wrapping、无法用errors.Is判断、无法保留原始上下文 -
recover只能在 defer 中安全调用，且必须在同 goroutine 内；跨 goroutine 的 panic 无法 recover，极易导致服务崩溃
自定义错误类型必须实现 error 接口，但别忘了指针接收者 vs 值接收者
常见错误是定义结构体后，用值接收者实现 Error() 方法，结果在包装时丢失类型信息：
- 如果写
func (e MyError) Error() string（值接收者），那么fmt.Errorf("wrap: %w", MyError{...})会把原值拷贝一份，errors.As(err, &target)无法成功断言到*MyError - 正确做法是统一用指针接收者：
func (e *MyError) Error() string，并确保返回错误时用&MyError{...} - 否则你在 handler 层调用
errors.As(err, &myErr)总是失败，查半天发现是接收者类型不匹配
如何让自定义错误支持 errors.Is 和 errors.As？
光实现 Error() 不够，要参与错误链就必须支持解包：
- 如果你的错误需要被上层用
errors.Is(err, ErrNotFound)判断，它得是哨兵错误（全局变量），或包装了哨兵错误 - 如果你的错误要携带额外字段（如
Code、TraceID），又希望上层能用errors.As(err, &myErr)提取，就必须实现Unwrap() error方法 - 典型写法：在结构体里嵌一个
error字段，Unwrap()返回它；这样fmt.Errorf("xxx: %w", underlyingErr)才能形成可遍历的链 - 漏掉
Unwrap就等于切断了错误链，errors.Is和errors.As在多层包装后全部失效
别在日志里只打印 err.Error()，丢失结构化信息
自定义错误类型最有价值的部分是字段（如 Code、RequestID、SQL），但 fmt.Println(err) 只调用 Error() 方法，字段全丢光：
- 日志输出时，显式访问字段：
log.Printf("code=%d req=%s msg=%s", myErr.Code, myErr.RequestID, myErr.Message) - 或者实现
fmt.Stringer接口，但注意不要和error.Error()冲突 —— 日志系统可能同时调用两者 - 更稳妥的是用结构化日志库（如
zap）直接传入字段：logger.Error("db query failed", zap.Int("code", myErr.Code), zap.String("sql", myErr.SQL))
真正难的不是定义一个带字段的结构体，而是在每一层函数调用中决定：该用 fmt.Errorf("%w", err) 包装，还是 fmt.Errorf("context: %v", err) 丢弃原错误，或是直接返回哨兵错误。这个决策链比语法本身更影响后期维护成本。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
