用途：作为高层路由技能，帮助在 .NET 项目中根据需求选择合适的服务通信协议，并提供决策矩阵与决策流程图。附带协议对比涵盖方向、线格式、浏览器支持、契约、延迟、吞吐、流式、连接方式、服务间通信与 AOT 友好性。
主要能力：
- gRPC：适合服务间通信、高吞吐流式、强类型契约，基于 .proto 的 schema-first 开发，支持四种流式模式，Protobuf 二进制序列化，内置代码生成与负载均衡/健康检查。不适合直接浏览器通信或简单 CRUD 公共 API。
- SignalR：适合面向浏览器的实时应用，自动传输协商（WebSocket→SSE→长轮询）、分组管理和用户定向、Hub 抽象、可用 Redis 背板或 Azure SignalR Service 扩展。不适合仅服务端推送或服务间通信。
- SSE：适合简单服务端推送、实时通知、状态更新，.NET 10 通过 TypedResults.ServerSentEvents 内置，浏览器原生 EventSource，自动重连，可穿透阻止 WebSocket 升级的 HTTP/1.1 代理。不适合双向通信。
- JSON-RPC 2.0：适合工具协议（如 LSP）、结构化 RPC，传输无关，StreamJsonRpc 被 Visual Studio、VS Code 与 .NET 工具使用。不适合实时流式或高吞吐服务间通信。
- REST：适合公共 API、标准 CRUD、广泛客户端兼容，人类可读 JSON，生态丰富。不适合实时推送或高吞吐服务间。
使用方式：先判断是否服务间（无浏览器）：是则按是否需要流式、是否请求-响应、吞吐与载荷格式选择 gRPC 或 REST；否则按是否需要实时、是否双向选择 SignalR、SSE 或 REST。特殊场景：LSP/工具协议用 JSON-RPC 2.0；混合场景浏览器用 REST、内部用 gRPC。单个 ASP.NET Core 主机可同时提供 gRPC、REST、SignalR 与 SSE，例如 AddGrpc、AddControllers、MapGrpcService、MapControllers、MapGet 配合 TypedResults.ServerSentEvents。
适用场景：API 网关混合协议、事件驱动配合 SSE、双协议服务等架构，按客户端类型路由。
限制：浏览器无法原生处理 gRPC HTTP/2 trailers，需 gRPC-Web 代理；不要默认用 gRPC 面向浏览器；不要用 SignalR 做服务间；SSE 足够时不要加 SignalR；高吞吐内部通信不要用 REST；REST 使用 System.Text.Json 时 AOT 需源生成上下文；原始 gRPC 需 HTTP/2，并非所有环境都支持。HTTP 客户端工厂、弹性管道、原生 AOT 架构与裁剪策略不在本技能范围内。
资料未提供安装命令、收费与价格信息。