EventSource 不依赖 Transfer-Encoding: chunked，仅依据 Content-Type: text/event-stream 和 SSE 协议规范解析数据流；其分帧基于换行符与字段语法，由浏览器自动处理 chunked 解码，服务端只需正确输出 SSE 格式文本并及时 flush。
EventSource 不依赖 Transfer-Encoding: chunked，它只认响应头 Content-Type: text/event-stream，并按 SSE 协议规范解析数据流，与底层是否用 chunked 编码无关。
EventSource 的分帧逻辑不关心 chunked 编码
Chunked 是 HTTP 层的传输编码机制，用于解决“响应体长度未知”时的数据分段发送问题；而 EventSource 工作在应用层，它接收的是已由浏览器网络栈解码后的完整字节流（即 chunked 已被自动还原为原始字节）。浏览器内部会先完成 chunked 解包，再把连续、无分块标记的纯文本交给 EventSource 解析。
换句话说：chunked 只影响 TCP 包怎么发、HTTP 怎么传，不影响 EventSource 看到的内容。只要后端返回正确的 SSE 响应头和格式，EventSource 就能正常工作。
SSE 分帧依据是换行符和字段语法，不是 chunk 边界
EventSource 按照 W3C SSE 规范 逐行读取响应体，以 \n 或 \r\n 为行分隔符，识别以下字段：
立即学习“Java免费学习笔记（深入）”；
- data: 后续内容作为事件数据（多行 data: 会自动拼接，以 \n 分隔）
- event: 指定事件类型（如 "message", "update"）
- id: 设置事件 ID，用于断线重连时的 last-event-id
- retry: 指定重连间隔（毫秒）
- 空行（仅含 \n 或 \r\n）表示一个完整事件结束
它完全忽略 HTTP chunk 头（如 0a\r\n）、chunk 分隔 CRLF 和终块 0\r\n\r\n——这些在到达 EventSource 前已被浏览器剥离。
服务端只需保证 SSE 格式正确，无需手动处理 chunked
现代 Web 框架（如 Express、FastAPI、Spring WebFlux）在返回 SSE 响应时，通常自动设置：
Content-Type: text/event-streamCache-Control: no-cacheConnection: keep-alive- 不设
Content-Length（触发服务器自动启用 chunked）
你只需按行输出符合 SSE 语法的文本，例如：
data: {"status":"running"}\n\n data: {"progress":50}\n\n浏览器会持续接收、缓冲、按行切分、组装事件，全程无需你干预 chunked 行为。
常见误区：混淆 chunked 和 SSE 的作用层级
误以为“必须手动写 chunked 头才能让 EventSource 流动”——这是错的。只要你没禁用自动 chunked（比如强行加了 Content-Length），且后端持续 write + flush，浏览器就会自然走 chunked 传输路径，但 EventSource 完全感知不到这个过程。
真正导致 EventSource 卡住或收不到数据的原因通常是：
- 响应头缺失
text/event-stream或含Content-Length - 后端未及时 flush（尤其在 Node.js 中漏掉
res.flush()） - 代理（Nginx、CDN）缓存了响应或关闭了长连接
- 每条消息末尾没加两个 \n（
\n\n），导致 EventSource 无法判定事件边界
