Fetch 不强制 HTTPS，但 HTTPS 页面中禁止 HTTP 请求；默认不带 Cookie，需设 credentials: 'include'；无内置超时，须用 AbortController；响应需手动调用 await res.json() 解析。
Fetch 必须用 HTTPS 吗？
不是必须，但现代浏览器对 fetch 有明确的混合内容限制：在 HTTPS 页面中，fetch 不能发起 HTTP 请求（会直接被浏览器拦截，控制台报 Mixed Content: The page at 'https://...' was loaded over HTTPS, but requested an insecure resource 'http://...'）。HTTP 页面里倒是可以发 HTTP 请求，但绝大多数生产环境已是 HTTPS，所以实际开发中基本等同于“必须走 HTTPS”。
例外情况：localhost 和 127.0.0.1 下，即使页面是 HTTP，fetch 也能发 HTTP 请求——这是浏览器为本地开发留的后门，别误以为线上也行。
Fetch 默认不带 Cookie，怎么让它带？
fetch 默认的 credentials 策略是 'omit'，也就是完全不发 Cookie。这和传统 XMLHttpRequest 的默认行为不同，容易导致登录态丢失、401 报错。
- 要携带 Cookie（且服务端需设
Access-Control-Allow-Credentials: true），必须显式传{ credentials: 'include' } - 如果只在同域下用，
'same-origin'更安全，它只在同源时发 Cookie -
'omit'是默认值，适合公开接口、无需鉴权的场景
示例：
fetch('/api/user', { credentials: 'include' })
Fetch 超时控制只能靠 AbortController 吗？
是的。fetch 本身没有 timeout 参数，也不能用 setTimeout 直接中断请求（Promise 无法外部取消）。必须用 AbortController 配合 signal 选项。
常见坑：
- 创建
AbortController后忘记调用abort()，会导致内存泄漏（尤其在 React 组件卸载时） - 超时时间设太短（比如 300ms），可能误伤正常慢网用户；设太长（如 30s）又影响体验
- 后端返回 504 或连接中断时，
fetch会直接 reject，但不会触发abort()，所以超时逻辑和网络错误要分开处理
示例：
const controller = new AbortController();<br>setTimeout(() => controller.abort(), 5000);<br>fetch('/api/data', { signal: controller.signal })<br> .catch(err => { if (err.name === 'AbortError') console.log('请求超时'); });
JSON 接口响应体没自动解析，为什么？
fetch 返回的是 Response 对象，不是解析后的数据。response.json() 是一个异步方法，必须手动调用，且它只读一次——重复调用会抛 TypeError: Already read。
典型错误写法：
const res = await fetch('/api');<br>console.log(res.json()); // 输出 Promise，不是数据<br>const data = res.json(); // ❌ 忘了 await
正确做法：
const res = await fetch('/api');<br>if (!res.ok) throw new Error(res.statusText);<br>const data = await res.json(); // ✅ 必须 await
注意：res.json() 会校验 Content-Type 是否含 application/json，否则报错。后端返回 text/plain 却塞 JSON 字符串时，得用 res.text() 再 JSON.parse()。
实际项目里最常漏掉的是 credentials 和 signal，其次是把 res.json() 当同步函数用。这些不是“高级技巧”，而是日常请求能跑通的前提。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
