fetch是浏览器发起的promise型请求，由浏览器拦截（cors）、控制（如credentials、mode），设计上剥离超时/重试等策略以保持底层简洁；cors是浏览器单方面实施的安全限制，服务端无感知；websocket绕过同源策略因协议独立于http，握手后通信不受origin校验约束。
JS 中关于 Fetch、CORS、WebSocket 的面试题，核心不是背定义，而是讲清“谁发起、谁拦截、谁控制、为什么这样设计”。面试官想听的是你对浏览器安全模型和通信机制的理解深度，而不是罗列解决方案。
Fetch 的本质与高频陷阱
Fetch 是浏览器原生的 Promise-based 网络请求 API，但它默认不带 Cookie，也不遵循传统表单的 content-type 自动设置逻辑。很多候选人一上来就说“Fetch 比 XHR 更现代”，却答不出关键差异。
- 必须显式配置 credentials: 'include' 才能携带 Cookie（且服务端需配合设置 Access-Control-Allow-Credentials: true）
- Fetch 的 错误处理有误导性：网络断开、超时、DNS 失败会 reject；但 HTTP 状态码如 404、500 仍会 resolve，需手动检查 response.ok 或 response.status
- 没有原生的 progress 事件（不像 XHR），上传进度需借助 ReadableStream + pipeThrough 或后端分块返回
CORS 的运行时机与常见误区
CORS 是浏览器实施的限制，服务端完全不知情。每次跨域请求（只要触发了预检条件）都会发出 OPTIONS 请求，但这个预检只由浏览器发起，服务端响应后，浏览器才决定是否放行后续真实请求。
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
- 预检触发条件有三个同时满足：非简单请求（如 Content-Type: application/json）、自定义 header（如 X-Trace-ID）、或使用了除 GET/HEAD/POST 外的方法
- Access-Control-Allow-Origin 不能设为 * 时再配 credentials: true —— 这是硬性限制，否则浏览器直接报错
- 很多人混淆“跨域请求是否到达服务端”：它一定到达了，只是浏览器在收到响应后，根据响应头决定是否把结果交给 JS 脚本
WebSocket 为什么能绕过同源策略
因为 WebSocket 协议本身不属于 HTTP 同源策略的管辖范围。它的握手阶段用的是 HTTP Upgrade 请求，但一旦建立连接，后续通信就是基于 TCP 的全双工二进制/文本帧，不再受浏览器的 Origin 校验约束。
- 连接时仍需指定完整 ws:// 或 wss:// URL，但浏览器不会因跨域拒绝建立连接
- 服务端仍可自行校验 Origin 请求头（非强制），用于业务层防护，但这属于应用逻辑，不是浏览器行为
- 适合替代轮询或 SSE 的场景：低延迟、双向实时（如聊天、协作编辑、行情推送）
三者如何组合使用更合理
实际项目中它们不是互斥选项，而是分工明确：
- Fetch 用于常规 CRUD 和页面初始化数据拉取（状态明确、一次交互）
- CORS 是 Fetch 跨域时的配套服务端配置方案，不是独立技术，要一起讲
- WebSocket 用于长连接、服务端主动推送、状态持续同步，不适用于短平快请求
- 注意：不要用 WebSocket 去做登录态校验——它不自动携带 Cookie，首次连接需通过 query 或 token 传参，后续靠服务端维护连接上下文
