在Go中，错误包装应有策略地在关键调用边界添加上下文，如服务层或数据访问层，将底层错误转为业务相关描述并保留原始类型以便用errors.Is或errors.As判断，例如fmt.Errorf("failed to load config: %w", err)；需避免重复、过度或无意义的包装，防止错误链冗余。
在Go语言中，包装错误（error wrapping）不是每次都要做的，而是一种有策略的上下文添加方式。核心原则是：当需要为原始错误增加有意义的上下文，并且调用方可能需要访问底层错误时，就应该使用包装。
在关键调用边界添加上下文
当你在一个函数或模块的边界处调用另一个可能会出错的函数时，包装错误可以清晰地说明“在这个环节发生了什么”。
- 将底层的、技术性的错误，包装成与当前业务逻辑相关的描述。例如，把“open config.yml: no such file or directory”包装成“failed to load user config: %w”，让调用者立刻明白问题出在配置加载阶段。- 包含关键参数或状态，比如“process order 12345: %w”，这比单纯的“database query failed”要有用得多。- 在服务层、数据访问层等抽象边界处进行包装，能有效隔离内部实现细节，同时提供足够的诊断信息。需要保留原始错误类型供后续处理
如果上游返回的错误是一个特定类型（如自定义错误、*os.PathError），并且你期望下游或顶层代码能够通过 errors.Is 或 errors.As 来识别和处理它，那么就必须使用包装，而不是创建一个全新的字符串错误。
- 使用 %w 而不是 %v 或 %s 来包装。只有 %w 能建立标准库可识别的包装链，确保 errors.Is 和 errors.As 能够递归地解包并找到目标错误。- 例如，数据库操作返回了 context.DeadlineExceeded，如果你直接返回 fmt.Errorf("db timeout")，顶层代码就无法用 errors.Is(err, context.DeadlineExceeded) 来判断超时。但使用 fmt.Errorf("query timeout: %w", err) 后，这个判断依然有效。避免包装的场景
并不是所有错误都需要包装，无意义的包装反而会污染堆栈和日志。
立即学习“go语言免费学习笔记（深入）”；
- **不要重复包装**：如果一个错误已经被包装过，通常不需要再加一层相同语义的包装。避免出现“failed to X: failed to Y: failed to Z: ...”这样的冗长链条。- **不要在中间件或工具函数中过度包装**：如果一个通用函数（如日志记录、基础校验）只是传递错误，直接返回即可。包装应该发生在业务逻辑的关键节点，而非每一层都加。- **不要为了包装而包装**：如果增加的上下文信息对理解错误没有帮助（例如，“entering function: %w”），那就不如不包装。基本上就这些。合理使用包装能让错误信息既丰富又结构化，关键是把握住“何时”和“为何”要添加这一层。使用 %w 保持错误链完整，并配合 errors.Is 和 errors.As 进行处理，是现代Go程序的标准做法。
