优先选 HTTP/1.1 + JSON（即 RESTful 风格 API），次选 gRPC（需 PHP 8.1+ + ext-grpc），慎用自定义 TCP 协议或 Thrift；因 PHP 生态中稳定、可调试、易监控比微秒级延迟更重要。
PHP 调用内部 RPC 服务该选什么协议？
直接说结论：**优先选 HTTP/1.1 + JSON（即 RESTful 风格 API），次选 gRPC（需 PHP 8.1+ + ext-grpc），慎用自定义 TCP 协议或 Thrift**。这不是“性能最优”而是“综合成本最低”的选择——尤其在 PHP 生态里，稳定、可调试、易监控比微秒级延迟重要得多。
为什么 HTTP/JSON 是 PHP 内部 RPC 的默认安全牌？
PHP 的 curl 和 file_get_contents 对 HTTP 支持最成熟，json_encode/json_decode 是内置函数，无额外扩展依赖。更重要的是：
- 所有日志系统、APM（如 SkyWalking、Zipkin）和网关（Nginx、Kong）都原生支持 HTTP trace 和 metrics 采集
- 出问题时能直接
curl -v http://svc:8080/api/user/123复现，不用写客户端脚本 - 服务端若用 Go/Python/Java 实现，HTTP 接口开发成本远低于维护多语言 gRPC IDL 同步
-
Content-Type: application/json的 body 体在 PHP 中无需序列化/反序列化逻辑，避免unserialize()安全风险
gRPC 在 PHP 里真香吗？先看这三道坎
gRPC 确实更快、更省带宽，但 PHP 侧落地门槛明显：
- 必须安装
ext-grpc扩展，且它不兼容 PHP 的opcache.preload，部分 Swoole 场景下会触发Segmentation fault - IDL（
.proto文件）要和 Go/Java 服务端严格同步；PHP 生成的 stub 类不支持运行时动态加载，改接口就得重生成+部署 - 调试困难：
grpc-status: 14这类错误码得查文档才能知道是 “unavailable”，不如 HTTP 的503 Service Unavailable直观 - 流式调用（streaming）在 PHP-FPM 下基本不可用，只有 Swoole/Swoole-Coroutine 或 RoadRunner 环境下才勉强支持
哪些情况可以考虑非 HTTP 协议？
仅当满足全部以下条件时，才值得投入成本上其他协议：
立即学习“PHP免费学习笔记（深入）”；
- 服务间调用 QPS > 5k，且对 P99 延迟敏感（
- 团队有专人维护协议栈，能处理
ext-grpc升级导致的 ABI 不兼容（比如从 grpc 1.42 升到 1.60） - 已有统一 IDL 管理平台，
.proto或.thrift变更能自动触发 PHP 客户端生成与 CI 检查 - 明确拒绝 HTTP 的 header 体积开销（比如每请求固定多 200+ 字节），且 payload 全是结构化二进制数据（如 protobuf 序列化后的用户画像）
否则，别碰 tcp:// 自研协议、Thrift 或 MsgPack-RPC——它们在 PHP 里没有标准实现，debug 时只能靠 tcpdump + 手动解析字节流。
