Go RPC底层不支持非阻塞套接字，因net.Conn默认全阻塞且强行修改会破坏状态机；真正轻量关键在减少序列化开销、复用连接、避免goroutine泄漏，而非追求非阻塞。
非阻塞套接字在 Go RPC 底层中不直接可用
Go 的 net.Conn 接口本身不暴露“设置为非阻塞”的能力——底层文件描述符是否阻塞，由 net.Listen 创建 listener 时的系统调用决定，而 Go 标准库默认全部使用阻塞式 socket。你无法像 C 或 Rust 那样调用 fcntl(fd, F_SETFL, O_NONBLOCK) 来切换；即使通过 syscall 强行修改，也会破坏 net.Conn 内部的读写状态机（比如 bufio.Reader、io.ReadFull 等依赖阻塞语义），导致 panic 或数据错乱。
想实现“超轻量 RPC 底层”，该绕开阻塞还是绕开 Go 标准 net？
真正轻量的关键不是“非阻塞”，而是减少序列化开销、避免 goroutine 泄漏、跳过 HTTP 头和中间件。标准 net/rpc + gob 已经足够轻，但它的 Client.Call 是同步阻塞的；若想并发发多个请求又不卡住主线程，正确做法是启动 goroutine + channel 回收结果，而非折腾 socket 非阻塞：
-
client.Go("Service.Method", args, reply, done)是标准库提供的异步入口，它内部仍用阻塞 conn，但把等待逻辑移到 goroutine 中 - 不要自己封装
read/write循环去模拟非阻塞——Go 的 runtime netpoll 已经为你做了 epoll/kqueue 封装，你只需按需启 goroutine - 若真要极致轻量（比如嵌入式或高频金融场景），应换用自定义二进制协议 +
encoding/binary+io.ReadFull，而非追求“非阻塞”这个伪需求
为什么有人误以为需要非阻塞 socket？
常见触发点其实是以下三类问题，它们和 socket 是否阻塞无关：
- 客户端调用
client.Call后整个 goroutine 卡住 → 实际是服务端没响应或网络断开，应设http.Client.Timeout（HTTP 模式）或用net.DialTimeout（TCP 模式） - 大量并发请求压垮服务端 → 问题出在服务端 handler 未做限流或未用
context.WithTimeout，跟 socket 模式无关 - 想让服务端“发完响应就不管了”，实现类似 webhook 的反向回调 → 这需要客户端暴露可被公网访问的 HTTP 端点，和 socket 阻塞/非阻塞完全不相关
真正影响 RPC 轻量级的三个实操细节
比起纠结非阻塞，这三点更值得检查：
立即学习“go语言免费学习笔记（深入）”；
- 编码器选
gob还是json？gob更快但仅限 Go；json可跨语言但解析慢 3–5 倍，且必须用net/rpc/jsonrpc（注意：它只支持 TCP，不支持 HTTP） - 服务端注册时是否用了
rpc.RegisterName("MySvc", svc)？默认注册名是结构体名（如*Rect），容易因包路径变化导致客户端调用失败 - 客户端连接是否复用？
rpc.Dial("tcp", addr)返回的*rpc.Client是线程安全的，可被多个 goroutine 共享；反复Dial会创建大量连接，触发 TIME_WAIT
所谓“超轻量”，本质是协议头够短、编解码够快、连接够复用、错误路径够清晰——而不是强行把阻塞接口改造成非阻塞接口。后者在 Go 里既不可靠，也无必要。
