html怎么做Server-Sent Events推送_html SSE服务端推送事件流接收【解析】-html教程-PHP中文网

HTML本身不负责SSE推送，仅通过EventSource接收；真正推送必须由服务端生成合法text/event-stream响应流，需严格满足5个条件：200状态码、Content-Type为text/event-stream、Cache-Control含no-cache、每条消息以\n\n结尾、连接不可提前关闭。

html怎么做server-sent events推送_html sse服务端推送事件流接收【解析】

HTML 本身不负责 SSE 推送，只负责接收；真正的推送必须由服务端生成合法的 text/event-stream 响应流 —— 如果你写了 new EventSource('/events') 却一直 pending 或报错 net::ERR_INCOMPLETE_CHUNKED_ENCODING，问题 90% 出在服务端响应头或输出格式没写对。

服务端响应必须满足这 5 个硬性条件

SSE 不是“发个数据就行”，浏览器会严格校验响应是否符合事件流规范。缺一不可：

HTTP 状态码必须是 200（304、204、500 都会导致连接失败）
Content-Type 响应头必须为 text/event-stream（拼错、大小写错误、多空格都会失效）
Cache-Control 必须含 no-cache；Safari 更敏感，建议加 must-revalidate 或 no-store
每条消息结尾必须是两个换行符：\n\n（哪怕只发 data: 也得补上）
连接不能被提前关闭：Node.js 不能用 res.end()，Python 不能 print() 后直接退出，PHP 必须 flush() 且保持脚本运行

Node.js/Express 中最易漏的保活和清理逻辑

本地测试可能正常，但上线后频繁断连？大概率是 Nginx 或负载均衡器默认 60 秒超时切断了空闲连接。光靠前端重连解决不了根本问题：

服务端需定期发送注释行保活：res.write(':keepalive\n\n')（冒号开头的行浏览器忽略，但能重置代理超时计时器）
必须监听 req.on('close') 或 res.on('close')，手动清理 setInterval 或数据库连接，否则内存泄漏
不要依赖 retry: 字段控制重连间隔 —— Chrome 完全不支持，仅 Firefox 解析；重连策略应由前端 onerror 手动控制

示例关键片段：

Html2md

使用 Readability + Turndown 将 HTML 页面转换为干净的、Agent 友好的 Markdown。去除导航栏、广告、页脚、Cookie 横幅、社交按钮等干扰元素。支持 URL...

下载

app.get('/events', (req, res) => {
  res.writeHead(200, {
    'Content-Type': 'text/event-stream',
    'Cache-Control': 'no-cache, must-revalidate',
    'Connection': 'keep-alive'
  });

  // 发一条初始化消息（可选）
  res.write('data: {"status":"connected"}\n\n');

  const timer = setInterval(() => {
    res.write(`data: {"time":${Date.now()}}\n\n`);
    // 保活：每 30 秒发一次注释
    if (Date.now() % 30000  {
    clearInterval(timer);
    res.end(); // 注意：这里才是安全结束
  });
});

前端 EventSource 的跨域、凭证与错误兜底

很多问题表面是“收不到数据”，实际卡在请求发不出去：

CORS 报错？服务端必须返回 Access-Control-Allow-Origin；若前端启用了 withCredentials: true，该值不能为 *，必须指定具体域名
需要带 token？原生 EventSource 不支持自定义 headers，只能走 URL 参数（如 /events?token=xxx）或改用 fetchEventSource（支持 headers 和 method: 'post'）
onerror 不区分错误类型：网络中断、CORS 拒绝、路径 404、服务端崩溃都触发它。判断是否真连上了，看 eventSource.readyState —— 0 表示未建立，0 反复触发基本就是跨域或路由问题
错误时别傻等自动重连：手动 es.close() + 延迟 new EventSource(...)，并指数退避（如 1s → 2s → 4s），避免雪崩

Spring Boot 的 `SseEmitter` 超时与异常处理陷阱

Spring Boot 封装了 SseEmitter，但默认 30 秒超时、异常后不自动清理，是线上最常见的内存泄漏源头：

创建时显式传 0L： new SseEmitter(0L)，禁用内置超时（否则 30 秒后 onTimeout 触发，但连接可能还在）
onError 回调里不要只打日志 —— 必须调用 emitter.complete() 或 emitter.send(...) 后再 complete()，否则对象滞留 Map 中
使用 ConcurrentHashMap 存储 emitter 时，务必在 onCompletion 和 onTimeout 里都执行 map.remove(uid)，否则 OOM
推送前必须判空：if (emitter != null && !emitter.isCompleted())，否则抛 IllegalStateException