VS Code默认保存为UTF-8 with BOM是HTML中文乱码主因，因BOM（ef bb bf）位于文件开头，导致浏览器在前1024字节内无法扫描到；该标签必须紧贴起始标签后、无任何前置内容（含空格、换行、注释），且仅认全大写“UTF-8”；HTTP响应头Content-Type中charset优先级更高，须确保服务器（如Nginx、Express）显式设置utf-8，所有关联文件（JS/CSS）也须统一用UTF-8无BOM保存。
VS Code 保存时默认带 BOM 是乱码主因
VS Code 新建或保存 HTML 文件时，默认选的是 UTF-8 with BOM，而 BOM（ef bb bf）会卡在文件最开头，导致浏览器在前 1024 字节扫描 meta charset 时直接中断——哪怕你写了 ，它也根本看不到。
- 右下角编码显示为
UTF-8 with BOM就必须改：点击 →Save with Encoding→ 选UTF-8（明确不勾“with BOM”） - 已存在的文件，先点
Reopen with Encoding→UTF-8，再Save with Encoding→UTF-8 - 验证是否清除成功：
xxd -l 4 index.html（Linux/macOS）或Get-Content index.html -Encoding Byte | Select -First 3（PowerShell），输出不含ef bb bf才算干净
它不是“写在 里就行”，而是必须紧贴 开始标签后、没有任何前置内容——包括空格、换行、注释、<script></script> 或 标签。否则浏览器扫描失败，立刻 fallback 到 Windows 默认的 GBK。
- 正确顺序：
... - 错误写法：
\n\n（换行+注释=失效） - 禁用别名：
utf8、UTF8、utf-8都不被 HTML5 规范认可，只认UTF-8（全大写 U T F - 8）
HTTP 响应头里的 Content-Type 优先级高于 meta
当你通过 http:// 或 https:// 访问页面时，服务器返回的 Content-Type: text/html; charset=utf-8 会直接覆盖 HTML 内的 meta 声明。如果响应头没设 charset，或者设成了 gbk，那 meta 就彻底作废。
- Nginx 配置必须写：
charset utf-8;（小写，结尾分号不能少），放在http/server/location块内 - Express.js 中要在
res.send()前加：res.set('Content-Type', 'text/html; charset=utf-8') - 验证方式：F12 → Network → 刷新 → 点 HTML 请求 → Headers → Response Headers → 查
Content-Type值
外部资源（JS/CSS）编码不一致也会连带报错
HTML 页面本身没问题，但引入的 <script src="app.js"></script> 或 是 GBK 编码，浏览器解析时就会卡在中文字符上，报 Uncaught SyntaxError: Invalid or unexpected token 或 CSS 注释解析失败。
- 所有配套文件（.js、.css、.json）都必须统一用
UTF-8（无 BOM）保存 - 验证 JS 文件：
file -i app.js（Linux/macOS），输出应为charset=utf-8 - 不要依赖编辑器“自动识别”：Sublime Text、Notepad++ 等可能误判 GBK 为 UTF-8，务必手动确认并重存
BOM 和响应头缺失是两个最隐蔽的点：一个让 meta 形同虚设，一个让整个 HTTP 层绕过你的声明。改完 VS Code 设置和 Nginx 配置后，记得用 xxd 和 Network 面板双验，缺一不可。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
