关键在于理清fetch、跨域、重试与websocket在请求生命周期中的分工：fetch是快递员，跨域是安检门，重试是补救机制，websocket是专线电话，四者分属不同层级，不可混淆。
学这个组合，关键不是挨个背概念，而是理清它们在真实请求生命周期里的分工和协作关系。Fetch 负责发一次 HTTP 请求，跨域决定它能不能拿到响应，重试管它失败后要不要再试，WebSocket 则是另一套不走 HTTP 的长连接通道——四者根本不在同一层，混着学容易绕晕。
先分清楚角色：谁管什么
• Fetch 是“快递员”：只负责把你的请求送出去、把响应拿回来。它不关心是不是跨域、超不超时、连没连上，这些都得你额外配置或兜底。
• 跨域 是“安检门”：浏览器在 Fetch 拿到响应后才检查。请求早就发到后端了，后端也返回了数据，但浏览器发现响应头里缺 Access-Control-Allow-Origin，就直接把数据扣下，控制台报红。所以跨域问题永远先看响应头，而不是怀疑请求没发出去。
• 重试 是“补救机制”：只在 Fetch 明确失败（比如网络断开、超时、502）后才触发。它不解决跨域，也不替代 WebSocket；只是让偶发性失败更耐操。
• WebSocket 是“专线电话”：它压根不经过浏览器的同源策略安检（没有 CORS 检查），但服务端会校验 Origin 头来决定放不放行。连接成功后是双向、持久、低开销的，和 Fetch 的“一问一答”模式完全不同。
动手练三类典型场景
• 带超时和重试的 Fetch：用 AbortController 控制 8 秒超时，失败后最多重试 2 次，每次间隔递增（1s → 2s）。别用固定延时，避免请求雪崩。
• 跨域接口调试流程：打开浏览器 Network 面板 → 找到那个跨域请求 → 点开看 Response Headers 有没有 Access-Control-Allow-Origin；如果没有，后端必须加，前端改不了。如果看到预检（OPTIONS）失败，说明后端没配 Access-Control-Allow-Methods 或 Access-Control-Allow-Headers。
• WebSocket 连接与消息处理：先确保协议匹配（http 页面只能连 ws://，https 页面必须连 wss://）；连接后监听 open 事件再发消息；收到 message 时先判断 event.data 类型（字符串？Blob？ArrayBuffer？），再做对应解析，别直接 console.log 就完事。
避开高频坑点
• Fetch 默认无超时，不手动加 AbortController 或封装逻辑，页面可能卡死几十秒。
• WebSocket 的 onerror 触发后实例已失效，不能复用，必须 new WebSocket() 新建连接；自动重连要加退避策略，不能立即重试。
• 跨域报错时别急着改前端，90% 是后端漏配 CORS 响应头；唯一前端能干预的是加 mode: 'no-cors'，但这会让响应变成 opaque，你读不到任何数据，仅适用于埋点等不需要响应内容的场景。
• SSE（Server-Sent Events）虽也走 HTTP，但它天然支持跨域，只要服务端设置好 Access-Control-Allow-Origin 即可，不需要预检，适合单向实时推送。
