HTTP 流式响应：SSE 与 Stream

元信息

目标：打破"响应是一份完整文档"的时间维度假设——理解流式响应"边生成、边传输、边处理"的价值；能在 SSE 与 fetch stream 间按场景取舍，读懂 LLM API 逐字打出效果的底层实现
关键概念：流式响应、chunk、SSE、EventSource、text/event-stream、ReadableStream、getReader、首字延迟、stream: true
关联阶段：cp3
常见误区：以为 HTTP 必须 Content-Length 整块交付（协议天然支持逐块发送）；AI 对话场景选 EventSource（它只能 GET，装不下带对话历史的 POST，只能用 fetch stream）；以为流式更快（总时间没变，降的是首字延迟——感知速度比总速度更重要）

前面学的 ajax/fetch（ajax、网络请求API）都是同一种模式：发请求 → 等服务器把响应全部发完 → 一次性拿到结果。这对小数据毫无问题，但两类场景会把它逼到墙角：

普通请求的痛点在于"响应是一份完整文档"的隐含假设（和浏览器应用里"一次请求=一份完整文档"同源——只不过这次是时间维度的整块交付）。流式响应打破它：响应体可以分成很多块（chunk），边生成、边传输、边处理。

HTTP 协议本身天然支持（Content-Length 可缺省，连接保持、逐块发送），浏览器提供了两套消费手段：SSE 和 fetch stream。

SSE 是 HTML 标准的一部分：服务器以 text/event-stream 类型持续发送"事件"，浏览器用内建的 EventSource 对象接收：

import "./styles.css";

document.getElementById("app").innerHTML = `
<h1>Hello world</h1>
`;

服务器发的报文体是极简单的文本格式，一行一条：

plain

data: 第一条消息

data: 第二条消息

特点：只能 GET、只能服务器→客户端单向推送；换来的是极简 API 和自动重连。适合通知、进度、行情这类"服务器单方面说"的场景。

fetch 拿到的 response.body 是一个可读流（ReadableStream），可以逐块读取：

import "./styles.css";

document.getElementById("app").innerHTML = `
<h1>Hello world</h1>
`;

特点：任意方法（POST 也行）、可带请求体、可自定义协议格式；代价是重连、解析都要自己写。

取舍逻辑一句话：能用普通请求就用普通请求；需要服务器持续说→SSE；需要复杂请求（如带对话历史的 POST）又要流式答案→fetch stream。

你每天见到的 AI 对话"逐字打出"效果，就是流式响应的当代最大应用。DeepSeek、OpenAI 等主流 LLM API 的做法高度一致：

客户端的最小实现，就是在 fetch stream 循环里解析这些行：

import "./styles.css";

document.getElementById("app").innerHTML = `
<h1>Hello world</h1>
`;

为什么 LLM 非要用流式？生成速度是逐 token 的（一次几个字），SSE 逐块转发把首字延迟从"全文生成完"降到"第一个 token 生成完"——几十秒的等待变成 1 秒内的开始响应。这也是体验层的一课：感知速度往往比总速度更重要。