C++ gRPC如何编写拦截器（Interceptor）记录请求调用日志-C++-PHP中文网

gRPC C++拦截器必须继承grpc::experimental::Interceptor并重写Intercept方法，不能用函数或lambda；需通过InterceptedChannel（客户端）或ServerBuilder::AddInterceptor（服务端）注册，且须过滤健康检查路径避免影响探针。

c++ grpc如何编写拦截器（interceptor）记录请求调用日志

gRPC C++ 拦截器必须继承 `grpc::experimental::Interceptor` 类

gRPC C++ 的拦截器不是通过装饰器或配置注册的，而是需要手动实现一个继承自 grpc::experimental::Interceptor 的类，并重写 Intercept 方法。这个类会在每次 RPC 调用时被实例化（除非使用 InterceptorFactory 控制生命周期），所以不能在类内保存跨调用的状态。

常见错误是试图直接实现一个普通函数或 lambda 作为拦截器——这在 C++ 版本中完全不被支持；也有人误以为继承 grpc::ClientInterceptorFactoryInterface 就够了，其实它只负责创建拦截器实例，真正干活的是 Interceptor 子类。

必须包含头文件 #include
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）辅助追踪。

不要尝试在 HOOK_POINT_SEND_MESSAGE 中 cast message 参数为具体 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。

C++14

C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。

下载

解决方案是在拦截器开头快速过滤掉非业务方法：

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，且顺序影响执行链（多个拦截器按添加顺序从前到后执行）。

典型漏配场景：