应返回error而非随意panic，仅在不可恢复时用panic；必须显式处理error，禁用_忽略；合理包装错误，避免冗余；recover仅用于顶层防护，非错误处理机制。
panic 代替 error 返回，导致无法恢复
新手常把 panic 当作“报错”用，比如在文件打开失败、JSON 解析出错时直接 panic(err)。这会让调用方彻底失去控制权，且无法用 recover 拦截（除非在同 goroutine 且显式 defer），更不符合 Go 的错误处理哲学。
正确做法是：绝大多数非程序崩溃类问题，应返回 error 类型，由调用方决定是否终止流程。
- 只有真正不可恢复的场景才用
panic：如 nil 指针解引用、切片越界、断言失败等运行时错误 -
http.HandlerFunc等框架入口中，panic可能被中间件捕获并转为 500，但这是框架行为，不是你该依赖的错误处理方式 - 避免在库函数中
panic—— 这等于强制调用方用recover，破坏了 API 的可预测性
忽略 error 或只写 _ = err
Go 编译器强制检查未使用的变量，但新手常写 _ = doSomething() 来“绕过”编译错误，或干脆删掉 err 变量声明。结果是：磁盘写满、网络超时、权限不足……全被静默吞掉。
哪怕只是日志记录，也必须显式处理 error。
- 不要用
if err != nil { return }就完事 —— 至少加log.Printf("failed to X: %v", err) - 在 CLI 工具中，常见做法是
if err != nil { log.Fatal(err) }；在库中则必须向上返回 - 使用
errors.Is(err, os.ErrNotExist)或errors.As(err, &pathErr)做类型判断，而不是用字符串匹配err.Error()
error 包装丢失上下文或过度包装
Go 1.13 引
入了 %w 动词和 errors.Unwrap，但新手要么完全不用（只返回原始错误），要么层层 fmt.Errorf("step A failed: %w", err) 导致堆栈爆炸、日志冗余。
关键是要让错误既可定位，又不重复。
- 在关键边界处包装一次即可：比如从数据库层到 service 层，用
fmt.Errorf("create user: %w", err) - 避免在每一层都包装 —— 不要从 DAO → Service → Handler 都加前缀，最终日志里出现 “HTTP handler → service → repo → sql driver” 四重嵌套
- 调试时用
fmt.Printf("%+v", err)查看带栈信息的错误（需用github.com/pkg/errors或 Go 1.20+errors.Join配合）
defer + recover 滥用，误以为能兜住所有错误
看到 “Go 没有 try/catch” 就急着自己模拟，写一堆 defer func() { if r := recover(); r != nil { ... } }()。但 recover 只对同 goroutine 中的 panic 有效，且一旦执行就终止当前 defer 链，极易掩盖真实问题。
它不是错误处理机制，而是最后的崩溃防护网。
- 仅在顶层 goroutine（如 HTTP handler、goroutine 入口）中谨慎使用
recover，用于防止 panic 导致进程退出 - 绝不在普通函数里写
recover—— 这说明你本该用error处理，却用panic制造了需要兜底的麻烦 -
recover()返回的是interface{}，不是error，不能直接参与 Go 的错误链，也无法用errors.Is判断
最隐蔽的坑是：把错误处理逻辑写得“看起来很完整”，比如每层都 if err != nil { return err }，但忘了上层没检查返回值，或者用 var err error 声明后，在多个分支里忘记赋值 —— 此时 err 是 nil，而实际操作已经失败。
