Go 中 error 是返回值而非异常，需显式处理；应避免嵌套 if err != nil，优先用 %w 包装、errors.Is/As 判断，HTTP 错误需脱敏并结构化处理。
Go 里 error 不是异常，别用 try-catch 思维写代码
Go 没有 throw、catch 或 finally，error 是普通接口类型，不是控制流机制。很多人从 Java/Python 转来，下意识想“捕获错误”，结果写出一堆嵌套 if err != nil 还以为是“优雅处理”。
真正该做的是：把错误当返回值处理，像处理 int 或 string 一样自然。函数签名里显式声明它，调用方必须面对它——这不是限制，是强制你思考失败路径。
-
error接口只有Error() string方法，所以自定义错误只需实现这个方法，不用继承任何基类 - 不要在函数里
log.Fatal或os.Exit——这等于把错误处理权抢走，上层无法恢复或重试 - 常见错误：用
fmt.Errorf("failed: %v", err)丢掉原始错误类型和堆栈；应优先用fmt.Errorf("failed: %w", err)（带%w）保留包装关系
什么时候该用 errors.Is，什么时候用 errors.As
Go 1.13 引入的这两个函数，解决的是“怎么判断一个 error 是不是我关心的那种错误”。直接用 == 或 strings.Contains(err.Error(), "...") 都不可靠——前者忽略包装，后者脆弱且无法跨语言本地化。
-
errors.Is(err, fs.ErrNotExist)：判断是否是某个已知错误（或其包装链中的任意一层），适合做“存在性检查”场景，比如文件不存在就创建 -
errors.As(err, &target)：尝试把err解包成具体类型，适合需要访问错误内部字段时，比如解析net.OpError获取Addr字段 - 注意：
errors.As第二个参数必须是指针，传值会 panic；而errors.Is的第二个参数不能是nil，否则行为未定义
自定义错误类型别乱加字段，先想清楚要不要导出
很多人一上来就写 type MyError struct { Code int; Message string; ReqID string }，然后所有地方都 &MyError{...} 返回。问题在于：这些字段是不是真的要暴露给调用方？有没有可能被误用或强依赖？
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 如果只是日志记录或调试用，用
fmt.Errorf("timeout for %s: %w", op, cause)+%w包装更轻量，也不泄露内部结构 - 如果必须结构化（比如 gRPC 错误码映射），字段名尽量小写（不导出），只通过方法暴露必要信息，例如
func (e *myError) Code() int - 别为了“面向对象感”而实现一堆 getter/setter；Go 的错误类型不是用来建模业务状态的，它是失败信号的载体
HTTP handler 里别把 error 直接塞进 http.Error
开发 Web API 时，看到 http.Error(w, err.Error(), http.StatusInternalServerError) 就该警觉。这等于把底层错误细节（比如数据库连接失败、SQL 语法错）全扔给前端，既不安全，也不利于客户端分类处理。
- 应该用中间层统一转换：把底层
error映射为预定义的业务错误码（如ErrUserNotFound），再转成 JSON 响应体 - 开发阶段可保留原始错误（加
X-Debug-Errorheader），生产环境必须脱敏；err.Error()永远不能直接返回给用户 - 别在 handler 里用
log.Printf打印错误就完事——漏掉上下文（如请求 ID、参数）会让排查变成猜谜；建议用结构化日志库（如zap）绑定reqID和err
最常被忽略的一点：错误不是越详细越好，而是要在“可诊断性”和“安全性/抽象层级”之间卡准位置。包装太多层会丢失关键上下文，不包装又难定位根因——得看调用链里谁真正需要知道这个细节。
