fetch()需显式配置credentials、手动判断response.ok、用AbortController设超时；HTTP/2提速依赖服务端真实支持；客户端缓存需精细控制；大JSON应流式解析或用Web Worker；优化重点在服务端响应头与CDN策略。
用 fetch() 替代 XMLHttpRequest，但得处理好默认行为
fetch() 是 HTML5 后期标准中更现代的异步通信方式，语法简洁、原生支持 Promise，但默认不带 Cookie、不自动拒绝非 2xx 响应、不支持超时——这些恰恰是提速和稳定性的关键点。
- 必须显式传
{ credentials: 'include' }才能携带 Cookie，否则登录态丢失 -
response.ok要手动判断，fetch()对 404/500 仍会 resolve，不 throw - 没有内置 timeout，需用
AbortController控制：
const controller = new AbortController();
setTimeout(() => controller.abort(), 8000);
fetch('/api/data', { signal: controller.signal })
.catch(err => {
if (err.name === 'AbortError') console.warn('请求超时');
});
启用 HTTP/2 多路复用前，先检查服务端是否真正支持
HTML5 本身不控制 HTTP 版本，但 AJAX 请求能否并发复用连接，完全依赖后端是否开启 HTTP/2 且配置正确。很多开发者误以为只要前端用 fetch() 就自动提速，其实不然。
- 用浏览器 DevTools 的
Network标签页，看请求的Protocol列是否显示h2 - Nginx 需启用
http2并配置有效 TLS 证书（HTTP/2 在非 HTTPS 下多数浏览器不启用） - 避免在同一个域名下混用 HTTP/1.1 和 HTTP/2 资源，可能导致连接降级
避免重复请求：用 cache 策略 + 客户端缓存键管理
AJAX 不像 自动走 HTTP 缓存，必须靠手动控制。盲目加 Cache-Control: max-age=3600 可能导致旧数据残留，而完全禁用又浪费带宽。
- 对只读接口（如配置、字典），服务端响应头设
Cache-Control: public, max-age=300 - 前端发请求时加
cache: 'default'或'force-cache'，但注意：Safari 对force-cache支持不稳定 - 动态参数（如时间戳、用户 ID）要参与缓存键计算，可用
URLSearchParams规范化查询字符串
大文件或长列表分页请求，别用 JSON.parse() 一次性吃全量
当接口返回几百 KB 甚至 MB 级 JSON（比如日志流、导出数据），直接 JSON.parse() 会阻塞主线程、触发内存抖动，用户感知就是页面卡顿。
立即学习“前端免费学习笔记（深入）”；
- 优先让后端支持
text/event-stream或分块application/json-seq，前端用ReadableStream流式解析 - 若只能返完整 JSON，考虑用
Web Worker拆包解析，避免阻塞渲染 - 对列表类数据，严格按需加载：用 IntersectionObserver 触发下一页，而不是预加载 5 页
真正影响 AJAX 速度的，往往不是前端写法，而是服务端响应头是否合理、CDN 是否缓存了 API、以及是否在不该并发的地方强行并发（比如 20 个 fetch() 同时打同一接口）。这些细节比换函数名重要得多。
