PHP实现RPC框架真正难点在于协议边界处理（需长度前缀防粘包）、序列化一致性（强制数组解码、规避资源/闭包）、反射调用安全隔离（白名单校验、禁用魔术方法、参数数量验证）及Swoole协程上下文管理（避免状态共享、禁用阻塞调用）。
PHP 实现 RPC 框架不是“写个 socket 就完事”，真正卡住人的地方是协议边界、序列化一致性、以及服务端反射调用时的上下文隔离。不处理好这三点，本地跑通了，一上生产就丢包、错参、超时或直接 segfault。
socket_read 读不到完整 JSON？得自己管消息边界
原生 stream_socket_server 和 stream_socket_client 不带帧头，socket_read 可能一次只读到半条 JSON，也可能拼上两条——这就是典型的粘包问题。
- 别依赖
\n或\0当分隔符：客户端若传的参数含换行（比如用户昵称是 "小明\n"），服务端会提前截断 - 必须加长度前缀：在 JSON 前写 4 字节网络序 int 表示 body 长度，服务端先读 4 字节，再按该长度读取完整 payload
- 客户端发送前要
pack('N', strlen($json)) . $json，服务端用unpack('Nlen', stream_socket_recvfrom($client, 4))拿长度 - 超时必须设：用
stream_set_timeout($client, 5)，否则一个坏连接会卡死整个服务端循环
json_encode/json_decode 不能直接当序列化方案用
PHP 的 json_encode 默认不处理资源、闭包、私有属性；json_decode 默认返回 stdClass，不是数组，反射调用方法时参数类型会崩。
- 服务端接收后必须用
json_decode($raw, true)强制转数组，否则call_user_func_array传参失败 - 客户端发参前检查是否可 JSON：用
json_last_error() === JSON_ERROR_NONE验证，避免空字符串或 NaN 导致静默失败 - 别传
DateTime对象：它会被转成空对象{}，应统一转为 ISO8601 字符串并约定服务端解析逻辑 - 敏感字段（如 token）建议在传输层加密，JSON 本身不防窥探
反射调用方法前，必须做服务名+方法名白名单校验
直接 new $serviceClass + call_user_func_array 是高危操作：攻击者可构造 {"service":"ReflectionClass","method":"__construct","params":["phpinfo"]} 触发任意类实例化。
立即学习“PHP免费学习笔记（深入）”；
- 所有可暴露的服务类必须继承统一基类（如
AbstractRpcService），并在服务注册时显式声明允许的方法列表 - 服务端路由层查表匹配：
isset($this->allowedMethods[$service][$method])，不命中直接返回 403 - 禁止通过反射访问 private/protected 方法，只允许 public 方法，且方法名不能含双下划线（防止调用
__destruct等魔术方法） - 参数数量也要校验：
count($params) !== $refMethod->getNumberOfParameters()，少传或多传都拒掉
Swoole 协程下要注意 $this 上下文丢失
用 Swoole\Coroutine\Server 启动时，每个请求在一个协程中运行，但如果你在服务类里存了连接池、缓存句柄等状态，不同请求会互相污染。
- 不要在服务类属性里存
$this->pdo或$this->redis：协程间共享，A 请求 close 掉连接，B 请求再用就报错 - 改用
go(function () { $db = new PDO(...); /* 用完即弃 */ });或从协程本地存储（Co::getUid()+ 全局数组）拿单例 -
Swoole\Http\Server和Swoole\Coroutine\Server的回调签名不同：前者是function ($request, $response)，后者是function ($server, $fd, $from_id, $data)，混用会 crash - 协程内禁止阻塞调用：如
sleep(1)、file_get_contents，必须换成co::sleep和Co\Http\Client
真正难的不是把一次调用跑通，而是让上百个服务节点之间长期稳定交换数据——边界定义不清、序列化不一致、反射没过滤、协程状态乱，任何一个点松动，都会在凌晨三点把你叫醒。
