应使用 errors.Is 和 errors.As 替代字符串匹配判断错误类型，自定义错误需实现 Unwrap；统一错误包装和日志到中间层函数；用 defer + 命名返回值收敛清理逻辑；对可恢复错误分层处理，明确错误域边界。
用 errors.Is 和 errors.As 替代字符串匹配判断错误类型
直接用 err.Error() == "xxx" 或 strings.Contains(err.Error(), "...") 判断错误，是 Go 初期常见但脆弱的做法。一旦底层错误消息变更（比如加了空格、翻译、上下文字段），逻辑就失效，且无法跨包可靠识别错误本质。
正确做法是用标准库提供的类型感知工具：
-
errors.Is(err, fs.ErrNotExist)用于判断是否为某个哨兵错误（如文件不存在） -
errors.As(err, &target)用于提取包装后的具体错误类型（如从fmt.Errorf("read failed: %w", io.EOF)中还原出io.EOF） - 自定义错误必须实现
Unwrap() error方法才能被正确展开
把重复的错误包装和日志统一收口到中间层函数
在每个 if err != nil 分支里都写一遍 log.Printf("failed to xxx: %v", err) 或 return fmt.Errorf("xxx: %w", err)，会导致日志格式不一致、上下文丢失、错误链断裂。
建议定义一个轻量错误处理辅助函数，例如：
立即学习“go语言免费学习笔记（深入）”；
func wrapErr(op string, err error) error {
if err == nil {
return nil
}
return fmt.Errorf("%s: %w", op, err)
}
调用时统一为：return wrapErr("parse config", cfg.Load())。这样既保留原始错误链，又让所有错误带上操作语义，后续集中处理（如监控告警按 op 聚类）也更方便。
Node.js 可靠编程技能。避免事件循环阻塞、异步陷阱、ESM 兼容问题和内存泄漏。触发词：Node.js 开发、async/await、流处理、性能优化、安全编码。
用 defer + named return 避免函数末尾重复检查
当一个函数内多个步骤可能返回错误，而你又需要在返回前统一做清理（如关闭文件、释放锁），容易写出冗余的 if err != nil { return err } 多次判断。
利用命名返回值 + defer 可以把错误检查收敛到一处：
func processFile(path string) (err error) {
f, err := os.Open(path)
if err != nil {
return // err 已命名，此处直接返回
}
defer func() {
if closeErr := f.Close(); closeErr != nil && err == nil {
err = closeErr
}
}()
// ... 其他逻辑，出错直接 return
return
}
注意：只有当 err 仍为 nil 时才用 closeErr 覆盖，避免掩盖主逻辑错误。
对已知可恢复错误提前分类，避免全链路透传
不是所有错误都需要层层向上抛。比如 HTTP handler 中遇到 json.UnmarshalTypeError，应立即转成 400 Bad Request 并返回，而不是一路 %w 包装到顶层再判断。
典型模式是「就近处理可理解的错误」：
- 数据库层：遇到
sql.ErrNoRows→ 转成业务语义的user.NotFoundError - HTTP 层：收到
user.NotFoundError→ 返回 404；收到validation.Error→ 返回 422 - 顶层 main 函数只处理未预期 panic 或基础设施错误（如配置加载失败）
这种分层拦截会让错误路径更短，也减少无意义的 if err != nil 嵌套。关键是定义清晰的错误域边界——哪些错误属于当前层职责，哪些必须上抛。
