gRPC拦截器拿不到认证信息的根本原因是客户端未正确传递metadata或服务端解析方式错误：客户端须用metadata.Pairs("authorization", "Bearer xxx")，服务端须用metadata.FromIncomingContext(ctx)获取；Streaming接口必须用StreamServerInterceptor且每次消息都重新鉴权；token解析失败应返回status.Error而非panic；k8s环境常见header被ingress或Istio剥离，需检查基础设施配置。
gRPC拦截器里拿不到 context.Context 中的认证信息？
多数人卡在这一步：在 UnaryServerInterceptor 或 StreamServerInterceptor 里调用 ctx.Value(...) 返回 nil。根本原因不是拦截器写错了，而是客户端压根没把 token 放进 metadata.MD，或者放的位置不对。
实操建议：
- 客户端必须用
metadata.Pairs("authorization", "Bearer xxx")（注意 key 全小写，gRPC 会自动转成 HTTP header 格式） - 服务端拦截器里要用
metadata.FromIncomingContext(ctx)拿元数据，不能直接ctx.Value - 如果用了
grpc.WithBlock()或连接池复用，记得每次 RPC 调用都重新传metadata，它不跨请求继承
鉴权逻辑该放在 UnaryServerInterceptor 还是 StreamServerInterceptor？
取决于你的接口类型。Unary 接口（比如 Login、GetUser）走 UnaryServerInterceptor；Streaming 接口（比如 SubscribeLog、ChatStream）必须用 StreamServerInterceptor，否则鉴权只在流建立时触发一次，后续消息不校验。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 在 Unary 拦截器里鉴权了，但 Streaming 接口完全没拦，导致未授权客户端能建连并收发消息
- 把鉴权逻辑写在 stream 的
Recv或Send里 —— 这属于业务层，不是拦截器职责，且性能差、易漏判 - 两个拦截器共用同一份鉴权函数，但忘了 streaming 场景下
ctx是随每个消息更新的，需每次重新解析 metadata
token 解析失败时，该返回 status.Error 还是直接 panic？
必须返回 status.Error，且状态码要准确：codes.Unauthenticated（无有效 token）、codes.PermissionDenied（token 有效但权限不足）。gRPC 客户端靠这个做重试或跳转登录页，panic 会导致整个 server goroutine 崩溃，影响其他请求。
参数差异与兼容性影响：
- 别用
fmt.Errorf包装错误，gRPC 客户端收不到标准 status —— 必须用status.Errorf(codes.XXX, "msg") - 如果鉴权依赖外部服务（如 Redis、Auth Service），超时控制要显式设置，避免拦截器阻塞太久拖垮整个 RPC 链路
- Go 1.21+ 对 context deadline 更敏感，建议在拦截器开头就检查
ctx.Err() != nil，提前退出
为什么加了拦截器，本地测试通过但 k8s 环境里总报 UNAUTHENTICATED？
大概率是 ingress 或 service mesh（比如 Istio）剥离或改写了 authorization header。k8s 默认不透传自定义 header，尤其带下划线或大小写混用的 key。
排查路径：
- 在拦截器最开头加日志：打印
md := metadata.MD(ctx.Value(grpcmd.MDKey{}).(metadata.MD))，确认原始 metadata 是否到达 - 检查 ingress controller 配置，确保
enable-underscores-in-headers: "true"（Nginx）或对应 header 白名单已开 - Istio 用户注意：
Authorizationheader 默认被 sidecar 过滤，需在EnvoyFilter或Sidecar资源中显式放行authorization
复杂点在于，header 丢失发生在 gRPC 连接建立前，拦截器甚至收不到上下文。这种问题没法在 Go 代码里修，得查基础设施配置。
