gRPC C++拦截器必须继承grpc::experimental::Interceptor并重写Intercept方法，不能用函数或lambda；需通过InterceptedChannel（客户端）或ServerBuilder::AddInterceptor（服务端）注册，且须过滤健康检查路径避免影响探针。
gRPC C++ 拦截器必须继承 grpc::experimental::Interceptor 类
gRPC C++ 的拦截器不是通过装饰器或配置注册的，而是需要手动实现一个继承自 grpc::experimental::Interceptor 的类，并重写 Intercept 方法。这个类会在每次 RPC 调用时被实例化（除非使用 InterceptorFactory 控制生命周期），所以不能在类内保存跨调用的状态。
常见错误是试图直接实现一个普通函数或 lambda 作为拦截器——这在 C++ 版本中完全不被支持；也有人误以为继承 grpc::ClientInterceptorFactoryInterface 就够了，其实它只负责创建拦截器实例，真正干活的是 Interceptor 子类。
- 必须包含头文件
#include <grpcpp></grpcpp> -
Intercept方法接收grpc::experimental::InterceptionHookPoints枚举和一个grpc::experimental::InterceptedMethod对象，后者提供对 call、context、request/response 的访问入口 - 日志记录逻辑应放在
HOOK_POINT_SEND_INITIAL_METADATA（客户端）或HOOK_POINT_RECV_INITIAL_METADATA（服务端）等关键钩子点，而非无差别塞在所有钩子里
客户端拦截器如何获取方法名和请求参数
客户端拦截器中，方法名藏在 context->method()，但原始请求消息（如 protobuf 对象）**无法在拦截器中直接反序列化**——因为此时数据还在 buffer 阶段，尚未被解析。强行解析需复制 buffer 并调用 ParseFromArray，但会带来性能开销和线程安全风险。
更稳妥的做法是：仅记录元信息（method、host、deadline、peer、timestamp），必要时用 context->client_metadata() 提取自定义 header（如 x-request-id）辅助追踪。
立即学习“C++免费学习笔记（深入）”；
- 不要尝试在
HOOK_POINT_SEND_MESSAGE中 castmessage参数为具体 protobuf 类型——它的类型是const void*，且生命周期极短 - 若真需结构化请求内容，应在业务层打日志，或改用服务端拦截器 +
Deserialize钩子（但仍有拷贝成本） - 推荐记录字段：
context->method()、context->host()、context->deadline()、std::chrono::system_clock::now()
服务端拦截器怎么避免影响 gRPC 健康检查和探针请求
gRPC 服务端拦截器默认对所有 RPC 生效，包括 /grpc.health.v1.Health/Check 和 /grpc.reflection.v1.ServerReflection/ServerReflectionInfo 这类管理接口。如果日志逻辑里有同步 I/O（如写磁盘、发 HTTP 请求）或未捕获异常，会导致健康检查失败，进而被 k8s 误判为 crashloop。
解决方案是在拦截器开头快速过滤掉非业务方法：
if (context->method().find("/grpc.") == 0 || context->method().find("/envoy.") == 0) {
// 直接放行，不记录
return;
}
- 注意
context->method()返回的是完整路径字符串，格式为/package.Service/Method - 避免用正则匹配，简单
find或starts_with（C++20）即可，减少 CPU 开销 - 若启用了 TLS，
context->auth_context()可用于区分内部调用与外部调用，但别在拦截器里做复杂鉴权
拦截器注册后没生效？检查 Channel 和 Server 的构造方式
客户端拦截器必须通过 grpc::experimental::InterceptedChannel 包装原始 Channel，否则完全不会触发；服务端拦截器则需在 ServerBuilder 中显式调用 AddInterceptor，且顺序影响执行链（多个拦截器按添加顺序从前到后执行）。
典型漏配场景：
- 写了拦截器类，但忘记在
ServerBuilder中调用builder.AddInterceptor(std::make_unique<mylogginginterceptor>())</mylogginginterceptor> - 客户端用了
grpc::CreateChannel，却没套一层grpc::experimental::InterceptedChannel - 服务端用了
RegisterService后才调用AddInterceptor—— 实际上必须在BuildAndStart()前完成注册 - 拦截器对象被提前析构（比如
unique_ptr生命周期管理错误），导致后续调用 crash
最易忽略的一点：拦截器工厂（InterceptorFactory）返回的拦截器实例，其析构时机由 gRPC 内部控制，不要在里面持有裸指针或依赖全局单例状态。
