go中error是值而非异常，必须紧跟调用立即检查并return，不可忽略或延迟处理；应使用errors.is/errors.as安全判断，包装错误需判空且慎用%w，固定错误优先用errors.new。
Go 里 error 不是异常，不能“捕获”，必须显式检查、显式返回、显式传递；漏掉 if err != nil 后的 return 或 break，程序大概率会 panic 或逻辑错乱。
为什么 if err != nil 必须紧跟调用且立刻终止执行
因为 Go 的错误是返回值，不是控制流。os.Open 返回 *os.File 和 error，如果忽略 err 直接对 file 调用 Read，而 file 实际是 nil，就会触发 panic: nil pointer dereference。
-
err变量可能被后续同名变量覆盖（比如多个:=声明） - 未检查就继续执行，可能基于无效状态做计算或写入
- HTTP handler 中不提前返回，会导致多次
WriteHeader或响应体冲突
errors.New vs fmt.Errorf：什么时候该用哪个
errors.New 适合固定字符串错误，轻量、安全、支持 errors.Is 精确比对；fmt.Errorf 必须用于带变量的上下文，且优先用 %w 包装底层错误，否则会切断错误链。
- ✅
errors.New("invalid token")—— 无变量，不需格式化 - ✅
fmt.Errorf("failed to parse %q: %w", input, err)—— 有变量 +%w - ❌
fmt.Errorf("failed to parse %q: %s", input, err)—— 用%s会丢失原始类型和堆栈 - ❌
fmt.Errorf("invalid token")—— 多余开销，等价于errors.New却更重
判断特定错误要用 errors.Is / errors.As，别用 == 或字符串匹配
os.IsNotExist(err) 内部调用 errors.Is(err, fs.ErrNotExist)，能穿透多层 %w 包装；而 err == fs.ErrNotExist 在错误被包装后永远为 false，字符串匹配则脆弱且易受格式变更影响。
- 判断是否是“文件不存在”：
os.IsNotExist(err)或errors.Is(err, os.ErrNotExist) - 提取底层
*os.PathError：var pathErr *os.PathError; if errors.As(err, &pathErr) { ... } - 自定义错误要支持
errors.Is，必须实现Unwrap() error方法返回内部错误
panic 只用于不可恢复的编程错误，业务失败一律返回 error
panic 是 goroutine 终止信号，不是错误处理机制。它适用于初始化失败（如配置解析出错且无默认值）、违反基本假设（如 switch 枚举已穷尽却没 default），但绝不该用于 I/O 失败、网络超时、参数校验不通过等常规场景。
- HTTP handler 里遇到
err != nil，应记录日志 + 返回500，而非panic -
init()中panic会直接终止进程，慎用 - 主动
panic("unreachable")可接受，但recover仅作兜底，不能替代业务错误路径
最常被忽略的是：错误包装后，errors.Is 和 errors.As 才真正有用；没加 %w，再复杂的错误判断也白搭。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
