现在都是APP，小程序抢购，支持浏览器不支持 SSE
在 APP 和小程序抢购场景中，通常不原生支持SSE（Server-Sent Events），这与浏览器对 SSE 的支持情况不同，具体如下：
- APP：一般情况下，APP 端不支持原生 SSE。若使用 UniApp 开发，在 App 端也不能直接使用 JavaScript 内置的 EventSource 对象来建立 SSE 连接，需要寻找其他替代方案，如使用 WebSocket 或轮询模拟流式请求。
- 小程序：以微信小程序为例，其原生也不支持 EventSource 对象。若要实现类似 SSE 的效果，可以通过 wx.request 结合 enableChunked 特性实现分块传输，模拟 SSE 流数据接收，或者使用一些垫片库来实现。
而在浏览器中，大多数现代浏览器是支持 SSE 的，可直接使用 EventSource API 来连接 SSE 端点。不过，IE 等早期浏览器不支持 SSE。
SSE不就是长连接？
SSE（Server-Sent Events，服务器发送事件）本质上是基于HTTP 长连接的单向通信协议，核心特征是 “客户端发起连接后保持长连接，服务器通过该连接持续向客户端推送数据”。
具体来说，SSE 的 “长连接” 特性体现在：
连接建立方式
客户端通过普通 HTTP 请求（GET方法）发起连接，请求头中会指定Accept: text/event-stream，告知服务器 “我要接收 SSE 流数据”。服务器响应时会返回Content-Type: text/event-stream，并保持 TCP 连接不关闭，形成 “长连接”。数据传输方向
长连接建立后，仅允许服务器向客户端单向推送数据（客户端不能通过该连接向服务器发送数据），适合抢购结果通知、实时日志等 “服务器主动推” 的场景。连接复用与保活
长连接会持续一段时间（具体时长由服务器和客户端的超时配置决定），期间服务器可多次推送数据（无需重新建立连接）。若连接中断，客户端可自动重连（SSE 的EventSource对象默认支持重连机制）。
SSE 与其他长连接方案的区别：
| 方案 | 连接类型 | 数据方向 | 适用场景 |
|---|---|---|---|
| SSE | HTTP 长连接 | 服务器→客户端（单向） | 抢购结果推送、实时通知 |
| WebSocket | 独立 TCP 长连接 | 双向通信 | 聊天、实时交互（如抢购中取消） |
| 轮询 | 短连接循环建立 | 客户端→服务器（主动拉取） | 兼容性要求高的简单场景 |
简单说，SSE 是 “HTTP 长连接 + 单向推送” 的轻量方案，而 WebSocket 是 “独立长连接 + 双向通信” 的全功能方案。在抢购等 “只需服务器推结果” 的场景中，SSE 比 WebSocket 更轻量（复用 HTTP 协议栈，无需额外握手），但受限于单向通信；若需要双向交互（如用户中途取消抢购），则需用 WebSocket。