Go中错误是显式返回的接口而非异常，需用error接口、%w包装、errors.Is/As判断，避免panic滥用、忽略Close错误及重复日志。
Go 中的错误不是异常，error 是一个接口
Go 不支持 try/catch，所有错误都通过返回 error 值显式传递。这意味着你不能“忽略”错误——编译器不会报错，但逻辑可能在静默中失败。error 接口只定义了一个方法：Error() string，所以任何实现了该方法的类型都可以作为错误返回。
常见误区是用 panic 处理本应返回 error 的场景（比如文件不存在、网络超时）。panic 应仅用于真正不可恢复的程序状态（如 nil 指针解引用、数组越界），而非业务错误。
- 函数签名中必须显式声明
error返回值，例如：func Open(name string) (*File, error) - 不要用
fmt.Errorf("something failed")丢掉原始错误上下文；优先用fmt.Errorf("wrap: %w", err)保留底层错误链 - 自定义错误类型应实现
Unwrap() error和Is(error) bool（如果需支持errors.Is或errors.As）
用 errors.Is 和 errors.As 替代字符串匹配
过去常有人写 if strings.Contains(err.Error(), "no such file") 来判断错误类型——这脆弱且易破。Go 1.13 引入了错误包装（%w）和标准判断工具，让错误处理可维护。
errors.Is(err, fs.ErrNotExist) 判断是否为某类预定义错误；errors.As(err, &pathErr) 尝试将错误解包并赋值给具体类型变量，比类型断言更安全（能穿透多层包装）。
- 只有用
%w包装的错误才可被errors.Is/errors.As正确识别 -
标准库中的 I/O 错误（如
os.PathError）、网络错误（如net.OpError）都支持这些操作 - 避免在中间层无意义地重 wrap：比如
return fmt.Errorf("read config: %w", err)合理，但return fmt.Errorf("failed: %w", err)无信息增量
不要在 defer 中直接调用带副作用的 Close() 而不检查错误
很多 Go 新手写 defer f.Close() 就以为万事大吉。但 Close() 可能返回非 nil 错误（尤其写入缓冲未刷盘、网络连接提前断开等），而 defer 中的错误会被丢弃。
