error 是接口而非关键字，需显式检查；必须用 if err != nil 判断，禁用 if err 或 _ 忽略；推荐 errors.New、fmt.Errorf（%w 包装）和谨慎自定义结构体；优先用 errors.Is/errors.As 判定错误，避免字符串匹配；包装错误应精简，仅入口层加必要上下文。
error 是接口，不是关键字，必须显式检查
Go 里 error 是一个内建的接口类型（type error interface { Error() string }），不是异常、不自动抛出、也不隐式中断流程。你写 json.Unmarshal(data, &v)，哪怕解码失败，程序照常往下跑——但 v 可能是零值或部分填充的脏数据，后续 panic 或逻辑错乱往往就从这里开始。
- 永远用
if err != nil判断，不能写if err（error是接口，不支持布尔转换） - 绝不要用
_忽略err，除非你 100% 确认那个函数在当前上下文**不可能返回非 nil 错误**（比如fmt.Sprintf） - 错误检查要“fail fast”：出错立刻处理或返回，别堆一堆逻辑再回头查
创建 error 的三种常用方式：errors.New、fmt.Errorf、自定义结构体
简单场景用 errors.New；带变量或上下文就用 fmt.Errorf；只有当你需要调用方法（如 IsTimeout()）或被 errors.As 提取时，才定义结构体。
-
errors.New("file not found")→ 纯字符串错误，轻量、够用 -
fmt.Errorf("failed to parse %s: %w", filename, io.ErrUnexpectedEOF)→ 唯一推荐的包装方式，%w保留底层错误链 - 自定义结构体要谨慎：90% 的业务错误不需要新类型；过度封装反而让
errors.Is失效、增加测试负担
判断和提取错误：用 errors.Is 和 errors.As，别比字符串
靠 strings.Contains(err.Error(), "no such file") 判断错误类型是反模式：脆弱、不可移植、无法跨包复用。标准库和主流生态都依赖 errors.Is 和 errors.As 做语义化判定。
-
errors.Is(err, os.ErrNotExist)→ 检查错误链中是否存在目标错误（支持多层包装） -
errors.As(err, &pathErr)→ 尝试把错误链里某个节点赋给*os.PathError这类具体类型，方便读取pathErr.Path等字段 - 别自己实现
IsXXX()方法再手动遍历Unwrap——errors.Is已帮你做了
包装错误时只加一层上下文，别层层套娃
常见错误是每层都 fmt.Errorf("layer X: %w", err)，结果错误链拉得又长又没用："HTTP handler: service call: db query: read file: permission denied"。真正有用的只有最外层上下文 + 最内层根因。
立即学习“go语言免费学习笔记（深入）”；
- 入口层（如 HTTP handler）加一次上下文就够了：
fmt.Errorf("create user: %w", err) - 中间层（如 service）通常直接返回，或仅补充关键信息（如请求 ID）：
fmt.Errorf("create user %s (req=%s): %w", userID, reqID, err) - 底层（如 db、io）不包装，直接返回原始错误，留给上层决定怎么处理
最易被忽略的一点：错误链不是用来“展示深度”的，而是为了精准判定和调试。你写的每一层 %w，都要问一句——这层信息是否真的影响下游的决策逻辑？如果不是，那就别包。
