优雅处理错误的核心是让错误可识别、可传播、可诊断；需正确使用 errors.Join、%w、errors.Is 和 errors.As，避免字符串拼接丢失类型与堆栈，确保自定义错误实现 Unwrap，并为批量操作添加上下文以支持精准定位。
Go 函数里“优雅处理错误”，核心不是让代码看起来更短，而是让错误可识别、可传播、可诊断。用对 errors.Join、%w、errors.Is 和 errors.As 这几个工具，比写一堆 fmt.Errorf("xxx: %v", err) 强得多。
什么时候该用 errors.Join 而不是字符串拼接
当你需要一次性返回多个独立错误（比如批量操作中多个子任务失败），且调用方后续可能要判断其中是否含某个特定错误类型时，必须用 errors.Join。
- 手动拼接如
fmt.Errorf("a: %v; b: %v", errA, errB)会丢失原始 error 类型和堆栈，errors.Is(err, os.ErrPermission)一定返回false -
errors.Join(errA, errB, errC)返回的 error 支持递归Unwrap，errors.Is和errors.As会自动遍历所有子错误 - 传入
nil会被自动忽略，不用提前过滤；全为nil时返回nil，语义干净 - 反模式：在
defer中反复err = errors.Join(err, stepErr)—— 容易因初始err是nil导致第一次后变成非nil，后续又覆盖或重复加入
%w 包装错误时，为什么必须确保原始 error 实现 Unwrap
只有被 %w 包装的 error 才能被 errors.Is 和 errors.As 向下穿透识别。否则，包装层就像一堵墙，拦住了所有判断逻辑。
- 标准库错误（如
os.ErrNotExist）和用fmt.Errorf(... %w ...)构造的 error 都自带Unwrap方法 - 自定义错误类型若想支持穿透，必须显式实现
Unwrap() error，并返回嵌入的底层 error 字段（不能只返回nil或硬编码值） - 只存字符串字段（如
Msg string）的自定义 error，哪怕实现了Error()，也无法被errors.As提取结构体，等于放弃诊断能力
errors.Is 和 errors.As 不是万能钥匙，别滥用
这两个函数专为跨包/跨层的错误分类设计，不是为了替代 if err != nil 这种基础检查。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
-
errors.Is(err, fs.ErrNotExist)适合判断标准哨兵错误；但errors.Is(err, errors.New("not found"))永远失败 —— 每次errors.New都是新实例 -
errors.As(err, &target)只在你需要读取自定义错误的字段（比如Code或Field）时才用；对普通字符串错误强行套用，纯属增加心智负担 - 单个函数内部做简单分支（如 “文件不存在就创建”），直接
if os.IsNotExist(err)更轻量，不必绕一圈errors.Is
批量操作出错时，怎么保留每个错误的上下文
errors.Join 解决的是“有哪些错误”，但不告诉你“哪个步骤出了什么错”。真要区分来源，得自己加一层包装。
- 不要只收集
[]error然后errors.Join—— 丢失了 key 或 index 信息 - 推荐：定义带上下文的错误类型，例如
type StepError struct { Step string; Err error }，再实现Unwrap() error返回Err - 这样既能用
errors.Join聚合，又能通过errors.As提取出StepError并访问Step字段，定位到具体失败项 - 如果只是临时调试，用
fmt.Errorf("%s: %w", stepName, err)也行，但注意这会让errors.Is失效 —— 因为没用%w包装，只是字符串插值
最常被忽略的一点：错误处理的“优雅”不在于语法多简洁，而在于当线上服务报出 failed to join errors: permission denied 时，你能不能 30 秒内从日志里看出是哪个文件、哪个 goroutine、哪个权限位出了问题。所有包装、聚合、判断，都得服务于这个目标。
