01
Schema 服务结构先进入工作台
Reflection、Proto 目录和 Git Proto 统一进入同一条发现路径，方法、类型和 streaming 标识在请求前确认。
Reflection + Proto跑通一个 gRPC 调用，回放整条链路
把 Auth、Metadata、运行时变量和 traceId 留在同一条本地工作流里。登录拿到的 token、userId、traceId 会跟着链路走，不再靠复制粘贴维持上下文。
1234
{
"username": "admin",
"password": "admin123"
} LoginRequest schema synced 5 fields
usernamestring · required
admin static passwordstring · required
admin123 secret remember_mebool · optional
true default trace_idstring · runtime
{{session.traceId}} runtime metadatamap<string,string>
+ 3 entries chain 12345
{
"token": "jwt.user-1.1777898990",
"expires_in": "86400",
"user_id": "user-1"
} macOS Windows Linux
RPCORA vs Postman vs Insomnia vs Apifox
先看差异，再决定要不要下载。
Postman、Insomnia 和 Apifox 都能发送 gRPC 请求，Apifox 也支持通过服务反射导入服务。RPCORA 的差异不在“能不能发”，而在把本地隐私、Git 仓库、Proto 目录、服务反射、目录树、上下文传递、链路回放和 Doctor 诊断串成默认工作流。
✓ 直接主路径 · △ 支持但更依赖通用平台能力或额外配置 · × 官方文档明确限制
| 体验点 | RPCORA | Postman | Insomnia | Apifox |
|---|---|---|---|---|
| 基础执行 gRPC 请求执行 | 支持四种 RPC 类型 | 支持四种 RPC 类型 | 支持四种 RPC 类型 | 支持四种 RPC 类型 |
| 本地隐私 请求 / Schema / 响应数据路径 | 本地工作区保存请求、Schema、响应和链路上下文 | 云同步/团队协作强，敏感数据需用 Local Vault 和权限隔离 | 可选 Local Vault / Git / Cloud，需明确项目存储方式 | SaaS 数据在云端，私有化部署/离线空间需单独选择 |
| 发现建树 自动生成服务目录树 | Git / Proto 目录 / Reflection 进入本地 API 树 | Definition / Reflection 填充方法列表，非目录树主线 | Proto 目录 / Reflection / BSR 后选择 RPC | Proto / URL / Reflection 导入为服务和方法 |
| 发现建树 Git 仓库 Proto 来源 | repo + branch + subdir 导入并建树 | gRPC schema 走 Protobuf API、文件、URL 或 Reflection | Git Sync 管项目存储；gRPC schema 走文件/Reflection/BSR | Git 连接偏 OpenAPI 备份；gRPC schema 走文件/URL/Reflection |
| 发现建树 本地 Proto 目录导入 | 扫描目录、预览差异、应用到目录树 | 导入 .proto 并配置 import paths | 支持上传单文件或目录 | 本地文件导入，依赖目录需手动补 |
| 发现建树 服务 Reflection 导入 | 输入 server URL 直接生成服务树 | URL 支持时自动加载 definition | 同步 Reflection 后选择 RPC | 支持 Server Reflection 导入 |
| 发现建树 Reflection 失败后的 fallback | 切到 Proto 目录/Git 继续同一条建树流程 | 改为选择或导入 Protobuf API | 改为上传 Proto 或使用 BSR | 可改用本地文件或 URL 重新导入 |
| 请求编辑 Schema-aware 请求编辑 | 按 message 字段组织 Payload | JSON 消息 + Protobuf 类型辅助 | 按 schema 填写 JSON Body | JSON 消息 + 请求/响应参数查看 |
| 请求编辑 示例生成和参数填充 | 目录树选方法后生成示例并保留已有参数 | 可生成 example message | 按 schema 编辑请求 body | 可自动生成消息体和动态值 |
| 请求编辑 Auth / Metadata / TLS 上下文 | 发送前统一解析并进入诊断证据 | Auth、Metadata、TLS 设置齐全 | Auth、证书和环境可配置，诊断不聚合 | Auth、Metadata、TLS、变量和环境齐全 |
| 链路上下文 多步链路回放 | Chains 内置回放路径 | 通过 collection、变量和 gRPC scripts 组织 | 官方 gRPC FAQ 将 request chaining 列为不支持 | 测试场景可编排，更偏自动化测试平台 |
| 链路上下文 token / userId / traceId 上下文传递 | 运行时变量随步骤流动 | 通过变量和脚本维护 | 可用环境变量；gRPC request chaining 文档列为不支持 | 通过动态值、提取变量和测试步骤维护 |
| 链路上下文 请求保存后的复用方式 | 目录树请求可直接进入 Chains | 保存到 collection 复用和分享 | 可保存请求；gRPC 历史持久化文档列为不支持 | 保存 URL、消息、Metadata 到当前方法 |
| 诊断交接 失败诊断和交接证据 | Doctor + 脱敏链路报告 | Response、Metadata、Trailers、Test results 可看 | 单次响应可看；gRPC 测试和历史能力有限 | 调试时间线、变量和测试报告可看 |
| 诊断交接 交接给同事排障 | 失败步骤、schema 来源、上下文一起脱敏输出 | 团队协作和评论能力强 | Local / Git / Cloud 项目共享，取决于存储方式 | 团队协作、文档和分享能力强 |
这里比较的是 gRPC 日常调试体验，不是完整 API 平台能力。Postman 更适合 API 生命周期管理；Apifox 更适合团队一体化 API 协作平台；Insomnia 更适合轻量通用客户端；RPCORA 更适合不希望请求、Schema、响应和调试上下文离开本机，同时每天从 Proto/Reflection 建树、调本地链路、沉淀诊断证据的人。
gRPC Workbench
把 gRPC 调试变成一条可追踪的桌面工作流。
02
Context 鉴权和变量随请求流动
环境变量、Auth、Metadata、TLS 与运行时绑定在发送前解析，减少手动复制 token、userId 和 traceId。
Runtime bindings03
Evidence 失败结果沉淀成证据
链路步骤、gRPC 状态、耗时、schema 来源和 Doctor 结论组成脱敏报告，便于交给研发继续定位。
Doctor report Workflow
从发现服务到链路回放，RPCORA 保留每一步上下文。
单请求不是孤立动作。RPCORA 把 schema、Payload、Auth、Metadata、运行时变量和诊断结果串在一起，让一次调试可以沉淀成下一次可复跑的路径。
本地工作区链路回放Doctor 诊断
RPCORA / 调试台 Reflection 已连接
Discover service
连接目标地址，读取 service、method、request 和 response 类型。
Compose payload
在结构化 Request Body Composer 里处理必填字段、oneof、map 和数组。
Bind runtime values
把上游响应、环境变量和 Metadata 绑定到下游请求。
Replay chain
按顺序执行已保存请求，定位失败步骤并生成 Doctor 结果。
01messageuser.v1.GetUserRequest
02user_idenv.USER_ID
03with_profiletrue
04trace_id{{session.traceId}}
05metadata+ 3 entries
No errors6/6 fields filled
Evidence
报告不是截图，是可以继续定位的运行证据。
失败时，RPCORA 把上下文解析、Doctor 检查和链路报告放在同一个证据面板里。你能看到哪里失败、失败时带了什么上下文，以及下一步应该查什么。
发送前看清变量解析结果
{{session.token}}、{{profile.user_id}}、traceId 等上下文在运行前就能校验。
Context ready把失败拆成可处理线索
地址、TLS、Metadata、Reflection、Proto fallback 和 gRPC status 分区展示。
4 checks passed脱敏报告直接用于协作排障
报告保留链路步骤、耗时、错误摘要和建议，避免敏感 token 泄露。
Redacted Doctor Report redacted
step03 · profile.UserService/GetUser
schemaReflection · user.v1.GetUserRequest
metadataauthorization: Bearer ******
statusOK · 120ms
For Teams
给每天排查服务的人用。
本地和内网服务联调
调通单个 gRPC 方法，保存可复用请求，复现登录后访问业务接口的完整上下文。
稳定复跑关键业务路径
把登录、查询、创建、校验这类步骤固定成链路，失败后复制脱敏报告给研发。
排查 TLS、Metadata 与 schema 问题
快速区分是地址、证书、权限、Reflection、Proto 还是响应结构导致调用失败。
Why RPCORA
不是多一个请求面板，而是把 gRPC 调试上下文收进同一条路径。
RPCORA 面向真实服务联调：先看懂 schema，再跑通请求，然后把上下文、链路和诊断证据留在本地工作台里。
gRPC 调试先从 schema 开始
RPCORA 把 service、method、message 类型、Metadata、TLS 和状态码作为一等信息处理，避免把 gRPC 当成普通 URL 表单来调。
链路上下文不再靠人手搬运
登录、鉴权、userId、traceId 和环境变量可以在请求之间传递，单次调通后就能沉淀成可重复执行的业务路径。
排障结果可以直接交付
Doctor 和链路报告围绕失败步骤、schema 来源、运行时变量、耗时和 gRPC 状态组织，方便研发、测试和平台团队继续定位。
Inputhost:port + schema
ResolveMetadata · Auth · TLS
Replaytoken → userId → traceId
ShareDoctor 报告 · 脱敏
Use RPCORA When
当 gRPC 调试开始依赖上下文、链路和证据，RPCORA 的价值会更明显。
调试需要完整 gRPC 上下文
服务发现、Payload、Metadata、Auth、TLS、响应状态和链路变量都在同一个桌面工作台里。
一次调用要沉淀成可复跑链路
把已经跑通的请求保存成步骤，再把登录、鉴权、查询和校验串成稳定回放路径。
排障结果需要能交付给别人
Doctor 和链路报告用结构化证据说明失败位置、运行上下文和下一步处理方向。
Community
加入 RPCORA QQ 技术交流群，遇到联调问题可以直接交流。
适合反馈桌面端使用问题、讨论 gRPC 调试链路、交流 Proto/Reflection/TLS/Auth 等真实联调场景。
RPCORA技术交流群 QQ群号 739750887
扫码加入 QQ 交流群
Download
下载 RPCORA，先跑通一个 gRPC 方法，再回放整条链路。
第一次使用建议从最小路径开始：安装桌面端，APIs 调通单请求，保存后进入 Chains 做两步回放。