乱码主因是meta charset、文件保存格式、http响应头三者未统一为utf-8（无bom）；必须紧贴开头，前不可有bom、空格、注释或脚本，否则浏览器仅在前1024字节内查找而失效。
乱码不是“页面没写好”，而是编码链路上至少有一环没对齐。只要 meta charset、文件保存格式、HTTP 响应头三者中有一个不一致，中文就可能变成 、□ 或一串乱码字母。
为什么 meta charset="UTF-8" 放在
浏览器解析 HTML 时，只在前 1024 字节内找 meta charset。如果它前面有注释、空格、BOM 头、或一段未闭合的 <script></script>，就可能跳过它，退回到系统默认编码（比如 Windows-1252）——这时即使写了 UTF-8，也无效。
- 必须把
<meta charset="UTF-8">放在的最开头，紧贴开始标签，前面不能有任何字符（包括 BOM、空行、HTML 注释） - 用 VS Code 或 Notepad++ 检查文件是否带 BOM：右下角状态栏看编码显示，如果是
UTF-8 with BOM，要转成UTF-8（无 BOM） - 避免在
<meta charset>前写<script></script>或<style></style>——哪怕只是空标签也不行
HTTP 响应头里的 Content-Type 比 meta 更优先
如果服务器返回的 HTTP 响应头里写着 Content-Type: text/html; charset=GBK，浏览器会直接忽略 HTML 里的 meta charset，按 GBK 解析——结果就是 UTF-8 写的中文全变乱码。
- 打开浏览器开发者工具 → Network → 刷新页面 → 点 HTML 文件 → 查看 Response Headers 中的
Content-Type - Nginx 配置需加：
charset utf-8;（注意小写，且不能写成UTF-8） - Apache 需在
.htaccess或配置中加：AddDefaultCharset UTF-8 - Node.js（Express）要用：
res.set('Content-Type', 'text/html; charset=utf-8')，注意utf-8小写
编辑器保存格式和实际传输格式必须一致
你在 VS Code 里选了 UTF-8，但文件被 Git、FTP 工具或部署脚本二次转码，或者后端模板引擎（如 Thymeleaf、Jinja）输出时没设编码，最终发到浏览器的仍是 GBK 字节流。
- VS Code 保存时点右下角编码 → “Save with Encoding” → 选
UTF-8（确认不是UTF-8 with BOM） - Thymeleaf 需显式设置：
templateResolver.setCharacterEncoding("UTF-8") - Java Servlet 要在处理请求前后加：
request.setCharacterEncoding("UTF-8")和response.setCharacterEncoding("UTF-8") - PHP 输出前加：
header('Content-Type: text/html; charset=utf-8');
部分中文乱码但其他正常？重点查数据来源
标题、导航栏正常，但文章内容或评论区是乱码，说明 HTML 本身没问题，问题出在动态加载的数据上——接口返回、数据库读取、JSON 解析等环节用了不同编码。
- 用浏览器直接访问接口 URL，看原始响应体是否已是乱码；如果不是，检查前端 JS 是否用错编码方式解析（如误用
TextDecoder('gbk')） - MySQL 连接 URL 加参数：
?useUnicode=true&characterEncoding=UTF-8 - JSON 接口后端务必设
Content-Type: application/json; charset=utf-8，且数据序列化时禁用 ASCII 转义（如 Python 的json.dumps(..., ensure_ascii=False)） - 避免用
innerHTML直接插入含未转义 HTML 实体的内容；该用textContent就别用innerHTML
最容易被忽略的点：本地开发时一切正常，上线后乱码——往往是因为 Nginx/Apache 没配 charset，或静态托管服务（如 GitHub Pages）虽默认 UTF-8，但你上传的文件本身带 BOM 或被构建工具重编码过。每次部署前，用 file -i your.html 命令确认真实编码，比靠眼睛猜可靠得多。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
