meta charset="UTF-8"必须置于<head>最开头、<title>之前，且前面不能有任何字符（含空格、换行、注释、BOM），否则浏览器仅扫描前1024字节并中断，fallback至系统默认编码（如Windows的GBK）导致中文乱码。
meta charset="UTF-8" 必须放在 <head> 开头、<title> 之前，且前面不能有任何字符（包括空格、换行、注释、BOM）。这是单页 HTML 应用（SPA）避免乱码的底线要求。
为什么 SPA 更容易出字符集问题
单页应用依赖 JS 动态渲染内容，一旦字符集错位，console.log("你好") 会直接报 Uncaught SyntaxError: Invalid or unexpected token；fetch() 返回的中文响应体也可能变成乱码；甚至 <script type="module"> 因首字节解析失败而整个不执行。
- HTML 文件本身编码 ≠
meta charset声明值 —— 若文件实际存为 GBK，但写了meta charset="UTF-8"，浏览器会强行用 UTF-8 解 GBK 字节，结果全是 - SPA 常含内联
<script>或模板字符串（如`<div>用户：${name}</div>`），这些文本直读源码，对编码零容忍 - 构建工具（如 Vite、Webpack）可能忽略 HTML 源文件编码，把 GBK 源码当 UTF-8 读入再输出，导致“声明对、文件错、结果崩”
检查并修复 HTML 文件实际编码
别只看 meta 标签——先确认文件磁盘上真是 UTF-8：
- VS Code：右下角点击编码名称（如 “GBK”），选
Reopen with Encoding→UTF-8；再点一次，选Save with Encoding→UTF-8（**不要选 “UTF-8 with BOM”**，BOM 会卡在<head>最前，让meta失效） - 命令行验证（macOS/Linux）：
file -i index.html应输出charset=utf-8；或head -c 4 index.html | xxd，若开头是ef bb bf就是带 BOM 的 UTF-8，需清除 - Windows PowerShell：
Get-Content index.html -Encoding Byte | Select -First 3，若返回239, 187, 191即 BOM，应删掉
HTTP 响应头必须与 meta 一致
本地双击打开（file://）时只认 meta；但 SPA 部署后走 HTTP，此时 Content-Type 响应头优先级高于 meta。两者不一致，document.characterSet 会返回响应头指定的值，而非你写的 UTF-8。
立即学习“前端免费学习笔记（深入）”；
- Nginx 配置加一行：
charset utf-8;（放在server或location块内） - Apache 在
.htaccess加：AddDefaultCharset UTF-8（注意不是UTF8） - Vercel/Netlify 默认发
charset=utf-8，无需操作；但自建 Node.js 服务（如 Express）需显式设置：res.set('Content-Type', 'text/html; charset=utf-8') - 验证方式：DevTools → Network → 刷新 HTML 请求 → 查
Response Headers中Content-Type是否含charset=utf-8
连带资源（JS/CSS）也得统一 UTF-8
单页应用里，<script src="app.js"> 或 <link href="style.css"> 若自身文件不是 UTF-8，照样触发乱码——比如 JS 里写 alert("提交成功")，文件存为 GBK，浏览器按 UTF-8 解就崩。
- 所有 .js、.css 文件同样要用编辑器保存为 UTF-8（无 BOM）
- 构建产物（如 Vite 打包后的
assets/index.xxxx.js）默认 UTF-8，但若源码含非 ASCII 字符且输入法打错、或复制粘贴进乱码文本，仍会继承错误 - 内联
<script>和<style>内容，完全依赖 HTML 文件编码，所以 HTML 编码错，它们必然错
最常被跳过的环节是：改了 meta charset，却没重存 HTML 文件；或者清了 BOM，又忘了同步 JS/CSS 文件编码。字符集问题从不单独存在，它是一整条链路上的编码共识——断一环，全盘静默失效。
