MCP 协议传输层进化：从 stdio 到 Streamable HTTP，我的踩坑实录

起因上个月我写了第一个 MCP Server，跑通了 stdio 传输，觉得自己已经入门了。然后我踩了个坑：把 stdio 模式的 server 部署到服务器上，对着终端发愣——stdio 要求 client 和 server 在同一个进程里，我的编辑器在本地，server 在远程，完全不配套。查了一圈才知道，MCP 不是只有 stdio 一种传输方式。2026 年的生态里，传输层已经分出了两条路：一条是本地开发用的 stdio，一条是生产部署用的 Streamable HTTP。这篇文章是我从 stdio 迁移到 HTTP 的全部记录，该踩的坑一个没少。## stdio：入门友好，生产痛苦MCP 最早只有 stdio 传输。它的设计很简单：client 启动一个 server 子进程，通过 stdin/stdout 交换 JSON-RPC 消息。// 从 client 发给 server 的典型请求

{“jsonrpc”: “2.0”, “id”: 1, “method”: “tools/call”, “params”: {“name”: “get_weather”, “arguments”: {“city”: “北京”}}}跑第一个 server 时觉得这设计挺优雅——不用管端口、认证、跨域，两个进程间管道通信，延迟极低（微秒级）。我原来写 Server 的工具查询方法，伪代码大概是这样：async def handle_request(request):
if request.method == “tools/list”:
return {“tools”: […]}
elif request.method == “tools/call”:
return await execute_tool(request.par