go rpc中间件链统一建模为func(context.context, interface{}) (interface{}, error)，通过倒序包装实现m1→m2→m3→handler执行；服务端注册需绑定方法级中间件列表，客户端需确保链末端为真实rpc调用；所有跨中间件通信必须通过context.value且key为未导出struct。
中间件链如何用 func(context.Context, interface{}) (interface{}, error) 统一建模
Go 的 RPC 中间件本质是函数式拦截，核心在于统一输入输出签名。必须让所有中间件接受 context.Context 和原始请求体，返回响应体或错误——这样才可嵌套调用。不强制要求中间件修改请求/响应结构，但若需透传元数据（如 traceID），必须通过 context.WithValue 传递，不能靠闭包捕获外部变量，否则并发下会错乱。
常见错误：把中间件写成 func() func(...) 形式再闭包捕获配置，看似灵活，实则在链式拼接时无法动态注入 context 或做 cancel 控制。正确做法是中间件本身接收 context.Context，由最外层调用方控制生命周期。
- 中间件函数签名必须固定为
func(context.Context, interface{}) (interface{}, error) - 链式执行时，后一个中间件的入参是前一个的返回值，因此必须确保类型兼容（通常用
interface{}向上兼容） - 不要在中间件里直接调用
next()多次，也不要在 defer 中无条件调用——这会导致重复执行或 panic 捕获失效
Server.RegisterService 如何绑定中间件链到具体方法
注册服务时不能只存 handler 函数，得同时存中间件列表。建议在服务注册结构体中加一个 Middleware []MiddlewareFunc 字段，而不是全局中间件池——不同服务、甚至同一服务的不同方法可能需要不同拦截逻辑（比如 Login 方法要鉴权，Health 方法则跳过）。
实际调用时，框架需将原始 handler 封装进链尾：把 handler 当作“最终 next”，然后从右往左依次包装。例如中间件数组为 [m1, m2, m3]，则执行顺序是 m1 → m2 → m3 → handler，拼接逻辑应类似：
fn := handler
for i := len(middlewares) - 1; i >= 0; i-- {
next := fn
fn = func(ctx context.Context, req interface{}) (interface{}, error) {
return middlewares[i](ctx, req, next)
}
}
- 注意遍历顺序：倒序遍历才能保证 m1 最先被调用
- 中间件内部调用
next(ctx, req)前，可修改req；返回后可修改响应或 error，但别直接改req指针内容——调用方可能复用结构体 - 如果某个中间件决定短路（如鉴权失败直接返回 error），就不要调用
next，这是合法且常用的做法
客户端侧如何复用同一套中间件模型
服务端中间件处理的是「收到请求→调用 handler→返回响应」，客户端中间件则是「构造请求→发出去→收响应→返回给调用方」。两者签名可以一致，但语义不同：req 是你要发的数据，next 是真正的网络调用函数（如 client.Call）。所以客户端中间件链必须在发起 RPC 前组装好，且 next 必须是能真正触发网络 I/O 的闭包。
典型陷阱：把服务端中间件直接挪到客户端用，结果 next 被当成普通函数调用而没发请求。必须确保客户端链末端是真实 RPC 调用，且该调用已绑定目标地址、编解码器等上下文。
- 客户端中间件也用
func(context.Context, interface{}) (interface{}, error)，但实现里next必须是带完整调用参数的函数（如func(ctx context.Context, method string, args, reply interface{}) error） - 不要在中间件里解析
reply结构体字段——那是业务逻辑，中间件只负责透传或打日志、埋点、重试 - 超时控制必须在最外层中间件设置
context.WithTimeout，否则底层next可能永远阻塞
为什么不用 net/rpc 默认机制而要自己封装链
net/rpc 自带的 Server.RegisterCodec 或 Server.ServeConn 都不提供方法级拦截点。它只允许你在连接建立、消息编解码层面插钩子，没法针对某个 service.method 插入日志、熔断、指标采集等逻辑。想做到 per-method 中间件，必须绕过原生 dispatch，自己实现 serviceMap 查找 + handler 包装。
另一个现实约束：net/rpc 的 Call 接口返回 *rpc.Call，不是 error，导致中间件难以统一错误处理路径。换成自定义 client 接口（如 Invoke(ctx context.Context, method string, args, reply interface{}) error），才能让中间件链自然融入 error 流程。
- 别试图 patch
net/rpc.Server的未导出字段（如serviceMap），Go 不支持反射修改私有结构 - 如果用 gRPC，直接用
grpc.UnaryInterceptor更省事；但纯 net/rpc 场景下，必须自己维护 method → middleware chain 映射表 - 链式调用的性能损耗极小（就是几次函数调用），但调试时容易迷失在哪一层 panic —— 建议中间件统一加
defer func() { if r := recover(); r != nil { log.Printf("middleware panic: %v", r) } }()
中间件链本身不难写，难的是让服务端和客户端共享同一套语义、同一套错误传播方式，同时不破坏 context 的 cancel 和 timeout 传递。最容易被忽略的是：中间件之间不该共享状态，所有跨中间件通信必须走 context.Value，且 key 类型必须是 unexported struct，避免冲突。
