HTML5乱码主因是文件编码与声明/响应头不一致：需确保文件为UTF-8无BOM、meta声明准确置于head首行、服务器响应头未覆盖charset。BOM和响应头冲突占90%案例。
HTML5 文件保存编码不匹配导致乱码
最常见的情况是：编辑器用 UTF-8 无 BOM 保存了 index.html，但服务器或浏览器没按 UTF-8 解析。HTML5 默认要求 UTF-8，但不会自动强制生效——它依赖你显式声明和文件实际编码一致。
- 检查文件真实编码：用 VS Code、Sublime 或 Notepad++ 查看右下角状态栏，确认显示的是
UTF-8（不是UTF-8 with BOM或GBK） - 确保
声明在最前面，且拼写准确： - 不要写成
charset=UTF8、charset=utf8（少横线）或content="text/html; charset=utf-8"（这是旧式 HTTP-equiv 写法，已过时）
服务器响应头覆盖了 HTML 中的 charset 声明
即使 写对了，如果服务器返回的 HTTP 响应头里有 Content-Type: text/html; charset=gbk，浏览器会优先信任响应头，直接忽略 HTML 内声明。
- 用浏览器开发者工具（F12 → Network → 刷新页面 → 点开 HTML 请求 → Headers 标签）查看
Response Headers中的content-type - 本地测试时若用双击打开
file://协议，浏览器不发请求头，此时完全依赖，务必保证文件编码和声明一致 - Apache 用户可在
.htaccess加：AddDefaultCharset utf-8
；Nginx 用户在 server 块中加：charset utf-8;
IDE 或构建工具自动转码引入 BOM 或编码污染
某些编辑器（如老版 Windows 记事本）、前端构建工具（如 gulp-htmlmin 默认可能移除 ）、甚至 Git 在换行符转换时，都可能悄悄插入 BOM 或改变编码。
- 用命令行检测 BOM：
xxd index.html | head
，如果开头出现00000000: efbb bf...，说明有 UTF-8 BOM，需另存为「UTF-8 无 BOM」 - Webpack/Vite 项目中，检查插件是否误处理 HTML 模板；
html-webpack-plugin一般安全，但自定义minify配置时禁用removeAttributeQuotes等可能干扰 meta 的选项 - VS Code 用户确认设置中
"files.encoding": "utf8"且"files.autoGuessEncoding": false（避免猜错）
中文路径或文件名在 URL 中未正确编码
这不属于 HTML 渲染乱码，但常被误认为“页面乱码”：当链接含中文路径（如 ），而服务器未配置 URL 解码支持，点击后可能 404 或返回错误内容。
立即学习“前端免费学习笔记（深入）”；
- 开发阶段尽量用英文文件名和路径，避免这类问题
- 必须用中文时，服务端需支持
URI decoding；例如 Node.js 的express默认支持，但 Nginx 需开启：underscores_in_headers on;
并确保location块未错误重写 URI - 浏览器地址栏中看到
%E4%BD%A0%E5%A5%BD.html是正常编码，不是乱码——只要服务端能正确 decode 就行
UTF-8 无 BOM、charset。BOM 和服务器头这两处最容易被忽略。 
