gRPC服务端一元拦截器需严格匹配grpc.UnaryServerInterceptor签名，末尾必须调用handler(ctx, req)，否则业务逻辑不执行；鉴权失败应返回status.Error(codes.Unauthenticated, ...)而非直接panic，且metadata键名须小写。
gRPC 拦截器不是开箱即用的“插件”，而是必须显式注册的函数；服务端用 grpc.UnaryInterceptor，客户端用 grpc.WithUnaryInterceptor，漏掉任一环节拦截器都不会生效。
服务端一元拦截器怎么写才不 panic？
签名必须严格匹配 grpc.UnaryServerInterceptor 类型，否则编译通过但运行时会 panic —— 因为 handler 可能为 nil 或未被调用。
- 务必在函数末尾调用
handler(ctx, req)，否则业务逻辑永远不会执行 - 不要在拦截器里直接 return 错误（如权限拒绝），应先处理再调用 handler，让错误自然透出或 wrap 后返回
- 如果需要提前终止请求（如鉴权失败），仍要调用
handler并返回自定义 error，否则 gRPC 会返回INTERNAL而非你期望的UNAUTHENTICATED - 示例中常见错误：在 defer 里读取
resp或err，但它们是 handler 返回值，defer 执行时还未赋值 —— 应把日志逻辑放在handler调用之后
客户端拦截器如何安全注入 metadata？
metadata.AppendToOutgoingContext 是唯一推荐方式；直接修改 context.Value 或伪造 metadata map 会导致传输失败或被 server 端忽略。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- token 过期、空值、拼写错误（如
"Authorization"写成"authorization"）都会导致认证失败，建议加一层非空校验 - 多个拦截器叠加时（如 auth + retry + log），顺序很重要：
grpc.WithUnaryInterceptor(auth, retry, log)表示 auth 最外层，log 最内层 - 注意
invoker必须被调用一次且仅一次，重复调用或跳过会导致连接卡死或 panic - 超时控制应在拦截器外通过
context.WithTimeout设置，而非在拦截器里重设 ctx —— 否则可能覆盖上游已设的 deadline
为什么流式拦截器比一元更难调试？
因为 grpc.StreamServerInterceptor 和 grpc.StreamClientInterceptor 不直接暴露请求/响应体，你拿到的是 ServerStream / ClientStream 接口，原始数据被封装在内部缓冲区里。
- 想记录流式请求内容，必须包装
ServerStream实现自定义RecvMsg/SendMsg方法，再把包装后的 stream 传给handler - 流式拦截器无法像一元那样用 defer 统计耗时 —— 流可能持续数分钟，start/end 时间点需靠消息事件驱动
- gRPC 官方不提供
StreamInterceptor的链式组合工具，go-grpc-middleware库的ChainStreamServer是事实标准，不用它容易写错生命周期管理 - 常见报错
"stream terminated by RST_STREAM"往往源于拦截器里未正确透传SendMsg或RecvMsg错误
拦截器里最常被忽略的上下文传递问题
所有中间件操作都依赖 context 透传，但 gRPC 的 metadata.FromIncomingContext 和 metadata.FromOutgoingContext 对大小写和 key 格式极其敏感。
- server 端读 metadata 时，key 必须小写（
"x-request-id"可以，"X-Request-ID"会被忽略） - client 端写 metadata 时，若 value 是二进制数据（如 JWT payload），需加后缀
"-bin"，否则 gRPC 会尝试 UTF-8 解码并失败 - 跨拦截器传递自定义字段（如 traceID）不能用
context.WithValue随意塞 interface{}，应统一用 typed key，避免类型断言 panic - 日志中打印 context deadline 或 cancel reason 时，别只看
ctx.Err()，要结合status.FromError(err)判断是否真是 context canceled
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
