MCP 传输层升级实战：从 stdio 到 Streamable HTTP，我踩过的坑

上个月我写了一个 MCP Server 给团队内部用，跑在 stdio 传输层上，一切正常。直到产品经理说：这个工具要给前端同学在浏览器里直接用。stdio 模式要求 MCP Server 和客户端在同进程，意味着要么写一个 VS Code 插件，要么让前端自己维护一个 Node 子进程。两个都不现实。查了一圈发现 MCP 官方已经在推 Streamable HTTP 传输层了——不是新协议，是传输方式的升级。我花了三天把 server 从 stdio 迁移到了 HTTP，中间踩了不少坑，记下来给有同样需求的人。MCP 的传输层进化史如果你没看过我前面几篇文章，简单说下 MCP（Model Context Protocol）给 AI 工具（Claude、Cursor、Copilot 等）提供了一种统一的插件接口，让它们能调用外部工具、读文件、查数据库。传送数据的方式就叫传输层（Transport）。MCP 的传输层一共有三代：第一代：stdio——Client 启动 Server 子进程，走标准输入输出通信。简单直接，适合本地开发工具。第二代：SSE（Server-Sent Events）——Client 和 Server 走 HTTP，Server 通过 SSE 向 Client 推送数据。支持远程部署，但 SSE 是单向的。第三代：Streamable HTTP——全部走 HTTP POST，单个请求流式返回。双向通信在同一连接内完成，简化了架构。这听起来可能有点抽象，我拿实际代码来说话。一个简单的 stdio MCP Server先看传统 stdio 模式的 MCP Server 长什么样。这里用 Typ