必须同步校准声明、文件编码、http响应头三者为utf-8无bom：meta标签需位于head首位置且唯一；文件须存为utf-8无bom；服务器响应头content-type必须为text/html; charset=utf-8。
直接在 里写 <meta charset="UTF-8"> 是必须的，但仅靠这一行远远不够。乱码本质是“声明、文件本身、传输过程”三者不一致。要彻底解决，得同步校准这三环。
一、<meta charset="UTF-8"> 必须放对位置且唯一
这个标签不是可有可无的装饰，而是浏览器解析页面的“第一指令”。它必须：
- 位于
内，且是中第一个非空白、非注释的子元素（理想位置：紧跟开始标签后）； - 写法严格为
<meta charset="UTF-8">—— 不接受utf8、UTF-8（带短横）、utf_8等任何变体； - 整个 HTML 文件中只允许存在一个 charset 声明，删除所有旧式写法如
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">； - 前面不能有任何字符：包括空格、换行、HTML 注释
<!-- -->，甚至不可见的 BOM 字节。
二、HTML 文件本身必须是 UTF-8 无 BOM 编码
声明说的是“我用 UTF-8”，但如果文件实际存的是 GBK 或带 BOM 的 UTF-8，浏览器就会按声明去“硬解”错误字节，结果必乱。
- 在 VS Code 中：右下角点击编码显示（如 “GBK” 或 “UTF-8 with BOM”），选 “Save with Encoding” → “UTF-8”（注意不是 “UTF-8 with BOM”）；
- 在 Notepad++ 中：菜单栏“编码” → “转为 UTF-8 编码”（不是 “UTF-8-BOM”）；
- 命令行快速验证：运行
xxd -l 4 yourfile.html，若输出含ef bb bf，说明存在 BOM，需清除后重存； - 避免使用老版 Windows 记事本保存，它默认添加 BOM 且不提示。
三、HTTP 响应头中的 Content-Type 具有最高优先级
当网页通过 HTTP 协议加载（即地址是 http:// 或 https://），服务器返回的响应头中 Content-Type 字段会覆盖 HTML 内的 meta 声明。哪怕你 meta 写得再标准，如果响应头是 Content-Type: text/html; charset=gbk，浏览器照样用 GBK 解析，中文全乱。
- 按 F12 打开开发者工具 → Network 标签 → 刷新页面 → 找到主 HTML 请求 → 点开看 Response Headers → 检查
Content-Type值； - 正确值应为：
text/html; charset=utf-8； - Apache 用户：在站点根目录加
.htaccess，写入AddDefaultCharset UTF-8； - Nginx 用户：在
server或location块中添加charset utf-8;； - Node.js/Express 用户：路由响应前加
res.set('Content-Type', 'text/html; charset=utf-8');。
四、额外检查点：别让其他环节悄悄破坏
有些问题容易被忽略，却直接导致前功尽弃：
- CSS 或 JS 外部文件也需确保自身是 UTF-8 无 BOM 编码，否则其中的中文注释或字符串也会乱；
- 构建工具（如 Vite、Webpack）插件可能误删或重写 meta 标签，检查 HTML 插件配置，禁用可能干扰
<meta>的压缩选项； - VS Code 设置中关闭自动猜编码：
"files.autoGuessEncoding": false，防止打开时误判； - 本地双击打开（
file://协议）时，浏览器不读响应头，只依赖 meta，此时前三步仍有效；但上线后务必走 HTTP 并校验响应头。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
