status.Errorf 返回 error 而非 status.Status 是因 gRPC 方法签名要求，其内部封装 status.Status；必须用 status.FromError 解包获取状态码和详情，不可类型断言。
status.Errorf 为什么返回的不是 *status.Status 而是 error
因为 gRPC 的 RPC 方法签名要求返回 error 类型，而 status.Errorf 的设计目标就是快速构造一个带状态码和消息的 error 实例，内部包装了 *status.Status。它不是直接暴露状态对象，而是走标准错误路径——这点常被误认为“没法取状态码”，其实可以反解。
-
status.Errorf返回的是实现了status.Error接口的私有结构体，不是裸指针 - 客户端收到后，用
status.FromError(err)才能还原出*status.Status - 直接类型断言
err.(*status.Status)会失败，这是最常见的一处 panic 来源
怎么从 error 提取 gRPC 状态码和详情
必须用 status.FromError 解包，不能靠类型断言或反射硬抠。这个函数是唯一安全入口，它处理了封装、nil、非 status 错误等多种情况。
- 成功时返回
ok == true，s.Code()是标准码（如codes.NotFound） - 如果传入普通
errors.New("xxx")，ok为false，s.Code()默认是codes.Unknown - 带详细信息（如
details）时，需额外调用s.Details()，注意返回的是[]interface{}，要类型断言
if st, ok := status.FromError(err); ok {
log.Printf("gRPC code: %v, msg: %s", st.Code(), st.Message())
}
status.Errorf 的参数顺序和 codes 值怎么选才不踩坑
status.Errorf 第一个参数是 codes.Code，第二个是格式化字符串，后面是可变参数——顺序错或传 int 代替 codes.Code 会导致静默转成 codes.Unknown。
- 别写
status.Errorf(3, "not found")，必须用codes.NotFound这类常量 -
codes.Internal和codes.Unknown不等价：前者表示服务端出错，后者表示无法识别的错误类型 - 客户端重试逻辑通常只对
codes.Unavailable或codes.Aborted生效，codes.InvalidArgument重试没意义 - HTTP 映射关系要心里有数：比如
codes.PermissionDenied→ HTTP 403，codes.Unauthenticated→ 401
自定义错误详情（details）怎么加进 status 并让客户端拿到
仅靠 status.Errorf 无法塞入 details，必须用 status.New + WithDetails 组合。否则客户端调用 s.Details() 永远是空切片。
立即学习“go语言免费学习笔记（深入）”；
-
status.New(codes.InvalidArgument, "bad ID").WithDetails(&errdetails.BadRequest{...})才有效 - 所有 detail 类型必须实现
protoreflect.ProtoMessage，通常是 proto 生成的 struct - 客户端收到后，
s.Details()返回的是原始 proto message 切片，需逐个类型断言，例如v.(*errdetails.BadRequest) - 细节数据不参与 gRPC 错误码判断，只用于携带上下文，别指望靠它触发重试或 fallback
s := status.New(codes.InvalidArgument, "invalid field")
s, _ = s.WithDetails(&errdetails.BadRequest_FieldViolation{
Field: "email",
Description: "must contain @",
})
return s.Err()
gRPC 状态码不是装饰，它是跨语言、跨网络的语义契约。写错一个 codes 常量，下游可能把 404 当成 500 处理；漏掉 status.FromError 这一层解包，就永远拿不到真实码值。这些地方没有报错提示，只有行为偏差。 
