Go 的 error 是接口而非具体类型，以便支持扩展性、上下文携带和类型区分；任何实现 Error() string 方法的类型均可赋值给 error，编译器强制“声明即实现”。
Go 的错误处理机制不是异常捕获，而是“显式值传递”——error 是一个接口，函数通过多返回值把错误当普通值返回，调用方必须主动检查 err != nil 才算完成错误处理。
为什么 error 是接口，而不是具体类型？
因为 Go 要求错误可扩展、可携带上下文、可区分类型。只要实现 Error() string 方法，任何结构体、指针甚至基础类型都能成为错误值。
-
标准库的
errors.New("msg")返回的是未导出的*errors.errorString，它只提供字符串信息 - 自定义错误（如
*DivideError）能带字段（Dividend,Divisor），方便下游做类型断言或逻辑分支 - 不实现接口的类型无法被赋值给
error变量，编译器强制你“声明即实现”
errors.New 与 fmt.Errorf 怎么选？
两者都返回 error 接口值，但语义和能力不同：
-
errors.New("xxx")：适合固定、无参数的错误消息，开销最小 -
fmt.Errorf("xxx %d", n)：适合带动态内容的错误，但默认会丢失原始错误类型 -
fmt.Errorf("wrap: %w", err)：加%w动词才能包装错误链，后续可用errors.Unwrap()或errors.Is()判断
err := fmt.Errorf("read config failed: %w", os.ErrNotExist)
if errors.Is(err, os.ErrNotExist) { // ✅ 成立
// 处理文件不存在
}
函数签名里 error 为什么总放在最后？
这是 Go 社区强约定，不是语法要求，但违反它会带来三个实际问题：
- 调用时无法用短变量声明一次性接收所有返回值：
a, b, err := fn()要求err是最后一个，否则编译报错 - IDE 和 linter（如
revive）会警告，影响代码审查通过率 - 其他开发者读你函数时，默认 expect
error在末尾；放中间会导致误判返回值含义（比如把int, error, bool当成int, bool成功路径）
最容易被忽略的坑：忽略 err 或只 log 不处理
写 _, err := doSomething(); log.Println(err) 看似“处理了”，实则等于没处理——程序继续往下跑，可能触发 panic 或数据损坏。
- 正确做法是：检查
err != nil后，立刻决定是 return、retry、fallback 还是 panic - 不要用
_ = err或if err != nil { }空分支来“跳过”错误 - 在 defer 中关闭资源时，也要检查
Close()的返回值（如file.Close()可能因 flush 失败而返回 error）
错误不是日志的附属品，它是控制流的一部分；Go 把错误当值，就意味它必须参与分支决策，不能只打个印就完事。
