关键在于区分环境：浏览器中fetch.text()自动依Content-Type解码，Node.js则默认仅UTF-8解码，对GBK等必乱码；Node需用arrayBuffer+iconv-lite手动转码。
在 JavaScript Fetch API 中处理文本编码转换乱码问题，关键在于区分运行环境：浏览器中 response.text() 会自动依据响应头的 Content-Type（含 charset）解码；而 Node.js 环境下默认只按 UTF-8 解码，对 GBK、GB2312 等中文编码网页必然乱码。解决思路是绕过自动文本解码，改用二进制方式读取再手动转码。
浏览器环境：通常无需手动干预
现代浏览器的 fetch 已内置 charset 感知能力：
- 若响应头含
Content-Type: text/html; charset=gbk，res.text()会自动用 GBK 解码 - HTML 中
<meta charset="gb2312">不影响fetch解码逻辑，仅指导浏览器渲染 - 如遇乱码，优先检查服务器是否正确设置了
Content-Type响应头
Node.js 环境：必须用 ArrayBuffer + iconv-lite
node-fetch 不支持自动识别非 UTF-8 编码，需手动处理字节流：
- 安装依赖：
npm install iconv-lite - 用
res.arrayBuffer()获取原始字节，而非res.text() - 将 ArrayBuffer 转为 Node.js Buffer，传给
iconv.decode(buffer, 'gbk') - 常见编码参数：`'gbk'`、`'gb2312'`、`'big5'`、`'windows-1252'` 等
通用技巧：如何判断网页真实编码
不能只看 meta 标签或响应头，要交叉验证：
立即学习“Java免费学习笔记（深入）”；
- 用开发者工具查看 Network → Response Headers 的
Content-Type字段 - 检查 HTML 源码中
<meta http-equiv="Content-Type">或<meta charset> - 对疑似乱码内容，尝试用不同编码解码后观察中文是否连贯、标点是否正常
- 小段文本可用在线编码检测工具辅助，但长网页建议以响应头为准
避免二次乱码：后续操作保持编码一致
解码成功后，所有字符串操作都基于 JavaScript 内部的 UTF-16 表示，无需再“转码”：
- 不要对已解码的字符串再次调用
encodeURIComponent或TextEncoder后又误用TextDecoder - 保存到文件时，明确指定写入编码（如用
fs.writeFileSync(path, html, 'utf8')） - 若需发送回服务端，URL 参数用
encodeURIComponent()，POST body 用JSON.stringify()或设置对应Content-Type头
