mode: "cors" 是声明走完整cors流程，能否成功取决于后端是否返回合法access-control-allow-origin等响应头；mode: "no-cors" 仅允许简单请求且响应为opaque，无法读取状态码、响应体等，仅适用于单向上报等无需响应的场景。
mode: "cors" 不等于“能跨域”，mode: "no-cors" 也不等于“能绕过跨域”——它俩根本不是同一类操作，选错一个，请求就卡在浏览器里或拿不到数据。
mode: "cors" 是标准跨域流程的声明，不是开关
它告诉浏览器：“我要走完整 CORS 流程”，但能否成功，完全取决于后端是否返回合法响应头：
-
Access-Control-Allow-Origin必须存在且匹配当前源（带credentials: "include"时不能是*） - 若带自定义 header（如
Authorization）、非简单Content-Type（如application/json），浏览器会先发OPTIONS预检；服务端必须正确响应该预检，否则主请求根本不会发出 -
mode: "cors"是 fetch 默认值（仅限无 credentials 场景），显式写出主要是防误配、增强可读性 - 错误现象：控制台报
Blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present或preflight is invalid—— 这说明请求甚至没到后端，浏览器已拦截
mode: "no-cors" 只发不收，响应不可读
它让浏览器跳过 CORS 检查，但代价是把响应降级为 opaque（不透明）：
-
response.type恒为"opaque"，response.status恒为0，response.headers为空，response.json()和response.text()全部抛TypeError - 只允许简单请求：方法限
GET/HEAD/POST，header 仅支持Accept、Content-Type（值只能是application/x-www-form-urlencoded、multipart/form-data、text/plain）——其他 header（如Authorization）会被浏览器直接丢弃 - 常见误用：加了
mode: "no-cors"还想await response.json()，结果报错；或以为加了就能传 token，实际 header 已被抹掉 - 唯一合理场景：埋点上报、触发 Webhook、加载第三方像素（类似
<img src="...">），即“发完就不管返回”的单向通信
same-origin 模式下跨域请求直接失败
这不是跨域方案，而是隔离策略：
- 只要 URL 协议、域名、端口任一不同，fetch 立即 reject，抛出
TypeError: Failed to fetch，不发网络请求，也不触发预检 - 适用于严格限制前端只能调自身 API 的场景，比如内部管理后台禁用一切外部接口
- 错误示范：
fetch("https://api.example.com/data", { mode: "same-origin" })在https://myapp.com页面中必然失败
credentials 和 mode 必须协同配置
两者配错，轻则 cookie 不发，重则请求被静默降级或报错：
-
mode: "cors"+credentials: "include"→ 后端Access-Control-Allow-Origin必须写具体域名，不能是* -
mode: "no-cors"下credentials只能是"omit"或"same-origin"；设"include"会直接报错 -
credentials: "same-origin"（默认）表示：同源自动带凭证，跨源绝不带——所以跨域时即使没写credentials，也不会发 cookie
真正容易被忽略的点是：mode 不是“解决跨域”的手段，而是你向浏览器申明“你想怎么参与跨域协议”。它不改变服务器行为，只改变浏览器对响应的处理权限。需要读响应？必须走 cors 并确保后端配合；只需要发个请求？no-cors 才有意义，但得接受拿不到任何返回信息。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
