该用 errors.new 而非 fmt.errorf 当错误信息是固定字符串时，因其更轻量、安全且支持 errors.is 精确比对；含变量时须用 fmt.errorf 并优先用 %w 保留错误链。
什么时候该用 errors.New，而不是 fmt.Errorf
当错误信息是固定字符串、不带任何动态变量时，errors.New 是更轻量、更安全的选择。它直接返回一个不可变的 error 实例，没有格式化开销，也不会意外引入空格或拼写错误。
-
errors.New("connection refused")—— 简单、高效、可被errors.Is精确比对 -
fmt.Errorf("connection refused")—— 多余：做了字符串解析却没用上格式能力 - 如果要带变量（比如端口号、用户ID），必须用
fmt.Errorf，但记得优先用%w而非%s保留错误链 - 误写
fmt.Errorf("failed to read %s: %s", path, err)会切断原始错误类型和堆栈；应改为fmt.Errorf("failed to read %s: %w", path, err)
如何让自定义错误支持 errors.Is 和 errors.As
自定义结构体错误默认不参与错误链遍历，errors.Is 和 errors.As 只能匹配最外层——除非你显式实现 Unwrap() 方法。
- 没实现
Unwrap：即使嵌套了os.ErrNotExist，errors.Is(err, os.ErrNotExist)也返回false - 必须返回一个
error类型值，通常是字段里存的底层错误：func (e *MyError) Unwrap() error { return e.cause } - 如果错误可能多层嵌套（比如 A 包 B 包 C），只需每层都实现
Unwrap，errors.Is会自动递归向下查 - 注意：
errors.Unwrap只解一层，且对nil输入会 panic，别直接裸调
panic 不是错误处理，而是程序“断电”信号
Go 里 panic 的定位非常明确：它表示当前 goroutine 已无法继续执行，不是“换个方式重试”的错误，而是“停机检修”的异常。把它当 try/catch 用，是 Go 新手最常踩的抽象错位。
- 适合场景：空指针解引用、数组越界、向已关闭 channel 发送数据——这些本不该发生，发生了说明逻辑或状态有严重缺陷
- 不适合场景：文件不存在、网络超时、数据库连接失败——这些是常态，应该走
error返回路径 -
recover只在defer中有效，且仅对同 goroutine 的panic生效；HTTP handler 顶层加 recover 是常见兜底，但不能替代业务错误检查 - 主动
panic("unexpected state")可以，但别用它替代log.Fatal或控制流；一旦 panic，堆栈已展开，性能代价远高于 if err != nil
为什么总在 if err != nil 后忘记 return 或 break
这不是语法错误，而是逻辑断裂点。Go 的错误检查依赖开发者手动终止后续执行，编译器不会帮你拦住“带病运行”的代码路径。
- 典型现象：检查了
err，打印了日志，但没return，接着往下用未初始化的变量或空指针，结果 panic 报错位置和真实问题隔了三层 - 推荐写法：用卫语句（guard clause）前置退出，保持主干逻辑缩进浅、可读性强：
if err != nil { return err } - 在循环里尤其危险：
for range中遇到错误只log.Print不break或continue，可能重复触发下游 panic - 工具辅助：启用
staticcheck的SA5011规则，能自动发现“检查了 err 却没处理”的漏网之鱼
if err != nil 都老老实实给个交代。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
