确认index.html实际编码是否为utf-8（含不含bom）：linux/macos用file -i index.html看charset；windows powershell用get-content -encoding byte | select -first 3查是否输出239 187 191（即ef bb bf）；vs code右下角显示≠真实编码，需“reopen with encoding”试读再“save with encoding”选utf-8（无bom）。
index.html 文件出现中文乱码，基本可以断定是字符编码链断裂——文件实际编码、HTTP 响应头、<meta charset> 三者至少有一处不一致或缺失，且未在解析窗口内被正确识别。
怎么确认 index.html 实际编码是否为 UTF-8（含不含 BOM）
浏览器不会读取文件后缀或编辑器状态，只认字节。你看到“乱码”，往往是因为文件本身存的是 GBK 字节，却用 UTF-8 解析；或者存的是 UTF-8-BOM，但 BOM 被误判为垃圾字符导致 <meta charset="UTF-8"> 失效。
- Linux/macOS：运行
file -i index.html，输出中charset=utf-8表示 UTF-8（不含 BOM），charset=utf-8-with-bom或charset=unknown-8bit+ef bb bf开头则大概率含 BOM - Windows PowerShell：运行
Get-Content index.html -Encoding Byte | Select -First 3，若输出为239 187 191，即十六进制ef bb bf，说明有 BOM - VS Code 状态栏右下角显示 “UTF-8” ≠ 文件真是 UTF-8；它可能只是按 UTF-8 解释了一堆 GBK 字节。此时点击状态栏编码名 → 选 “Reopen with Encoding” → 依次试 GBK / ISO-8859-1 / UTF-8，看哪一种能正常显示中文，再用 “Save with Encoding” → 选 “UTF-8”（**不是 “UTF-8 with BOM”**）另存
<meta charset="UTF-8"> 为什么写了也不生效
这个标签只有在被 HTML 解析器「最早读到」时才起作用。它必须出现在 的最开头，且前面不能有任何不可见字符（BOM、空格、换行、HTML 注释 <!-- -->）。
- 常见失效场景：
前有 BOM（ef bb bf）、空行、<script></script>、<link>、甚至一个全角空格（U+3000） - HTML 解析器只扫描前 1024 字节找
charset，一旦在这范围内遇到非 ASCII 字符（比如 BOM 或注释里的中文），就放弃解析<meta charset>，退回到系统默认编码（Windows 是 GBK，Linux/macOS 是 ISO-8859-1） - 不要写
<meta charset="utf8">或<meta charset="UTF8">—— 必须是UTF-8（带短横线），否则部分旧浏览器和工具会忽略 - 绝对不要混用：
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">是 HTML4 写法，HTML5 已废弃；同时写两个 meta，只有第一个可能被识别
HTTP 响应头 Content-Type 比 <meta> 更优先
当通过 http:// 或 https:// 访问时，服务器返回的 HTTP 响应头中的 Content-Type: text/html; charset=xxx 具有最高优先级。哪怕 <meta charset="UTF-8"> 写得再规范，只要响应头里是 charset=gbk，浏览器就一定用 GBK 解析。
- Chrome/Firefox：F12 → Network → 刷新 → 点击
index.html→ 查看 “Response Headers” 下的Content-Type值 - Nginx：在
server或location块中加charset utf-8;（注意不是add_header Content-Type，那会重复 header） - Apache：在
.htaccess或配置中加AddDefaultCharset UTF-8 - Node.js/Express：在
res.send()或res.sendFile()前调用res.set('Content-Type', 'text/html; charset=utf-8') - PHP：在任何输出（包括空白、
<?php前空格）之前调用header('Content-Type: text/html; charset=utf-8');
静态文件直连 file:// 时只能靠 <meta>
双击打开或用 file:// 协议访问时，没有 HTTP 响应头，浏览器完全依赖 <meta charset> 和文件自身字节。这是最容易出问题的场景，也是验证编码是否真正干净的“压力测试”。
- 必须确保
index.html文件本身是纯 UTF-8（无 BOM），且<meta charset="UTF-8">是中第一个非空白、非注释的标签 - 所有关联资源（
.js、.css）也必须是 UTF-8 编码，否则 JS 报Uncaught SyntaxError: Invalid or unexpected token，CSS 注释乱码导致样式异常 - 避免用 VS Code 默认保存为 “UTF-8 with BOM” —— Windows 版 VS Code 默认开启该选项，极易踩坑；务必手动选 “UTF-8”（无 BOM）保存
- 开发阶段别双击打开，用
python3 -m http.server或 VS Code Live Server 插件，它们会自动注入正确的Content-Type响应头
BOM 是最隐蔽的破坏者：它看不见、删不掉（普通编辑器不显示）、却能让整个编码链崩塌。确认无 BOM + <meta> 在 顶格 + HTTP 响应头明确声明，这三点缺一不可。多数人只改了其中一点，就以为问题解决了，结果换个环境又乱码——因为另外两点没对齐。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
