这两年有个挺明显的变化：问"SSE 怎么调试"的人多了起来。原因也不难猜------大模型的打字机效果、实时通知、行情推送，背后全是流式接口：以 SSE 为主，一部分是 gRPC 流。这类接口的调试体验和普通 REST 完全是两回事：普通接口点一下、看响应就行，流式接口是"一条连接上源源不断往外吐数据"------工具的展示方式要是不对，你看到的就是一团没头没尾的文字。
这篇就说说流式接口的抓包调试：SSE 和 gRPC 各自长什么样、工具怎么展示、出了问题怎么排查吧。
一、先搞清它们特殊在哪
SSE（Server-Sent Events） ，说穿了是一种"长连接版"的普通 HTTP：服务器响应一个 Content-Type: text/event-stream 的流，然后就一直不关，想起一条就写一条。消息格式是纯文本的简单协议------data: 是内容、event: 是事件名、id: 是序号，两条消息之间用空行隔开。也就是说，SSE 的消息自带分帧标记，缺的只是"按条拆开看"的工具。
gRPC 走的另一条路：跑在 HTTP/2 上，body 是 protobuf 二进制------没有 .proto 定义时，字段连名字都没有，只剩字段号和值；再加上四种调用模式里就有服务端流、双向流，一次调用的 body 本身就是一串消息。
两者一个共同点：都不是"一个请求一个响应"，而是一串消息流。所以调试流式接口，第一件事不是看内容，是找到"按事件 / 按帧拆着看"的那个视图。
二、SSE 抓下来长什么样
先看原始格式，心里有个谱：
event: message
data: {"seq":1,"token":"你"}
event: message
data: {"seq":2,"token":"好"}
event: done
data: [DONE]人眼扫一遍还行，但真跑起来一秒几十条、还夹着长轮询的重连------要么日志滚得看不清，要么更糟：工具把它当成"一个还没结束的响应体"，你点开只看到连接断开前攒下的那一大坨快照，然后干瞪眼。
正确的看法是逐事件展示 ：像消息列表一样一条条列出来，每条能点开看 payload。这样"第 3 条和第 4 条之间隔了两秒""某条事件之后流就断了"这类问题，一眼就能定位。在 TraceEagle 里，SSE 的抓取结果就是按事件流逐事件拆开展示的------顺带说一句，WebSocket 的逐帧展示也是同一套思路，之前写过一篇讲 WebSocket 的，有兴趣可以找来看看。
三、gRPC：没有 .proto 也能先看个大概
gRPC 的麻烦在于二进制加无名。好在字段的"骨架"还在呢------字段号、类型、值，都在字节流里。免 .proto 的解析就是把这层骨架先解出来：不知道接口定义，也能先看到"第 1 个字段是字符串、值是 xxx"这样的结构，配合上下文反推含义，比对着二进制发呆强得多。
顺带科普一句 gRPC 的流式模式：客户端流、服务端流、双向流------抓包里遇到最多的是服务端流（服务器像 SSE 一样一条条推）和双向流，读法都一样：按条拆。在 TraceEagle 里，流式调用同样按条展示------服务端推了几条、每条里字段怎么变的，和 SSE 一样是"列表式"的读法。
四、几个真实的调试场景
大模型的打字机效果。 前端"字出来得卡顿"，到底是谁的锅？逐事件看时间线：如果服务端的事件本身就发得稀稀拉拉，问题在模型侧；如果事件发得很快、前端渲染慢，那问题在客户端。别小看这点区别啊，它能省掉前后端互相甩锅的一个下午。
流断了，"断在哪"？ 流式接口最烦的故障是"推着推着没了"。逐事件列表里，末尾那条成功的事件、断点前后的时间差、有没有错误事件------这几个信息凑起来，很快能判断是服务端主动结束、网络闪断还是客户端取消。
重连逻辑对不对。 SSE 协议自带重连约定（客户端带上 Last-Event-ID 续传），调试时可以看服务端有没有正确响应续传请求、有没有重复推送。这个用"一整坨 body"的视角是看不出来的。
五、和其他工具怎么配合
流式接口不是只能靠抓包工具看：curl -N 能直接看原始流（简单直接，但连接一断输出就没了嘛，留不下历史）；浏览器 DevTools 的 Network 面板有 EventStream 视图（看浏览器发的 SSE 很方便，但只能看浏览器进程、且只管 SSE）；Postman 这类接口工具对流式的支持这几年在补，简单场景够用。各自的强项不一样：TraceEagle 的位置在于"把流的每一条都留下来、能回看能对比"------尤其是抓手机上或别的进程发的流的时候（浏览器 DevTools 就够不着了）。Wireshark 也能看到流的原始 TCP 数据，但要跟着 follow stream 手动读才有意义，拿它看协议细节可以，日常调接口就太绕了。
六、几个常问的
SSE 和 WebSocket 有什么区别？ 最大的区别是方向：SSE 是服务器单向推、走普通 HTTP、协议自带断线重连和续传；WebSocket 是双向的、独立协议。做"服务器 → 客户端"的单向推送，SSE 的工程成本更低------这也是大模型接口都选它的原因。
抓 HTTPS 的 SSE 要装证书吗？ 要，和抓普通 HTTPS 没区别：解密那一步是前提，解出来之后才有"逐事件"的展示。证书那套流程之前写过，不重复了。
gRPC 一定要有 .proto 才能看吗？ 不一定。没有 .proto 时可以先解出字段号、类型和值，把内容看个大概；拿到定义之后再对照，理解的效率更高。
流很长，会不会看丢？ 工具会保留整个事件序列（而不是只留末尾那一帧），可以滚动回看、筛选、也可以整条导出
流式接口的调试，核心其实就一句话：把"一串消息"按条拆开，而不是当一坨 body。 SSE 靠 event: 和空行分帧，gRPC 靠 protobuf 的字段骨架，拆开之后，那些"卡顿是哪里的问题还有流断在哪一条"的问题，就方便查了。