Webman最适合的微服务定位是作为轻量级网关或客户端，用TCP/HTTP对接真实后端；不支持gRPC服务端，强行自建会卡在协议解析、流式响应等底层环节，得不偿失。
Webman 本身不支持 gRPC 服务端，也无意替代 Go/Java 的高性能 RPC 服务角色；它最适合的微服务定位是：**作为轻量级网关或客户端，用 TCP/HTTP 协议对接真实后端服务**。强行在 Webman 里自建 gRPC 服务端，会卡在协议解析、流式响应、连接复用等底层环节，得不偿失。
Webman + tinywan/rpc 实现 TCP 原生 RPC 调用
这是 Webman 生态中最成熟、开箱即用的 RPC 方案，基于纯 TCP + JSON 文本协议，无额外扩展依赖，适合内部服务间低延迟调用。
-
tinywan/rpc默认使用9512端口监听，服务端需在service/目录下定义类（如User.php），方法必须返回含code、msg、data结构的数组 - 客户端调用时，
fgets($client, 10240000)必须带足够大的缓冲区，否则大响应体被截断；结尾的换行符"\n"不可省略，否则服务端无法识别消息边界 - 连接不能复用：每次调用都应
stream_socket_client()新建连接 +fclose()关闭，否则在高并发下易触发Too many open files - 若需连接池，得自行封装
Swoole\Coroutine\Channel缓存 socket 句柄，但注意stream_socket_client不支持协程调度，必须改用Swoole\Client或co::socket
Webman 作为 gRPC 客户端调用 Go/Java 后端
这是真正能发挥 Webman 协程优势的场景——用 PHP 做业务胶水，把重逻辑交给 gRPC 服务。
- 必须编译安装
grpc扩展（PECL 安装后需确认php -m | grep grpc输出存在），仅composer require grpc/grpc无效，会报Class 'Grpc\Channel' not found -
Channel实例建议在onWorkerStart中创建并绑定到Container，避免每次请求 new Channel 导致连接爆炸；同时设置'grpc.keepalive_time_ms' => 30000防止空闲断连 - 明文调用必须用
Grpc\ChannelCredentials::createInsecure()；若后端启用了 TLS，传入的证书路径必须为绝对路径且 Webman 进程有读取权限，否则连接直接失败无明确错误提示 - proto 文件生成的 PHP 类需手动
require_once，因为 Webman 默认不扫描vendor/下的生成代码目录
Nginx 反向代理 gRPC 流量到 Go 服务
当 Webman 需对外暴露统一 API 入口，又想让前端直连 gRPC（如 Vue 使用 @improbable-eng/grpc-web），只能靠 Nginx 中转。
- Nginx 配置必须用
grpc_pass，写成proxy_pass会导致 HTTP/1.1 降级，返回426 Upgrade Required或直接502 Bad Gateway - 后端 gRPC 服务监听地址必须是
0.0.0.0:50051，不能是127.0.0.1:50051，否则容器或 Docker 网络环境下 Nginx 无法访问 - Webman 自身不参与代理逻辑，它只负责鉴权、日志、限流等前置处理；gRPC 的
Content-Type: application/grpc和二进制帧由 Nginx 透传，PHP 层完全不可见
真正难的不是“怎么调”，而是决定哪一层该承担什么职责：Webman 不该做协议解析，也不该管连接保活细节；它该专注路由分发、上下文注入和错误归一化。把 gRPC 当黑盒用，把 tinywan/rpc 当内网高速通道用，才是符合其设计边界的用法。
