Go轻量RPC框架通过统一中间件签名func(context.Context, *rpc.Request, interface{}, func() error) error实现嵌套调用，服务端借ServerCodec注入钩子，客户端封装Do方法支持Before/After回调，全程透传context与error。
go 里实现支持中间件嵌套调用的轻量级 rpc 框架，核心不在于重写 net/rpc，而在于把中间件逻辑注入到请求生命周期的关键钩子点——服务端用 handler 包裹，客户端用 call 前后拦截，且中间件必须能链式传递上下文和错误。
用 func(context.Context, *rpc.Request, interface{}, func() error) error 统一中间件签名
中间件必须可嵌套，就不能依赖固定参数列表。统一用函数类型接收 context.Context、*rpc.Request、响应值指针、以及一个“继续向下执行”的 next 函数。这样每层中间件决定是否调用 next()，还能在前后做日志、鉴权、超时控制等。
常见错误是把中间件写成 func(*rpc.Request) error，导致无法透传 context 或提前终止调用链。
- 所有中间件必须返回
error，以便上层统一处理失败（比如直接返回rpc.ErrShutdown） - 响应值用
interface{}指针接收，避免中间件内部对具体结构体强依赖 -
next()不应暴露底层连接或 codec，只负责触发后续 handler 或实际 RPC 调用
服务端：用 rpc.Server.RegisterCodec + 自定义 ServerCodec 插入中间件链
标准 rpc.Server 不提供 handler 注册钩子，但允许替换 Codec。你可以包装原始 ServerCodec，在 ReadRequestHeader 后、ReadRequestBody 前启动中间件链，在 WriteResponse 前注入后置逻辑。
典型场景是统一加 trace ID、校验 token、限流——这些都得在反序列化请求体前完成，否则可能浪费解析开销。
- 不要在
Register阶段注册中间件，那只是绑定方法名，不参与执行流 - 自定义
ServerCodec必须完整代理原始 codec 的所有方法，漏掉Close会导致连接泄漏 - 中间件链执行顺序 = 注册顺序，前置中间件先执行；若某层返回非 nil error，应跳过
next()并直接WriteResponse错误
客户端：封装 rpc.Client.Call 为 Do 方法并支持 Before/After 回调
客户端没法改 rpc.Client 内部逻辑，所以最轻量做法是包装一层结构体，暴露 Do(ctx context.Context, serviceMethod string, args interface{}, reply interface{}) error，并在其中按序执行 Before 列表（如注入 header）、调用原 Call、再执行 After（如记录耗时）。
容易踩的坑是把中间件写成同步阻塞式重试——这会卡死整个调用，正确做法是在 Before 中设置 ctx 超时，让 Call 自身承担重试语义（或由单独的 retry middleware 处理）。
-
Before可修改args（比如加签名字段），但不能改reply指针本身 -
After接收error参数，用于判断是否成功，避免重复解包 response - 不要在中间件里直接操作
rpc.Client的conn字段——它是未导出字段，且 Go 1.22+ 已标记为 internal
中间件嵌套时 context 传递必须显式透传，不能依赖闭包捕获
多个中间件嵌套时，如果用闭包捕获外层 ctx，会导致超时/取消信号无法向下传递。必须把更新后的 ctx 作为参数传给下一层 next，并在每层中间件开头用 ctx = ctx 显式接收。
例如鉴权中间件生成新 ctx 带 user info，日志中间件就得从这个 ctx 里取，而不是读原始传入的 ctx。
- 每次调用
next(ctx, req, reply, ...)前，确保ctx已被当前中间件增强（如context.WithValue或context.WithTimeout） - 避免在中间件中用
context.Background()创建子 context，会切断取消链 - 调试时打印
ctx.Err()是排查“调用没响应却也不报错”的最快方式
真正难的不是写通中间件链，而是保证每个环节的 error 被正确归因——是 codec 解析失败？还是中间件主动拒绝？还是下游服务无响应？这些 error 类型必须区分清楚，否则运维时根本没法定位是框架问题还是业务逻辑问题。
