乱码本质是浏览器用错编码读取字节，只要原始字节完整，90%以上可修复；需同步确保文件真实编码为无bom utf-8、紧贴开头无前置内容、http响应头content-type声明charset=utf-8三者严格一致。
乱码不是“文字坏了”，而是浏览器用错了编码去读取字节。只要原始 HTML 文件里中文的字节还完整，90% 以上能修好。
确认文件实际保存编码（别信编辑器右下角显示）
VS Code 右下角写着 “UTF-8”，不代表文件真是 UTF-8；它可能被另存为 GBK 后又没改显示设置，导致你看到的是“假 UTF-8”。必须验证字节本身：
- Linux/macOS：运行
file -i index.html或head -c 4 index.html | xxd，若输出含ef bb bf就是 UTF-8-BOM；若显示charset=iso-8859-1或charset=us-ascii，大概率是 GBK/ANSI 被误判 - Windows PowerShell：
Get-Content index.html -Encoding Byte | Select -First 3，结果为239 187 191即 BOM - 用 Notepad++ 打开 → 编码菜单 → 查看当前识别结果（灰色文字），再点“转为 ANSI”或“转为 UTF-8”对比显示效果
<meta charset> 必须紧贴
浏览器只扫描 HTML 前 1024 字节找 <meta charset>，一旦前面有空格、BOM、注释或换行，就直接跳过——然后 fallback 到系统默认编码（Windows 是 GBK，Linux/macOS 是 ISO-8859-1），必然乱码。
- 正确写法（
后第一行，无空行、无注释、无 BOM）：<meta charset="UTF-8"><title>页面标题</title>
- 错误写法举例：
<!-- 注释 --><meta charset="UTF-8">、\n<meta charset="UTF-8">、<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> - HTML5 只认
<meta charset="UTF-8">；<meta http-equiv="Content-Type">已废弃，且在多数现代浏览器中不生效
HTTP 响应头 Content-Type 优先级高于 <meta>
当你用 http:// 或 https:// 访问（而非双击打开 file://），服务器返回的 HTTP 响应头里的 Content-Type 会盖过 <meta charset>。如果 Nginx/Apache/Express 返回的是 text/html; charset=gbk 或压根没声明 charset，<meta> 就无效。
- 检查方式：F12 → Network → 刷新 → 点 HTML 请求 → Headers → Response Headers → 查
Content-Type - Nginx 配置加：
charset utf-8;（注意不是add_header） - Express 中，在
res.send()前加：res.set("Content-Type", "text/html; charset=utf-8"); - Python
http.server或 VS Code Live Server 默认不发 charset 头，此时<meta>生效；但生产环境务必配服务端头
避免 BOM 和编辑器自动插入干扰
UTF-8-BOM 在 Windows 编辑器里很常见，但它会卡在 <meta> 前面，让浏览器找不到 charset 声明。更隐蔽的是某些模板引擎（EJS、Thymeleaf）会在 前注入空格或换行。
- VS Code 保存时选 “Save with Encoding” → “UTF-8”（不要选 “UTF-8 with BOM”）
- Sublime Text / Notepad++ 同理，明确取消 BOM 选项
- 删掉
前所有空白、注释、PHP/JS 模板语句；用文本编辑器十六进制模式确认开头三个字节不是ef bb bf - 如果用了构建工具（Vite、Webpack），检查 HTML 插件是否自动注入了额外内容
最常被忽略的一点：乱码修复不是“改一个地方就行”，而是文件编码、<meta> 位置、HTTP 响应头三者必须严格一致。少一个，浏览器就退回到系统默认编码——而那个默认值，你根本没法控制。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
