选 MCP 传输层，本质是选「客户端和服务器怎么说话」。 stdio 最简单、本地最稳；SSE 曾长期是远程标配但现在被更现代的方案取代；Streamable HTTP 把双向通信收进一套 HTTP 语义里，是当前的推荐方向。传输层选错，后面鉴权、扩缩容、调试全要返工。本文把三种传输的取舍讲清楚，帮你按部署场景做决定。
stdio：本地进程的默认选择
stdio 通过标准输入输出来传递 JSON-RPC 消息，服务器作为本地子进程由客户端拉起。它没有网络端口、没有暴露面，天然适合「 AI 编程助手调用本机工具」这类场景。它的代价是只能本机、只能一对一，且进程生命周期绑定客户端。绝大多数桌面端 MCP 客户端默认就用 stdio，配合 MCP 客户端对比选择 时，传输方式往往是第一个要看的指标。
SSE：旧版远程方案，正在退场
SSE（Server-Sent Events）曾用于「服务器在远端、客户端走 HTTP 」的部署：客户端用普通 HTTP 发请求，服务端用 SSE 长连接推结果。它的明显短板是只能服务端单向推、客户端仍需单独的 POST 回传，连接管理和重连都很别扭，且规范已不推荐新项目使用。新项目不应再选 SSE，除非你在维护一套已有的旧部署。
Streamable HTTP：当前推荐的统一方案
Streamable HTTP 把请求/响应和服务器推送都收进标准 HTTP：用普通 POST 发 JSON-RPC，需要流式或服务器主动推送时再升级到 SSE，连接可无状态也可带会话。它解决了 SSE 的单向尴尬，又能跑在普通反向代理和负载均衡后面，是远程部署的首选。配合 MCP 生产部署 时，Streamable HTTP 的「可放在标准网关后」特性几乎是必选项。
怎么按场景选
一句话：本地工具优先 stdio；远端服务优先 Streamable HTTP；SSE 仅用于兼容旧系统。还要考虑运维：stdio 没有网络层，简单但难扩展；Streamable HTTP 能借现有 Web 基础设施做鉴权、限流、灰度，代价是你要管好会话与超时。可参考 MCP 服务端选择指南 把传输、鉴权、托管一起评估，别孤立地只看传输一项。
调试与常见坑
stdio 的坑在日志：子进程的 stderr 容易被客户端吞掉，建议把调试日志写到文件而非标准错误。 Streamable HTTP 的坑在会话：负载均衡后若会话状态不共享，请求可能落到没有该会话的节点，要用粘性或把会话外置。无论哪种，都建议在网关层记录原始消息体，出问题才能复盘，而不是盲猜。
- 判位置：服务器在本机优先 stdio，在远端优先 Streamable HTTP 。
- 弃 SSE：新项目不再选 SSE，仅用于兼容既有旧部署。
- 定会话：Streamable HTTP 要规划会话存储与粘性，避免负载均衡丢会话。
- 接网关：远程部署把鉴权、限流、超时放在标准网关层统一处理。
- 留日志：网关记录原始消息体，stdio 写文件日志，便于事后复盘。
常见问题
本地工具为什么默认用 stdio？
SSE 还能用吗？
Streamable HTTP 好在哪？
Streamable HTTP 最容易被什么坑？
评论 (0)