核心方案是用response.arraybuffer()获取原始字节流，再用textdecoder('gbk')解码；因fetch的res.text()默认且仅按utf-8解码，无视content-type中的charset=gbk，导致gbk接口返回中文变“锟斤拷”。
HTML跨域请求本身不涉及“设置编码”，真正要处理的是响应体解码失败和字符乱码问题——根源在服务端返回的Content-Type头缺失charset、HTML文件自身编码不一致，或fetch未正确解析响应流。
为什么fetch('/api/data')返回中文变???
这不是跨域配置问题，而是浏览器拿到响应后不知道用什么编码去 decode 字节流。常见现象：接口明明返回{"name": "张三"}，但await res.json()报错，或await res.text()显示乱码。
- 先确认服务端是否在
Content-Type响应头里声明了charset=utf-8，例如：Content-Type: application/json; charset=utf-8；Spring Boot 默认会加，但若用ResponseEntity<byte></byte>或手动写输出流就可能漏掉 - 检查 HTML 页面自身的编码是否为 UTF-8：
<meta charset="UTF-8">必须存在且位于内，且文件保存时也得是 UTF-8（无 BOM 更稳妥） - 不要依赖
res.text()后手动decodeURIComponent——那是 URL 编码，不是字符集解码
fetch跨域请求中response.text()和response.json()的编码差异
response.text()和response.json()底层都调用response.arrayBuffer()再按编码解析，但策略不同：
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
-
response.text()优先读取响应头Content-Type里的charset，没声明则 fallback 到 UTF-8；若服务端返回text/plain却没带charset，就容易按系统默认编码（如 Windows-1252）解，导致乱码 -
response.json()强制按 UTF-8 解码（规范要求），所以即使Content-Type写错或缺失charset，只要响应体真是 UTF-8 编码的 JSON，它通常能成功；但若后端误用 GBK 输出 JSON，json()必报Unexpected token - 遇到
json()失败但text()能取到字符串时，用console.log(escape(resText))看是否含%u或乱码字节，可快速判断是不是编码错配
本地file://协议下fetch永远乱码的根本原因
双击打开的file://页面，浏览器不会发送Origin头，服务端无法识别请求来源，多数 API 网关或框架会直接返回 403 或 HTML 错误页（比如 Nginx 默认 403 页面是 GBK 编码的），这时fetch拿到的是 HTML 字节流，却当 JSON 解，必然失败。
- 这不是编码设置问题，是协议层被拦：必须用
http://localhost:8000这类本地服务器启动 HTML，才能触发标准 CORS 流程并拿到真实 API 响应 - VS Code 的 Live Server、
npx serve -s、python3 -m http.server都行，关键是要让页面运行在 HTTP 协议下 - 哪怕只是临时调试，也别用
--disable-web-security启动 Chrome——它绕过的是同源策略，不修复响应编码问题，且无法复现真实环境行为
后端返回非JSON内容却伪装成application/json时的陷阱
有些后端在异常时返回 HTML 错误页（如 Spring Boot 的 Whitelabel Error Page），但响应头仍设Content-Type: application/json;charset=UTF-8，前端res.json()就会解析失败，错误信息却是Unexpected token 。
- 在
fetch后先检查res.status是否在 200–299 范围，再调json()；否则用res.text()看原始内容 - 后端应统一错误响应格式，避免返回 HTML；Spring Boot 可配
server.error.whitelabel.enabled=false关掉默认错误页 - 若必须兼容旧接口，可在
catch里对TypeError做二次判断：if (err.message.includes('Unexpected token
最易被忽略的一点：Nginx 反向代理时，若没透传Content-Type头或自行重写了该头，会导致上游服务返回的charset丢失。务必检查代理配置里是否有proxy_pass_request_headers on;和未覆盖Content-Type的add_header指令。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
