gRPC Status 不能直接用 error.Error() 判断，因为其底层是 *status.Status 结构体，需用 status.FromError() 解包并检查 ok；直连时依赖 st.Code() 和 st.Message()，网关场景需解析响应头或使用拦截器；带 details 的错误须用 status.New().WithDetails() 构造，且双方需有对应 proto 定义。
gRPC Status 为什么不能直接用 error.Error() 判断
因为 status.Status 是一个结构体，不是原始 error；你看到的 rpc error: code = NotFound desc = user not found 是它的字符串表示，但底层类型是 *status.Status，直接用 err.Error() 做字符串匹配会崩——既脆弱又无法跨语言兼容。
真正该做的是用 status.FromError() 解包：
if st, ok := status.FromError(err); ok {
switch st.Code() {
case codes.NotFound:
// 处理 404
case codes.InvalidArgument:
// 处理参数错误
}
}
- 必须先
ok检查，否则st是零值，st.Code()返回codes.OK，造成误判 -
status.FromError()对非 gRPC error（比如fmt.Errorf）返回ok=false，安全 - 别用
errors.Is(err, xxx)去比对自定义 error，gRPC 的 status 不实现Is()接口
客户端收到 rpc error 后怎么提取原始 HTTP 状态码和详情
gRPC over HTTP/2 本身没有 HTTP 状态码概念，但很多网关（如 Envoy、grpc-gateway）会把 status.Status 映射成 HTTP 状态码，并在响应头里塞 grpc-status 和 grpc-message。客户端若走网关，需手动解析响应头；若直连 gRPC Server，则只能靠 status.FromError()。
- 直连场景：只信任
st.Code()和st.Message()，它们是协议层定义的语义，稳定 - 网关场景：如果服务端用了
grpc-gateway，它会在响应 header 中写入Grpc-Status（字符串数字）和Grpc-Message，但客户端 SDK 通常不暴露这些 header，得自己封装拦截器或改用http.Client发请求 -
st.Details()能取扩展字段（比如*errdetails.BadRequest），但要求服务端显式调用st.WithDetails()，否则返回空切片
服务端怎么构造带 details 的 Status 并确保客户端能解出来
服务端不能只写 status.Errorf(codes.InvalidArgument, "xxx")，那只会塞进 message 字段，details 是空的。要传结构化错误信息，必须用 status.New().WithDetails()。
立即学习“go语言免费学习笔记（深入）”；
s := status.New(codes.InvalidArgument, "invalid request")
s, _ = s.WithDetails(
&errdetails.BadRequest{
FieldViolations: []*errdetails.BadRequest_FieldViolation{{
Field: "user.email",
Description: "must be a valid email address",
}},
},
)
return s.Err()
-
errdetails包需要单独 import："google.golang.org/genproto/googleapis/rpc/errdetails" - 细节类型必须是 proto 定义的 message，且服务端和客户端都要有对应 pb.go 文件，否则
st.Details()解不出来（类型不匹配） - 如果用了
grpc-gateway，它会自动把errdetails.BadRequest映射成 JSON 的details字段，前端可直接消费
为什么有时 status.FromError() 返回 ok=false，但 err 确实是 RPC 错误
常见于中间件或封装层提前把 *status.Status 转成了普通 error（比如用 fmt.Errorf("rpc failed: %w", err) 包了一层），导致原始类型丢失。此时 status.FromError() 只能解最外层的 error，而它已不是 *status.Status。
- 避免用
%w或%v包装 gRPC error，尤其不要在日志或监控中间件里无差别 wrap - 如果必须包装，用
status.Convert()先转回*status.Status，再构造新 status：status.Convert(err).WithMessage("wrapped") - 测试时可以用
reflect.TypeOf(err).String()快速确认是不是*status.statusError
细节类型不一致、中间件误包、网关与直连混用——这三个点卡住的人最多，而且 debug 时看不出明显报错，只是逻辑走不到预期分支。
