Fetch 的 mode 参数定义请求-响应链在 CORS 机制下的行为边界：cors 要求服务端返回合法 CORS 头且允许读取响应；no-cors 发送不透明请求，无法读取响应；same-origin 禁止跨域，URL 不同源则直接报错。
Fetch 的 mode 参数直接决定浏览器是否允许跨域请求、是否携带凭据、以及响应能否被脚本读取。它不是“开关”，而是定义整个请求-响应链在 CORS 机制下的行为边界。
mode: "cors" —— 标准跨域安全通道
这是显式跨域请求的默认且推荐模式（除非你手动设为其他值）。它要求：
- 请求自动带上
Origin请求头 - 服务端必须返回合法的 CORS 响应头，如
Access-Control-Allow-Origin - 若未返回匹配的 CORS 头，浏览器直接拒绝响应（JavaScript 拿不到 status 或 body）
- 响应体可被读取，但仅限于 CORS 允许暴露的响应头（如需自定义头，服务端需设置
Access-Control-Expose-Headers）
mode: "no-cors" —— 只发不收，降级为“不透明”请求
该模式下浏览器仍会发出请求，但强制将其视为“不透明响应”：
- 请求不会携带
Origin，服务端无法识别为 CORS 请求（常被当作普通请求处理） - 响应状态始终为 0，statusText 为空，body 无法读取（
response.text()等方法抛错） - 唯一可用信息是
response.type === "opaque"和response.redirected - 适用于纯“打点”或埋点场景（例如上报日志），不依赖响应内容
mode: "same-origin" —— 跨域即报错，强制同源约束
此模式禁止任何跨域请求：
- 若 URL 协议、域名、端口任一不同，fetch 直接 reject（TypeError: Failed to fetch）
- 不发送网络请求，也不触发 CORS 预检
- 适合严格隔离前端资源访问范围，比如只允许调用自身后端 API
与 credentials 配合的关键细节
mode 必须和 credentials 协同使用才安全有效：
- 当
mode: "cors"且credentials: "include"时：服务端必须返回Access-Control-Allow-Origin: *❌（不允许通配符），而必须指定具体源，例如https://example.com -
credentials: "same-origin"（默认值）表示：同源时自动带 cookie，跨源时绝不带 -
mode: "no-cors"下credentials只能是"omit"或"same-origin"，设为"include"会报错
不复杂但容易忽略：mode 不是绕过 CORS 的手段，而是明确告诉浏览器“你想怎么参与 CORS 流程”。选错 mode，轻则拿不到数据，重则请求根本发不出或被静默拦截。
