DevTools 流式连接排查路线
按 DevTools 面板协作方式梳理 SSE、WebSocket 和流式响应排查路径，覆盖握手、Header、消息流、代理和缓存干扰。
#type / synthesis
#status / growing
#tech / dev / frontend
#platform / browser
#resource / chrome-devtools
[!info] related notes
- 所属 MOC: 浏览器开发者工具 MOC, DevTools Network MOC
- 相关概念: SSE 与 WebSocket 调试, 请求与响应检查, Security / Issues 面板
- 易混淆概念: SSE, WebSocket, 实时通信：SSE vs WebSocket vs Polling, SSE 连接缓存问题
DevTools 流式连接排查路线
范围
这条路线处理的是：
- SSE 一直处于 CONNECTING
- WebSocket 握手失败或反复断开
- 流式输出突然中断、消息不连续
- 代理、压缩、缓冲破坏了长连接
为什么要放在一起理解
流式连接问题常常不是“业务逻辑没写对”，而是连接建立、传输链路和中间层行为出了问题。
排查时必须把这几层分开：
- 协议有没有建立成功
- 消息流有没有持续到达
- 中间层有没有改写 Header、压缩流、缓存结果
排查路线
第一步：先确认连接有没有真正建立
打开 Network 面板：
- SSE 看
Content-Type: text/event-stream - WebSocket 看握手是否成功
- 看状态码、响应头和连接持续时间
第二步：看是不是中间层破坏了流
重点检查：
- 是否错误启用了压缩
- 是否存在代理缓冲
- 是否有重定向、认证中间件、CORS 或 Header 丢失
这一层优先读 SSE 与 WebSocket 调试。
第三步：看消息流是否真的在动
如果连接建起来了，还要继续看：
- SSE 数据是否持续追加
- WebSocket Frames / Messages 是否正常收发
- 断开前有没有异常关闭码或错误事件
第四步：再看认证和站点状态
很多流式连接失败并不是传输本身坏了，而是：
- 认证没通过
- Cookie / Token 没带上
- 刷新 token 或长连接鉴权链路不一致
这时回到：
第五步：最后再怀疑业务协议层
如果连接和消息流都正常，才继续查：
- 业务消息格式
- 心跳策略
- 客户端状态机和重连逻辑
对比与易混淆点
- SSE 连接建不起来，常见是代理、压缩、缓冲问题，不一定是前端代码
- WebSocket 握手成功，不代表业务消息一定正常
- “看起来像超时”可能其实是认证失败或中间层提前断开