error 是 go 内建接口类型，定义为 type error interface { error() string }，不可用 == 比较，应使用 errors.is/as；推荐 errors.new 和 fmt.errorf（含 %w）创建错误，避免手动构造指针或忽略错误传播。
error 是接口，不是类型别名
Go 里 error 是一个内建的接口类型，定义为 type error interface { Error() string }。它不是 string，也不是指针或结构体——这意味着你不能直接用 == 比较两个 error 值是否“相等”，也不能假设它有某个字段可访问。
常见错误现象：if err == errors.New("xxx") 看似能工作，但实际每次调用 errors.New 都返回新对象，地址不同，比较结果恒为 false（除非恰好被编译器优化或复用，但不可依赖）。
- 要用
errors.Is(err, target)判断是否是某个已知错误（比如包装过的、带上下文的） - 要用
errors.As(err, &target)提取底层具体错误类型（如*os.PathError） - 自定义错误时，别只实现
Error()就完事；如果需要参与语义判断，得让类型支持Is()或Unwrap()
不要在函数里 new 错误再 return，优先用 errors.New 或 fmt.Errorf
errors.New("failed to open file") 和 fmt.Errorf("open %s: %w", path, err) 是标准做法。手写 &myError{msg: "..."} 不仅冗余，还容易漏掉 Unwrap() 导致错误链断裂。
使用场景：大多数业务逻辑错误、参数校验失败、IO 失败等，都该走这俩函数生成错误值。
-
errors.New适合静态、无参数的错误描述 -
fmt.Errorf加%w动词才能正确包装（不加就是字符串拼接，丢失原始错误） - 避免
fmt.Errorf("something: %v", err)—— 这会把err.Error()当字符串塞进去，原始类型和堆栈全丢
error 返回必须检查，但不是所有地方都要 if err != nil { return err }
Go 的错误处理哲学是“显式传播”，但不是机械套用。重点在于：当前函数是否能处理这个错误？还是只能记录、转换、或终止流程？
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
常见错误现象：在 defer 中忽略 Close() 的返回值，或在循环里遇到第一个 err 就 return，导致后续资源没清理、批量操作提前中断。
- IO 类型操作（如
file.Close()）建议用if cerr := file.Close(); cerr != nil && err == nil { err = cerr }方式合并错误 - 批量处理时，收集错误（如用
errs := []error{}）比一错就退更合理 - 日志打点后仍要 return 错误，否则调用方无法感知失败 —— 不要只
log.Printf就继续往下跑
panic 不是 error，别混用
panic 是运行时崩溃信号，error 是控制流的一部分。把本该返回 error 的情况写成 panic，会让调用方失去选择权（比如重试、降级、兜底），也破坏了 Go 的错误显式性原则。
性能 / 兼容性影响：recover 成本高，且无法跨 goroutine 传播 panic；而 error 可以安全地传参、返回、序列化、记录。
- 仅在真正“程序无法继续”时用 panic：比如配置加载失败且无默认值、全局单例初始化失败
- HTTP handler 里不要 panic 后指望中间件 recover —— 应该统一用
return err+ 统一错误响应格式 - 测试中用
assert.NoError(t, err)比defer func(){...}()捕获 panic 更清晰、更符合 Go 风格
最容易被忽略的是错误的“所有权”：谁创建，谁负责包装或解释；谁接收，谁决定是否终止或重试。一旦把 error 当作可忽略的返回值，或者当成必须立刻 panic 的灾难，就偏离了它的设计本意。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
