grpc拦截器需通过grpc.unaryinterceptor/grpc.streaminterceptor显式注册：server端传入grpc.newserver()，client端用grpc.withunaryinterceptor/grpc.withstreaminterceptor；须注意单拦截器限制、ctx传递、耗时统计时机、req/resp类型安全处理、panic/cancel日志丢失及ip获取限制。
gRPC拦截器函数怎么注册到Server和Client
Go 的 gRPC 框架本身不内置拦截器，得靠 grpc.UnaryInterceptor 和 grpc.StreamInterceptor 这两个选项显式传入。Server 端注册时直接塞进 grpc.NewServer() 的 opts 参数里；Client 端则是在 grpc.Dial() 时用 grpc.WithUnaryInterceptor 或 grpc.WithStreamInterceptor 包一层。
注意：Server 只能注册一个 unary 拦截器（多次传 grpc.UnaryInterceptor 会覆盖），所以如果要用多个逻辑（比如先鉴权再打日志），得自己写个链式调用的 wrapper，或者用第三方库如 grpc-middleware。
常见错误现象：context deadline exceeded 突然变多，很可能是拦截器里没正确传递 ctx，比如忘了用 ctx, cancel := context.WithTimeout(...) 后又没 defer cancel()，或者把原始 ctx 丢掉了。
- Server 注册示例：
grpc.NewServer(grpc.UnaryInterceptor(yourUnaryInterceptor)) - Client 注册示例：
grpc.Dial(addr, grpc.WithUnaryInterceptor(yourClientInterceptor)) - 拦截器函数签名必须严格匹配：
func(ctx context.Context, req interface{}, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (resp interface{}, err error)
如何在拦截器里准确统计请求耗时
耗时统计不是简单套个 time.Now().Sub() 就完事——关键在于「起始时间点」要选对。必须在调用 handler 前打点，否则会漏掉拦截器自身开销（比如 JWT 解析、日志序列化）；结束时间点必须在 handler 返回后立即记录，不能等到 defer 执行，否则可能被 panic 中断或受 recover 影响。
更稳妥的做法是用 time.Now() 打起点，然后用 defer 包一层匿名函数做终点计算，但要确保这个 defer 在 handler 调用之后才注册（即写在 handler 调用语句后面）。
性能影响：高频服务下，每次请求都新建 time.Time 和格式化字符串（如 fmt.Sprintf）会带来 GC 压力。建议用 time.Since() 避免中间变量，日志输出前判断阈值（比如只记 >100ms 的请求）。
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
- 错误写法：
start := time.Now(); defer log.Printf("cost: %v", time.Since(start))—— defer 在函数入口就注册，耗时包含拦截器初始化 - 正确写法：
start := time.Now(); resp, err := handler(ctx, req); cost := time.Since(start) - 可加采样控制：
if cost > 100*time.Millisecond { log.Warnf("slow req: %s, cost: %v", info.FullMethod, cost) }
拦截器中获取请求参数与响应结果的注意事项
unary 拦截器的 req 和 resp 是 interface{} 类型，不能直接打印或结构体断言——因为 proto 编译生成的 struct 名带包路径（如 pb.LoginRequest），而拦截器不知道具体类型。硬转会 panic，尤其当多个 service 共用一个拦截器时。
安全做法是用反射或 proto.Message 接口做泛化处理：先判断 req 是否实现了 proto.Message，再用 proto.MarshalJSON() 序列化（注意控制长度，避免日志爆炸）；响应同理，但要注意 err != nil 时 resp 通常是 nil，别直接解包。
敏感字段（如密码、token）必须脱敏。不要依赖前端传来的字段名做判断，而应基于 proto 的 json_name 或自定义 option 标记（比如加 (redact) = true），否则容易漏脱敏或误删。
- 推荐检查方式：
if msg, ok := req.(proto.Message); ok { data, _ := protojson.MarshalOptions{EmitUnpopulated: true}.Marshal(msg) } - 避免直接
fmt.Printf("%+v", req)—— 可能触发无限递归（含嵌套 message 或 map） - 审计日志建议固定字段：
method（info.FullMethod）、status（err == nil）、cost_ms、client_ip（从peer.FromContext(ctx)提取）
为什么日志审计总漏掉 panic 或 context canceled 请求
拦截器函数本身是个普通 Go 函数，如果 handler 内部 panic，且没被上层 recover，整个 goroutine 会终止，defer 不执行，你写的日志就丢了。同样，客户端主动 cancel（ctx.Done()）后，handler 可能提前返回 context.Canceled，但此时你若还在做耗时操作（比如写磁盘日志），反而拖慢请求释放。
根本解法不是在拦截器里 try-catch，而是利用 gRPC 的 Recovery 拦截器（如 grpc_recovery）兜底；对于 cancel 场景，日志动作必须是非阻塞的——写入内存 buffer 或发到 channel 由后台 goroutine 异步刷出，而不是同步调用 log.Printf。
另一个隐形坑：gRPC 的 UnaryServerInfo 里没有 client 真实 IP，peer.FromContext(ctx) 拿到的是连接层地址，经 nginx 或 k8s service 后通常是 cluster IP。得靠 X-Real-IP 或 X-Forwarded-For 头，但这需要你在拦截器之前就解析并注入 ctx，属于前置中间件职责，不是拦截器该干的活。
- panic 场景下，唯一可靠日志位置是
grpc_recovery的回调函数 - cancel 场景下，优先记录
err == context.Canceled，而非尝试打印 resp - 审计日志的可靠性永远低于监控指标（如 Prometheus 的
grpc_server_handled_total），别拿它当唯一依据
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
