Go语言建议将业务错误作为普通error返回，因其契合“显式错误处理”哲学，使调用方可控决策；业务错误是正常流程分支而非程序崩溃，应避免panic或大一统错误类型，而用errors.Is/As及包装链实现语义化、可扩展的错误处理。
Go语言中建议将业务错误作为普通error返回，核心原因是：它契合Go“显式错误处理”的哲学，让调用方清晰感知、可控决策，而非隐式 panic 或混入异常流——业务逻辑出错不是程序崩溃，而是流程的正常分支。
业务错误 ≠ 程序错误
用户输入手机号格式错误、订单已支付、库存不足、权限被拒绝……这些都不是代码缺陷，而是业务规则下的合理状态。用panic或自定义异常类捕获，反而掩盖了语义，迫使上层用recover兜底，破坏可读性和可维护性。
建议：
• 用errors.New或fmt.Errorf构造带上下文的error
• 避免在业务逻辑里panic("库存不足")
• 不要为每个业务码封装独立类型（如ErrOrderPaid），除非需行为扩展（比如重试判断）
error 是接口，天然支持分类与扩展
Go 的error是接口：type error interface { Error() string }。这意味着你可以：
• 用errors.Is(err, ErrOrderPaid)做语义判断
• 用errors.As(err, &e)提取具体错误类型（适合需携带字段的场景，如ValidationError{Field: "email", Msg: "invalid format"}）
• 包装错误链：fmt.Errorf("failed to process order: %w", err)，保留原始原因
统一错误处理不等于统一错误类型
HTTP handler、CLI命令、gRPC服务等入口处，可以统一拦截error并转成响应码/日志/提示语。但这个“统一”发生在顶层，而非把所有业务错误塞进一个BusinessError{Code: 1001, Msg: "..."} 结构体里。
这样做的好处：
• 底层函数保持轻量，不耦合框架错误模型
• 测试更直接：if err != nil { t.Fatal(err) } 即可验证路径
• 错误消息可含调试信息（开发环境），又可通过包装屏蔽敏感内容（生产环境）
什么时候该用自定义错误类型？
当错误需要携带数据、支持行为、或参与策略判断时才定义类型，例如：
• ValidationError：含Field和Value，供前端精准标红
• TemporaryError：实现Temporary() bool方法，供重试机制识别
• AuthError：嵌入http.StatusUnauthorized，方便中间件自动映射状态码
注意：类型应窄而专，避免大而全的AppError基类——它往往变成“错误垃圾桶”，失去语义精度。
基本上就这些。业务错误回归error，不是妥协，而是把控制权交还给调用方，让错误成为API契约的一部分，而不是隐藏在panic或类型迷雾里的意外。
