中间件的本质是拦截器链，需通过统一Handler调度器注入调用前/后逻辑，而非装饰器套壳；应基于自定义ServerCodec在ReadRequestHeader阶段注入context元信息，并用Middleware func(Handler) Handler实现可组合链式调用。
中间件的本质是拦截器链，不是装饰器套壳
Go 的 net/rpc 原生不支持中间件，强行在 Server.Register 前 wrap service 结构体，会导致反射注册失败或方法签名不匹配。真正可行的路径是接管请求分发入口——也就是重写 Server.ServeHTTP 或自定义 Server.ServeCodec。但更轻量、更可控的做法是：把中间件逻辑注入到每个 RPC 方法的执行前/后，即在 handler 层做拦截。
关键点在于：RPC 方法必须统一走一个可插拔的调用入口，不能直接暴露原始方法。这意味着你需要封装一层 HandlerFunc 类型的调度器，并让所有注册的服务方法都通过它被调用。
- 不要试图给
net/rpc打补丁式中间件（比如用reflect.Value.Call包一层再塞回去），它会破坏类型安全和错误传播 - 推荐用
gob或jsonrpc编解码器 + 自定义ServerCodec，把中间件链放在ReadRequestHeader/WriteResponse阶段 - 若用
grpc-go，直接用UnaryInterceptor；但题目明确是“RPC 框架”，默认指自研基于net/rpc的轻量实现
用 Handler 链替代 method 注册，让中间件可组合
核心改动是放弃直接 server.Register(&MyService{})，转而注册一个统一的 Handler，由它负责解析请求、执行中间件、调用真实方法、写回响应。中间件函数签名应为：
type Middleware func(Handler) Handler
其中 Handler 是：
type Handler func(ctx context.Context, req, resp interface{}) error
这样就能用 mw1(mw2(handler)) 串起链式调用。实际使用时，每个服务方法需包装成 Handler：
func (s *MyService) Add(ctx context.Context, req *AddReq, resp *AddResp) error {
*resp = AddResp{Result: req.A + req.B}
return nil
}
<p>// 注册时：
server.Handle("MyService.Add", middleware.Log(middleware.Auth(handlerOf(Add))))
注意：handlerOf 是个辅助函数，把方法签名转换为 Handler 类型，内部处理 reflect 调用和错误提取；中间件本身不应感知 RPC 协议细节，只处理业务上下文与错误。
中间件里访问 RPC 元信息（method name、client addr）要靠 context 透传
net/rpc 的 Request 结构体只在 Server.ServeCodec 内部可见，无法直接传入业务方法。所以必须在 codec 层把 serviceMethod、remoteAddr 等注入 context，再一路向下透传。
- 自定义
ServerCodec时，在ReadRequestHeader后，用context.WithValue把req.ServiceMethod和conn.RemoteAddr().String()存入 ctx - 中间件中用
ctx.Value(key)提取，避免全局变量或闭包捕获 - 不要在中间件里修改
req或resp的字段（除非明确设计为数据转换中间件），否则语义混乱 - 超时控制类中间件（如
Timeout(5 * time.Second)）必须用context.WithTimeout，不能靠time.AfterFunc杀 goroutine
性能陷阱：别在每次 RPC 调用里重复构建中间件链
如果每次 Handle 都写 mw1(mw2(mw3(handler)))，那每来一个请求就新建一次闭包链，GC 压力大且无必要。正确做法是：在服务注册阶段一次性组装好链，缓存为最终的 Handler。
例如：
var h Handler = handlerOf(MyService.Add)
h = Recover(h)
h = Log(h)
h = Metrics(h)
server.Handle("MyService.Add", h) // 只存一个闭包
另外，中间件自身应尽量无状态。像日志中间件，不要在闭包里 hold 一个 *log.Logger 实例再反复赋值，而是直接捕获（capture）已配置好的 logger；鉴权中间件若依赖外部 token cache，应传入接口（如 TokenValidator），而非具体结构体，便于测试 mock。
最易被忽略的是错误处理一致性：所有中间件必须把底层 error 原样返回，或 wrap 成带上下文的新 error（用 fmt.Errorf("xxx: %w", err)），不能静默吞掉或转成 nil——否则上层无法判断是业务失败还是网络中断。
