HTML乱码根本原因是文件实际编码与<meta charset="UTF-8">声明不一致，必须同步修正二者；<meta>须置于<head>最前且无BOM/空格干扰，HTTP响应头charset优先级更高，外部资源也需统一UTF-8无BOM。
直接看文件编码和 <meta charset="UTF-8"> 是否匹配，不一致就必然乱码；光改 HTML 声明或光改保存编码都不够，必须两边同步。
检查并修正 HTML 文件实际编码格式
VS Code 右下角显示的编码（比如 GBK 或 UTF-8 with BOM）就是文件真实编码，不是“看着像中文”就代表对。Windows 记事本默认存为 ANSI（实为 GBK），这是最常见乱码源头。
- 用 VS Code / Notepad++ 打开
index.html，点击右下角编码名 → 选Save with Encoding→ 强制选UTF-8（不是UTF-8 with BOM） - 用命令行验证：Linux/macOS 运行
file -i index.html，输出应含charset=utf-8；Windows PowerShell 运行Get-Content index.html -Encoding Byte | Select -First 3，结果不应是ef bb bf（即无 BOM） - 别点
Reopen with Encoding—— 这只是临时重解释，不改变文件字节，保存后仍会回退乱码
<meta charset="UTF-8"> 必须在 <head> 最前面且无干扰
浏览器只扫描前 1024 字节找这个标签，任何前置内容（空格、注释、BOM、甚至 DOM 操作脚本）都可能导致它失效，然后 fallback 到系统默认编码（如 Windows 的 GBK）。
-
<meta charset="UTF-8">必须是<head>内第一个标签，前面不能有任何字符（包括换行、<!-- -->、<script>） - 不要混用旧写法：
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">已过时，且部分浏览器解析更不稳定 - 如果用了模板引擎（如 EJS、Pug），确认它没在
<meta>前注入其他内容（比如服务端日志、调试注释）
HTTP 响应头 Content-Type 优先级高于 <meta>
当 Web 服务器（Nginx/Apache）或后端（PHP/Node.js）返回的响应头里明确写了 Content-Type: text/html; charset=gbk，浏览器会直接忽略 HTML 里的 <meta>，哪怕它写的是 UTF-8。
立即学习“前端免费学习笔记（深入）”；
- Nginx 配置中，在
location /块加charset utf-8;，并确保没被其他add_header Content-Type覆盖 - PHP 中，
header('Content-Type: text/html; charset=utf-8');必须在任何输出之前调用，且文件本身不能含 BOM（否则 header 失效） - Node.js Express 中，用
res.set('Content-Type', 'text/html; charset=utf-8')，别依赖res.sendFile()默认行为（它不带 charset）
CSS/JS 等外部资源也要 UTF-8 编码
HTML 页面正常了，但内嵌文字（如 content: "按钮"）、AJAX 返回的 JSON、或表单提交的参数仍乱码，大概率是关联资源编码不统一。
- 检查
style.css和app.js文件本身是否也是 UTF-8 无 BOM 编码（同样用file -i或编辑器状态栏确认） - 不要手动加
charset="UTF-8"到<script>或<link>标签——现代浏览器按文件实际编码加载，加了反而可能触发兼容模式 - 表单提交后服务端收到乱码？可能是 POST 数据被按 ISO-8859-1 解析了，需在接收端做一次转码，例如 Java 中用
new String(str.getBytes("ISO-8859-1"), "UTF-8")
真正卡住人的地方，往往不是某个单一配置，而是多个环节编码声明互相冲突：文件存成 UTF-8，<meta> 却写 gbk；Nginx 返回 charset=iso-8859-1，又指望 <meta> 救场；CSS 文件还是 GBK 编码，里面写了中文注释…… 逐个验证比凭感觉改更快。
