Go中应避免用panic替代错误返回，所有I/O等操作须返回error供显式处理；推荐自定义实现error接口的结构体携带上下文，并合理使用错误链与日志记录。
Go 里不要用 panic 替代错误返回
很多从其他语言转来的开发者习惯用异常机制兜底，但在 Go 中，panic 仅用于真正不可恢复的程序错误（如空指针解引用、切片越界访问），不是错误处理的常规路径。一旦触发 panic，默认会中断当前 goroutine 的执行流，且无法被调用方用 if err != nil 捕获和决策。
常见错误现象：在 HTTP handler 或数据库查询封装中滥用 panic，导致服务偶发崩溃或 500 错误不可追溯；或者用 recover 在顶层“吞掉” panic，掩盖真实问题。
- 所有 I/O、网络、解析、校验类操作，必须返回
error类型，由调用方显式判断 - 若真要封装 panic 场景（如初始化失败），应定义明确的 fatal error 类型，并在
main函数中统一处理，而不是散落在业务逻辑里 -
panic的参数建议是字符串字面量或实现了Error()方法的自定义类型，避免传入nil或未导出结构体
用自定义错误类型携带上下文信息
标准库的 errors.New 和 fmt.Errorf 返回的是无结构的错误值，难以做类型断言、分类处理或日志打点。生产环境需要能区分“用户不存在”和“数据库连接超时”，而不仅是“操作失败”。
推荐做法是定义实现 error 接口的结构体，并嵌入字段记录错误码、追踪 ID、原始错误等：
立即学习“go语言免费学习笔记（深入）”；
type AppError struct {
Code int
Message string
TraceID string
Cause error
}
func (e *AppError) Error() string {
return e.Message
}
func (e *AppError) Unwrap() error { return e.Cause }
这样既能用 errors.Is(err, someErr) 判断错误类型，也能用 errors.As(err, &e) 提取上下文字段。注意：如果嵌套了 Cause，务必实现 Unwrap() 方法，否则 errors.Is 和 errors.Unwrap 无法穿透。
避免在中间件或工具函数里静默忽略错误
典型反模式是写一个通用 JSON 解析函数，内部调用 json.Unmarshal 后直接忽略 err，或只打日志不返回，导致上游完全不知道解析失败——这等于把错误处理责任上交给调用方，但又没暴露任何线索。
- 每个可能失败的操作，其错误必须向上传递，哪怕只是包装一层：
return fmt.Errorf("decode request body: %w", err) - 中间件（如 Gin 的
HandlerFunc）中遇到错误，应调用c.AbortWithStatusJSON并返回，而不是继续执行后续 handler - 日志记录错误时，优先记录
err.Error()而非直接打印err，避免因未实现fmt.Stringer导致输出
错误链（error wrapping）要节制，别层层套娃
Go 1.13 引入的 %w 动词支持错误嵌套，但滥用会导致错误栈过深、日志冗余、调试困难。例如连续五层都用 fmt.Errorf("step X failed: %w", err)，最终错误展开后出现大量重复前缀。
合理使用边界：
- 跨领域边界时 wrap：比如 DAO 层错误传给 service 层，可加业务语义：
fmt.Errorf("create user record: %w", dbErr) - 同层调用一般不 wrap：同一包内函数间传递错误，直接返回更清晰
- 日志或监控上报前，用
errors.Unwrap剥离到最内层原始错误，避免指标统计失真
错误处理不是越“严谨”越好，而是让每个错误值在它该出现的地方被识别、分类、响应。最容易被忽略的是：错误类型的可测试性——如果你的 AppError 字段全是 public，那单元测试里就能构造它做精确匹配；但如果靠字符串匹配 message，一改文案就全挂。
