HTML5 中文乱码主因是 charset 声明缺失或文件编码不一致，须在 head 首行写，文件保存为 UTF- 8 无 BOM，服务器响应头不可覆盖该声明，CSS/JS 文件也需同为 UTF- 8 无 BOM。
HTML5 静态网页出现中文乱码，90% 是因为 charset 声明缺失或与文件实际编码不一致，不是浏览器问题，也不是“字体没装好”。
HTML 文件里必须显式声明 UTF-8 编码
HTML5 不再支持老式的 meta http-equiv="Content-Type" 写法（虽然部分浏览器仍兼容），必须用简短、标准的 meta charset，且要放在 最开头（在任何 CSS/JS 引入之前）：
我的页面 你好，世界
注意：charset 值必须是 UTF-8（大小写不敏感，但惯例全大写），不能写成 utf8、utf-8（带短横）、UTF8（无短横但非标准写法）——某些旧版 IE 或工具链可能识别不稳定。
立即学习 “ 前端免费学习笔记（深入）”；
编辑器保存文件时必须选 UTF-8 without BOM
即使 HTML 里写了 ，如果文件本身是以 GBK、ISO-8859-1 或带 BOM 的 UTF-8 保存的，浏览器仍会按错误编码解析中文，导致乱码或页面顶部出现  等不可见字符。
- VS Code：右下角点击编码名称 → 选择
Save with Encoding→ 选UTF-8（默认即无 BOM） - Sublime Text：菜单
File → Save with Encoding → UTF-8 - Notepad++：菜单
编码 → 转为 UTF-8 无 BOM 格式
验证方法：用命令行执行 file -i your-page.html（Linux/macOS）或用 VS Code 打开后看右下角是否显示 UTF-8 且无 BOM 提示。
服务器响应头不能覆盖 meta charset
本地双击打开 HTML 文件（file:// 协议）时，浏览器只依赖 meta 声明；但一旦通过 HTTP 服务访问（如 http://localhost:8080），服务器返回的 Content-Type 响应头优先级高于 meta 标签。如果服务器返回：
Content-Type: text/html; charset=GBK那无论你 HTML 里怎么写 meta，浏览器都会用 GBK 解析，中文必然乱码。
- 用 Python 快速起服务测试：
python3 -m http.server 8000 --bind 127.0.0.1默认发UTF-8头，安全 - 用 Nginx/Apache：确认配置中未手动设置
charset GBK或类似指令 - Chrome 开发者工具 → Network → 刷新页面 → 点开 HTML 请求 → 查看 Response Headers 中的
Content-Type
外部资源（CSS/JS）也要保持编码一致
如果 CSS 文件里写了中文注释或内容（如 content: "删除";），或 JS 文件里有中文字符串，它们同样需要自身是 UTF-8 without BOM 编码，并在 或 标签中显式声明：
不过现代浏览器对 CSS/JS 默认也按页面编码解析，只要 HTML 主文档编码正确、外部文件也是 UTF-8，一般无需额外加 charset 属性；但加了更稳妥，尤其面对老旧环境。
真正容易被忽略的是：用文本编辑器新建一个 .css 文件，直接输入中文保存——很多编辑器默认用系统区域编码（如 Windows 简体中文版默认 GBK），这个文件单独打开就是乱码，嵌入 HTML 后也会污染渲染。
