选对技术比写对代码更关键：Ajax适合低频兼容性场景，Fetch是现代HTTP请求替代，SSE适用于服务端单向轻量推送，WebSocket适用于双向高频实时协同，实际应用常混合使用。
选对技术比写对代码更关键。Ajax、Fetch、SSE 和 WebSocket 解决的不是同一个问题，而是分布在“请求频率”“通信方向”“实时性要求”和“浏览器支持”四个维度上的不同需求。
Ajax 适合一次性、低频、兼容性优先的交互
本质是客户端主动发起、服务端单次响应的请求-响应模型。它不追求实时，只求稳和广。
- 表单提交、搜索建议、分页加载等用户触发后才获取数据的场景
- 需要支持 IE9+ 或老旧内网系统时的兜底方案
- 上传文件时需监听进度（
xhr.upload.onprogress） - 需要手动中断请求（
xhr.abort()）的可控操作
Fetch 是 Ajax 的现代替代，适合结构化、可组合的 HTTP 请求
基于 Promise，语法简洁，天然支持 async/await，但默认不带 cookie，错误处理逻辑需显式判断。
- RESTful API 调用，尤其是配合 TypeScript 类型推导时
- 需要链式处理响应（如
response.json().then(...)）或流式读取（response.body.getReader()） - 构建自定义请求中间件（如统一加 token、日志、重试）
- 不需要上传进度监控，也不强依赖 IE 兼容性的新项目
SSE 适合服务端单向、持续推送的轻量实时场景
基于 HTTP，服务端保持连接并不断推送文本事件，客户端用 EventSource 接收。连接自动重连，协议简单，无双向需求。
立即学习“Java免费学习笔记（深入）”；
- 股票行情、新闻推送、系统通知等只读型实时更新
- 后台任务状态广播（如“导出完成”“审核通过”）
- 对移动端友好，HTTP 头部复用现有 CDN 和代理设施
- 服务端实现成本低，无需额外长连接管理（相比 WebSocket）
WebSocket 适合双向、高频率、低延迟的实时协同场景
建立全双工 TCP 连接后，客户端和服务端可随时互发消息。连接一旦建立，后续通信开销极小。
- 在线聊天、协作文档、多人游戏、远程控制台
- 需要心跳保活、消息确认、离线缓存与重传机制的业务
- 服务端需主动触发客户端 UI 变更（如权限变更立即踢下线）
- 已有 WebSocket 基础设施（如 Socket.IO、ws 库、云厂商通道）支撑
没有银弹。一个典型应用往往混合使用：用 Fetch 加载初始数据，用 SSE 推送通知，用 WebSocket 处理互动，而 Ajax 在遗留模块中继续服役。关键是根据数据流向、更新节奏和运维能力做取舍。
