go rpc 不支持 context 传递，因 net/rpc 方法签名固定为 func(args, reply) error，无法注入 context.context；grpc 原生支持 context，自动透传 deadline、cancel 和 value；若坚持用 net/rpc，需手动透传关键字段并模拟超时检查，但无法真正实现 cancel 传播。
Go RPC 本身不支持 context 传递
标准库 net/rpc 是 Go 1.0 就存在的老协议，它没有设计 context 集成机制——所有方法签名固定为 func(*Args, *Reply) error，无法塞入 context.Context 参数。强行改签名会导致服务端/客户端不兼容，直接 panic。
这意味着：如果你用原生 net/rpc，context.WithTimeout、context.WithCancel 这些在调用层设置的上下文，**根本不会传到服务端**，超时、取消、traceID 都会丢失。
常见错误现象：
- 客户端设置了 5s 超时，但服务端卡死 30s 才返回，客户端早已放弃，却收不到任何通知
- ctx.Value("trace_id") 在服务端始终是 nil
- 使用 rpc.Client.Go 启动异步调用后，cancel context 无法中断正在传输的请求
用 gRPC 替代 net/rpc 是最直接的方案
gRPC 原生基于 HTTP/2，每个 RPC 方法签名天然支持 context.Context 作为第一个参数，服务端能完整继承客户端的 deadline、cancel signal 和 value。
迁移要点：
- 用 protoc + grpc-go 生成 stub，方法形如 func(ctx context.Context, req *Req) (*Resp, error)
- 客户端调用时直接传入带 timeout 的 context：ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
- 服务端可安全读取：reqID := ctx.Value("request_id") 或检查 ctx.Err() == context.DeadlineExceeded
- 不需要额外序列化 context 数据，HTTP/2 header 自动携带 grpc-timeout 和 grpc-encoding
性能影响几乎为零：gRPC 默认使用 Protocol Buffers，比 net/rpc 的 Gob 更紧凑；HTTP/2 多路复用也比 TCP 上串行 RPC 更高效。
如果必须用 net/rpc，context 只能手动透传
你得把 context 中的关键字段（如 timeout、trace_id、user_id）显式提取出来，塞进 *Args 结构体，并在服务端手动重建轻量 context。
实操建议：
- 在 Args 中增加字段：DeadlineUnixNano int64、TraceID string、UserID string
- 客户端填充：args.DeadlineUnixNano = time.Now().Add(5 * time.Second).UnixNano()
- 服务端还原：ctx := context.WithValue(context.Background(), "trace_id", args.TraceID)
- 超时需手动检查：if time.Now().UnixNano() > args.DeadlineUnixNano { return errors.New("deadline exceeded") }
- ⚠️ 注意：无法实现真正的 cancel 传播（比如客户端断连，服务端收不到通知），只能靠轮询或 channel 配合定时器模拟
这种做法绕过了 RPC 协议层，属于“应用层 context 模拟”，维护成本高，且容易漏掉 cancel 场景。
别忽略 transport 层对 context 的支持边界
即使用了 gRPC，context 的生命周期也只覆盖到 server handler 入口。如果 handler 内部启动 goroutine 做异步处理（比如发消息到 Kafka、写日志到磁盘），那个 goroutine **不会自动继承父 context**，必须显式传入并监听 ctx.Done()。
典型坑点：
- go func() { doHeavyWork() }() —— 完全脱离 context 控制
- 正确写法：go func(ctx context.Context) { select { case <br>
- 第三方库（如 <code>database/sql、redis/go-redis）是否支持 context，要查文档确认；不支持的库调用会阻塞整个 handler，让 context 超时失效
真正难的不是“怎么传 context”，而是“传下去之后，每一层是否真的响应了它”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
