Webman不能直接用Router处理/graphql请求，因其onMessage或中间件仅接收原始Request对象，而GraphQL协议硬性要求统一POST到单路径、JSON格式含query字段等，若按REST式路由分发则丧失字段级按需能力。
Webman 本身不支持 GraphQL，必须手动桥接；直接用路由分发 query 字符串会退化成 REST 风格，彻底丢掉字段级按需能力。
为什么 Webman 不能直接用 Router 处理 /graphql 请求
Webman 的 onMessage 或中间件拿到的是原始 Request 对象，而 GraphQL 协议有硬性约定：
- 必须统一 POST 到单个路径（如
/graphql），不能按字段或资源拆路由 - 请求体必须是 JSON 格式，且含
query字段，variables和operationName为可选 - 若用
Route::post('/user', ...)这类 REST 写法，就无法复用同一个Schema响应不同字段组合，等于白搭 GraphQL - 常见错误：返回 404（没注册
/graphql路由）、Parse error: Unexpected token（把 raw body 当字符串传给执行器，没json_decode）
如何正确拦截并解析 GraphQL 请求体
关键在从 Request 中安全提取结构化数据，不是简单取 $request->input('query') —— Webman 不像 Laravel 那样自动解析 JSON body。
Webman 2.2.0
下载
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
- 先校验
$request->method() === 'POST'且$request->header('content-type')包含application/json或application/graphql - 用
json_decode($request->rawBody(), true)解析 body，别依赖$request->post()（它只处理application/x-www-form-urlencoded） - 必须检查
$body['query']是否存在，$body['variables']默认设为空数组，$body['operationName']可选传入执行函数 - 如果解析失败，直接返回
400 Bad Request+{"errors":[{"message":"Invalid JSON"}}，避免执行器崩溃
resolver 必须适配 Webman 的协程/异步模型
Webman 默认启用协程（Swoole），resolver 里写同步阻塞代码（如 file_get_contents、未加 co\run 的 PDO 查询）会卡住整个 Worker。
- 数据库操作必须用协程 MySQL 客户端（如
swoole_mysql）或支持协程的 ORM（如hyperf/database封装版） - HTTP 请求要用
Co\Http\Client，别用curl_exec - 如果 resolver 返回
Generator或Co\Channel，需确保 GraphQL 执行器（如webonyx/graphql-php）支持 Promise/future —— 它默认不支持，得用graphql-php-async分支或自行包装 - 字段返回
null的最常见原因：resolver 抛异常但没被捕获，或用了sleep()、usleep()等同步等待
响应格式和错误处理必须严格遵循规范
GraphQL 客户端（如 Apollo）依赖标准响应结构，任意偏差都会导致前端解析失败。
- 响应头必须设
Content-Type: application/json，不能是text/html或缺省值 - 成功时返回
{"data":{...}}，失败时返回{"data":null,"errors":[{...}]}，errors数组不能为空 - 必须捕获
GraphQL\Error\InvariantViolation、GraphQL\Error\SyntaxError等底层异常，转为规范 error 对象，否则 Worker 进程可能退出 - 不要在 resolver 里
throw new Exception()后不管——GraphQL 执行器会吞掉堆栈，前端只看到模糊的"Internal server error"
最难调试的其实是 resolver 的隐式同步调用：看起来代码能跑，但一并发就慢、超时、CPU 暴涨。真正适配 Webman 的 GraphQL 服务，90% 的工作量不在 Schema 定义，而在让每个 resolver 真正“协程友好”。
