grpc拦截器在c#中需显式注册：服务端必须对bindservice()结果调用.intercept()，客户端须包装channel或注入callinvoker；不支持di自动注入；上下文仅通过servercallcontext/clientinterceptorcontext传递；流式调用需单独实现对应拦截方法。
gRPC拦截器在C#中不是“加个装饰器就生效”的魔法机制，它依赖明确的注册时机和调用链位置。服务端拦截器必须通过.Intercept()显式挂载到服务实例上；客户端拦截器则必须包装Channel或注入CallInvoker，否则完全不会触发。
服务端拦截器必须用.Intercept()挂载到BindService()结果上
很多人把拦截器当成中间件往IServiceCollection里注册，结果日志一条没打——服务端拦截器不走DI生命周期，也不参与ASP.NET Core中间件管道。它只在gRPC服务绑定阶段生效。
-
BindService()返回的是ServerServiceDefinition，这是一个不可变对象，必须立刻用.Intercept(new MyInterceptor())生成新实例 - 直接对
UserService.BindService(instance)结果不做.Intercept()调用，等于没注册 - 多个拦截器按顺序传入
.Intercept()：例如.Intercept(new AuthInterceptor(), new LoggingInterceptor())，先鉴权、再记日志 - 如果使用
Grpc.AspNetCore.Server（即ASP.NET Core托管模式），仍需在Program.cs中手动调用.Intercept()，框架不会自动扫描Interceptor类型
客户端拦截器不能靠DI注入，必须包装Channel或重写CallInvoker
客户端拦截器最容易踩的坑是试图把它注册进IServiceCollection然后期待自动生效。gRPC C#客户端没有“全局拦截器容器”，所有拦截逻辑必须绑定到具体Channel或CallInvoker实例上。
- 正确做法：用
ChannelIntercepted包装原始Channel，再用它创建stub：var channel = new ChannelIntercepted(originalChannel, new[] { new LoggingInterceptor() }); var stub = GreeterClient.Create(channel); - 错误做法：把
LoggingInterceptor注册为Singleton并期望某处自动调用——它根本不会被触发 - 若使用
Grpc.Net.Client（基于HttpClient的实现），则必须自定义DelegatingHandler链，在HttpClientHandler外层插入逻辑，此时已不属于gRPC原生Interceptor体系 -
AsyncUnaryCall()里不能直接awaitresponse，必须返回AsyncUnaryCall<tresponse></tresponse>包装对象，否则会破坏gRPC的取消传播和上下文传递
ServerCallContext和ClientInterceptorContext是唯一可信的上下文来源
别从ThreadLocal、静态字段或AsyncLocal里捞请求信息。gRPC跨线程/异步边界时，只有这两个上下文对象能可靠携带元数据、截止时间、取消令牌和请求头。
- 服务端读取header必须用
context.RequestHeaders，不是HttpContext.Request.Headers（后者在Grpc.AspNetCore.Server中为空） - 客户端注入token应通过
context.Options.CallOptions.WithHeader("auth-token", token)，而非修改ClientContext后丢弃 -
ServerCallContext.Peer可获取真实客户端IP，但需确保反向代理（如Nginx）透传X-Forwarded-For并配置UseForwardedHeaders()，否则拿到的是代理IP - 在
try/catch中捕获异常后，若想统一返回Status(StatusCode.PermissionDenied, "xxx")，必须throw new RpcException(...)，不能仅return空响应
流式调用（streaming）的拦截器要单独重写对应方法
一元调用（unary）的UnaryServerHandler和AsyncUnaryCall对流式RPC完全无效。客户端和服务端各有三类流式方法，必须显式覆盖：
- 服务端：重写
ClientStreamingServerHandler（如上传文件）、ServerStreamingServerHandler（如日志尾部）、DuplexStreamingServerHandler（如聊天） - 客户端：对应重写
AsyncClientStreamingCall、AsyncServerStreamingCall、AsyncDuplexStreamingCall - 流式调用中无法像一元调用那样简单
await continuation()，需手动管理IAsyncStreamReader和IAsyncStreamWriter的生命周期，尤其注意DisposeAsync()调用时机，否则可能泄漏连接 - 日志或鉴权逻辑若只放在一元方法里，遇到
rpc StreamData(stream DataRequest) returns (stream DataResponse)这类定义就会彻底失效
最常被忽略的一点：拦截器里的异常如果不显式throw，而是吞掉或return default，会导致gRPC底层静默失败，客户端收到StatusCode.Unknown且无详细消息——调试时得翻gRPC日志级别到Debug才能看到真正原因。
