乱码主因是meta charset位置错误、文件实际编码不匹配或http响应头覆盖：必须确保位于最开头（无bom/空格/注释）、文件真实为无bom utf-8、http响应头content-type含charset=utf-8，三者缺一不可。
乱码不是编码没设，而是 <meta charset="UTF-8"> 没站对位置、文件实际编码不匹配、或 HTTP 响应头压过了它——三者只要缺一，中文就大概率变问号、方块或乱码符号。
检查 <meta charset="UTF-8"> 是否在
浏览器只扫描 HTML 前 1024 字节找 charset 声明，一旦前面有 BOM、空格、注释、甚至不可见的零宽空格（），它就直接跳过， fallback 到系统默认编码（Windows 是 GBK，Linux/macOS 是 ISO-8859-1）。
- 打开 VS Code，右下角状态栏确认显示的是
UTF-8（不含 “with BOM”） - 按
Ctrl+Shift+P→ 输入Change File Encoding→ 选Save with Encoding→UTF-8 - 手动删掉
之前所有内容，包括注释<!-- -->、空行、缩进空格 - 确保代码是这样：
<meta charset="UTF-8"><title>测试页</title>
别写成 <meta charset="utf8"> 或 <meta charset="UTF8"> —— 只有 UTF-8 是标准值。
验证 HTML 文件实际保存为 UTF-8（无 BOM）
编辑器显示“UTF-8”不等于文件真是 UTF-8；很多编辑器（尤其 Windows 下的 Notepad++、旧版 Sublime）默认存为 UTF-8 with BOM，而 BOM（EF BB BF）会卡在文件开头，让 <meta> 失效。
- Linux/macOS 终端执行：
head -c 4 index.html | xxd，如果输出含ef bb bf，说明有 BOM，需清除 - Windows PowerShell 执行：
Get-Content index.html -Encoding Byte | Select -First 3，同理看是否为239, 187, 191 - VS Code 中：右下角点编码 →
Reopen with Encoding→UTF-8→ 再Save with Encoding→UTF-8（注意两次都选纯 UTF-8）
排查 HTTP 响应头是否覆盖了 <meta>
当页面通过 http:// 或 https:// 访问时，服务器返回的 Content-Type 响应头优先级高于 <meta>。如果它写着 charset=gbk 或没声明 charset，<meta> 就被无视。
- F12 → Network → 刷新页面 → 点 HTML 请求 → 查看
Response Headers中的Content-Type - 正确值应为：
text/html; charset=utf-8（注意utf-8小写，带连字符） - Nginx 配置需加：
charset utf-8;（在server或location块内） - Express 中需在
res.send()前调用：res.set('Content-Type', 'text/html; charset=utf-8'); - Apache 的
.htaccess加：AddDefaultCharset UTF-8
双击打开 HTML 文件（file://）时只靠 <meta> 生效
本地双击 HTML 文件没有 HTTP 服务，也就没有响应头，此时唯一生效的是 <meta charset="UTF-8"> —— 它必须存在、位置正确、且文件本身是 UTF-8 编码。
- 不要依赖浏览器“重新编码”菜单强行切换，那只是临时渲染，不解决根源
- VS Code 安装
Live Server插件，右键 →Open with Live Server，模拟真实 HTTP 环境 - 避免用记事本直接编辑并保存 HTML：它默认存 GBK，哪怕你写了
<meta charset="UTF-8">，文件内容实际是 GBK 字节，浏览器按 UTF-8 解就会错
最易被忽略的是：文件编码、meta 位置、HTTP 响应头这三项必须全部对齐；任一环节脱节，乱码就立刻复现，而且往往只在某个环境（比如上线后、某个浏览器、某台电脑）才暴露。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
