go将错误视为普通返回值而非异常，因此必须显式检查err != nil；fmt.errorf("%w")用于保留可被errors.is/as检测的错误链，而%s拼接会断链；自定义错误需实现unwrap()才能参与标准错误链，且仅在需结构化字段或业务决策时才应定义。
error 是值，不是异常；不检查 err != nil 就继续往下走，十有八九会 panic 或静默失败。
为什么 Go 不用 try-catch？
因为 Go 把错误当作普通返回值处理，而不是控制流中断机制。这带来两个实际影响：
• 调用方必须主动看 err，编译器不会强制，但忽略它几乎等于埋雷
• 错误无法“被抛出到上层”，只能靠手动传递或包装，所以错误链容易断掉
• panic 真的是异常——它不走正常返回路径，defer 会执行，但不会被 if err != nil 捕获
fmt.Errorf 和 %w 怎么选？
用 %w 只在你需要保留原始错误以便后续用 errors.Is 或 errors.As 判断时才必要。
常见误用：
• 所有地方都写 fmt.Errorf("xxx: %w", err)，但下游根本没调用 errors.Is(err, fs.ErrNotExist) —— 白加一层包装
• 该用 %w 却写了 %s，导致 errors.Is 失效
• 在日志里直接打印包装后的错误（比如 log.Printf("%v", err)），看不出原始类型，调试困难
• 包装时没加有意义的上下文，比如 fmt.Errorf("read config: %w", err) 比 fmt.Errorf("failed: %w", err) 强得多
自定义错误类型什么时候值得写？
当标准错误无法支撑你的业务决策时才需要。
典型场景：
• HTTP handler 需要根据错误类型返回不同状态码（如 404 vs 400）
• 重试逻辑需区分临时错误（网络超时）和永久错误（参数校验失败）
• 需要携带结构化字段，比如错误码 Code、追踪 ID TraceID、原始请求参数快照
注意：
• 实现 Unwrap() 方法才能让 %w 和 errors.As 正常工作
• 不要只为“看起来专业”而定义新类型，多数时候 fmt.Errorf("xxx: %w", err) 已足够
• 自定义错误的 Error() 方法别拼接敏感信息（如密码、token），日志可能泄露
并发场景下错误怎么传出来？
goroutine 里发生的错误不能靠返回值直接传给主 goroutine，必须显式同步。
常用方式：
• errChan := make(chan error, 1) + select 或 recv, ok := <br>• <code>sync.WaitGroup 配合闭包变量（注意竞态，需加 mutex）
• 更推荐：用 errgroup.Group，它自动聚合第一个非 nil 错误，且支持上下文取消
关键陷阱：
• 启动 goroutine 后忘了收错误，导致错误丢失
• 多个 goroutine 写同一个 error 变量，没加锁，结果被覆盖
• 用 recover() 拦 panic，却误以为能捕获普通 error —— 完全两回事
if err != nil，而是判断这个 err 到底该返回、重试、降级，还是记录后吞掉。很多崩溃，源头都是某处把本该终止流程的错误，当成可忽略的 warning 处理了。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
