Go用error接口而非异常处理错误，强调明确性、可控性和简洁性；error接口仅含Error() string方法，支持errors.New、fmt.Errorf和自定义实现；强制显式检查err，控制流清晰且不可忽略；推荐用errors.Is/As等值语义判断错误，避免panic滥用。
Go 用 error 接口而非异常机制处理错误，核心是**明确性、可控性和简洁性**——错误不是意外，而是函数正常行为的一部分，必须被调用者显式检查。
error 接口极简，但足够表达所有错误语义
error 接口只定义了一个方法：Error() string。这种设计避免了类型爆炸和继承复杂性，任何能返回描述性字符串的类型都能成为 error。比如：
- 内置的
errors.New("xxx")返回一个不可变的字符串错误 -
fmt.Errorf("failed: %w", err)支持错误链（Go 1.13+），保留原始错误上下文 - 自定义结构体只要实现
Error() string就是合法 error，还能附带码、时间、字段等额外信息
显式错误处理强制开发者面对失败路径
Go 不允许忽略返回值（尤其当变量名是 err 时，静态检查工具如 errcheck 会报警）。这迫使你在每个可能出错的调用后写 if err != nil，而不是依赖 try/catch 的“兜底”幻觉。好处是：
- 控制流清晰：成功路径和错误路径分离，无隐式跳转
- 错误处理不被遗忘：没有 catch 块就等于没处理，编译期无法绕过
- 可组合性强：多个函数串联时，错误自然向上传递，无需层层 re-throw
错误值可比较、可判断、可包装，不依赖 panic
Go 鼓励用值语义判断错误（如 os.IsNotExist(err)、errors.Is(err, io.EOF)、errors.As(err, &e)），而不是靠类型断言或字符串匹配。这带来：
- 稳定兼容：底层错误类型变化不影响上层判断逻辑
- 语义准确：区分“是否是某类错误”和“是否等于某个具体错误”
- 避免滥用 panic：panic 仅用于真正不可恢复的程序错误（如空指针解引用），不是常规错误处理手段
基本上就这些——Go 的 error 接口不是妥协，而是对“错误即数据”的坚定选择：它轻量、透明、可组合，把责任交还给程序员，也让代码更易读、易测、易维护。
