Swoole做RPC需闭环整合协程、协议设计、连接管理与错误传播：不能直接用SwooleClient（同步阻塞、无连接池、无请求ID绑定）；必须基于协程Socket+Channel实现长连接与请求分发；需处理TCP粘包（固定头+循环读取）；协程上下文须用Co::getContext()透传；超时需服务端主动中断；服务注册发现为必选项，至少用Redis心跳实现。
面试里聊到Swoole做RPC，千万别以为考官只是让你启动个 SwooleServer 就完事了。真正的考点是——你能不能把「协程调度、协议设计、连接管理、错误传播」这几块拼图完整地串起来，形成一个闭环落地方案。
为什么不能直接用 SwooleClient 做 RPC 客户端
不少同学一上来就写 $client->connect() + $client->send()，压测脚本里跑跑没问题，但一上生产场景立马露馅：
SwooleClient是同步阻塞模型，recv()一调用就卡住当前协程，高并发下大量协程挂起，吞吐量直接掉到地板- 没内置连接池，每次调用都得新建TCP连接，资源开销大不说，还容易把端口池搞爆，满屏
TIME_WAIT - 自动重试？没有。超时控制只支持全局
timeout，颗粒度太粗。出错了到底是网络抖了一下还是服务真的挂了？根本分不清 - 最关键的是，它没有请求ID绑定机制——多个并发请求同时发出，返回时根本不知道哪个响应对应哪个请求，这就是“请求-响应”上下文缺失的尴尬
真正能用的客户端，得基于 SwooleCoroutineHttpClient 或者自己封装 SwooleCoroutineSocket，手动维护长连接，再用协程 Channel 做请求分发。这一步省不了。
onReceive 回调里必须处理粘包和半包
TCP 是纯流式协议，onReceive 收到的数据长度完全不可控——运气好一次来一个完整请求，运气不好两个请求挤在一起，或者一个请求被切成三截。不处理粘包，解析必然翻车。
- 必须定义固定长度的消息头，比如前4字节存 body 长度，先读够头部，再按长度读 body
- 别傻傻地用
strlen($data)判断是否收全——要用socket_recv循环读取直到凑够长度 - 协程环境下推荐
SwooleCoroutineSocket::recv()配合unpack('N', $header)解包，这样不会阻塞整个 worker - 如果用 JSON 协议，千万不能直接
json_decode($data)——数据没收完就 decode，百分百返回null，而且没有任何错误提示，排查起来让人抓狂
协程上下文丢失是 RPC 最隐蔽的坑
RPC 调用链里经常需要透传 trace_id、用户身份、超时时间等上下文，但 PHP 协程切换时，全局变量、静态属性、$_SERVER 都不会自动继承。这个坑，不踩一次你根本意识不到。
Co::getContext()和Co::setContext()是唯一靠谱的方式——收到请求时存进去，调用业务逻辑之前取出来，一步都不能乱- 别在服务端方法里直接读
$_SESSION或$_COOKIE——TCP RPC 里根本就没有 HTTP 上下文，读出来只能是空 - 超时控制不能只靠客户端
recv()超时：服务端业务逻辑如果卡死（比如 DB 死锁），必须用Co::sleep()+Co::cancel()主动中断，否则那个协程就永久占着不放了 - 日志打点一定要带上协程 ID（
Co::getuid()），不然所有请求日志混在一起，根本没法定位
服务注册与发现不是加分项，是必选项
面试官如果说“手写一个 RPC”，默认考的是可运行的最小闭环。没有注册中心的 RPC 就是硬编码 IP+端口，上线即失效，谁用谁头疼。
- 最低成本方案：用 Redis 的
SET key value EX 30 NX做服务心跳注册，KEYS rpc:service:*做临时发现（注意线上别用 KEYS，可以用 SCAN 替代） - 客户端首次调用前必须拉取一次服务列表，后续用定时
GET检查存活，而不是每次调用都去查 Redis——那样性能太差 - 别把服务发现逻辑写死在客户端代码里——要抽象成
RegistryInterface接口，方便以后换成 Etcd 或 Nacos - 负载均衡策略至少实现轮询（RoundRobin）和随机（Random），权重配置可以先不写，但接口要预留
weight字段，方便后续扩展
真正难的不是写通一条调用链，而是让几十个服务节点在动态扩缩容、网络分区、进程重启时，依然能维持正确的服务寻址和流量分发——这个意识，比代码本身更重要。
