Go中错误是值而非异常，需显式检查；应合理包装错误链、避免忽略err、慎用panic、规范自定义错误类型并全面测试错误路径。
Go 中的错误不是异常：error 是一个接口，不是控制流机制
Go 不提供 try/catch，所有错误都必须显式检查。这意味着你不能靠“抛出”跳过后续逻辑，必须用 if err != nil 判断并处理。常见错误是忽略返回的 err，比如写成 json.Unmarshal(data, &v) 而不检查错误，导致解析失败却静默继续——程序可能在后续访问 v 时 panic。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 每个返回
error的调用后，立即判断；不把多个操作链在一行（如a(); b(); c()），否则无法定位哪一步出错 - 不要用
panic处理可预期的错误（如文件不存在、网络超时），只用于真正不可恢复的编程错误（如数组越界、nil 指针解引用） - 使用
errors.Is或errors.As判断错误类型，而不是字符串匹配或直接比较指针
如何包装和传递上下文：用 fmt.Errorf + %w 实现错误链
原始错误（如 os.Open 返回的 *os.PathError）往往缺乏调用上下文。直接返回它，上层很难理解“为什么读配置失败”。Go 1.13 引入了错误包装（wrapping），支持用 %w 将底层错误嵌入新错误中。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
fmt.Errorf("failed to load config: %w", err)包装，而非fmt.Errorf("failed to load config: %s", err.Error())—— 后者会丢失原始错误类型和堆栈线索 - 只有最外层错误需要带堆栈（可用第三方库如
github.com/pkg/errors或 Go 1.22+ 的errors.AddStack），中间层包装不必重复加 - 避免过度包装：同一错误被
%w包装 3 次以上，排查时容易迷失；优先在边界处（如函数入口/出口、模块交界）包装一次并补充语义
何时自定义错误类型：实现 error 接口比字符串更可控
当错误需要携带结构化信息（如错误码、重试建议、HTTP 状态码），或需被程序逻辑分支识别时，应定义结构体错误类型。例如 API 层返回 400 Bad Request，前端需要区分是参数缺失还是格式错误。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 让结构体实现
Error() string方法即可满足error接口；若需额外字段（如Code int），上层可用errors.As断言提取 - 避免为每个小错误都新建类型；共用一个带
Code和Message字段的AppError通常更轻量且足够 - 不要在自定义错误里存敏感数据（如密码、token），日志或监控系统可能自动打印
Error()结果
测试错误路径：别只测 nil 分支，要验证错误内容与行为
很多 Go 单元测试只验证“成功路径”，对错误分支仅检查是否非 nil，这掩盖了错误消息不清晰、包装丢失、类型断言失败等问题。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
testify/assert.ErrorIs或原生errors.Is验证错误是否由特定底层错误包装而来 - 对自定义错误，用
errors.As提取后断言字段值（如assert.Equal(t, wantCode, appErr.Code)） - 模拟 I/O 错误时，别用
errors.New("mock error")，改用&os.PathError{Op: "open", Path: "config.json", Err: syscall.ENOENT}，这样能真实触发标准库的错误判断逻辑
错误处理不是加一堆 if err != nil 就完事。关键在于：错误是否可诊断、是否可恢复、是否被正确传播。最容易被忽略的是错误链的完整性——从 syscall 层一路透出到 HTTP handler，中间每层是否保留了足够的上下文，又没引入冗余包装。这需要在每次 %w 前停半秒想想：这里真的需要加一层语义吗？
