HTML乱码本质是编码链路未对齐，必须确保文件实际字节、HTTP响应头Content-Type、<meta charset>三者统一为UTF-8（无BOM）；确认实际编码需用file -i、xxd或PowerShell查字节，而非依赖编辑器显示；BOM会导致<meta>失效，浏览器fallback至GBK等默认编码；<meta charset="UTF-8">须为<head>首个子元素且大小写严格；HTTP响应头charset优先级高于<meta>，Nginx/Apache/Node.js/PHP等须分别配置；JS/CSS及AJAX资源也需统一UTF-8编码。
HTML乱码不是“浏览器没显示好”，而是编码链路上至少一个环节没对齐——文件实际字节、HTTP响应头Content-Type、<meta charset> 三者必须一致为 UTF-8（不含 BOM）才能稳定不乱。
怎么确认 HTML 文件实际编码是 UTF-8？
别信编辑器右下角写的“UTF-8”，它可能只是当前打开方式。真实字节才是依据：
- Linux/macOS：用
file -i index.html看输出里的charset=值；再用head -c 3 index.html | xxd检查开头是否为ef bb bf（BOM） - Windows PowerShell：运行
Get-Content index.html -Encoding Byte | Select -First 3，结果是239 187 191就含 BOM - VS Code：右下角点击编码名 → 选“Reopen with Encoding” → 手动试选
UTF-8、GBK、ISO-8859-1，看中文是否正常显示；确认后点“Save with Encoding” → 选UTF-8（不带 BOM）
BOM 是最大隐形坑：一旦存在，<meta charset="UTF-8"> 就失效，浏览器 fallback 到系统默认（Windows 常为 GBK），直接崩 DOM 解析。
为什么 <meta charset="UTF-8"> 写了还是乱？
因为浏览器只在前 1024 字节内找这个标签，且必须紧贴 <head> 开头，中间不能插任何东西：
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
-
<meta charset="UTF-8">必须是<head>里的第一个子元素，前面不能有空格、换行、注释、BOM - 错例：
<head>\n <!-- 页面编码 -->\n <meta charset="UTF-8">→ 失效 - 错例：
<meta charset="utf8">或<meta charset="UTF8">→ 只有UTF-8是标准写法，大小写敏感 - 错例：同时存在
<meta charset="UTF-8">和<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">→ 后者被忽略，但可能干扰解析
注意：服务器返回 HTTP 响应头时若已带 Content-Type: text/html; charset=gbk，<meta> 完全无效 —— 浏览器优先信响应头。
HTTP 响应头 Content-Type 没设 charset 怎么办？
这是本地开发和老旧服务最常见的根源。不同环境修复方式差异大：
- Nginx：在
http、server或location块里加charset utf-8;（小写，不能写charset=UTF-8） - Apache：在
.htaccess或配置中写AddDefaultCharset UTF-8（大写U和T，不能写utf8） - Node.js/Express：在
res.send()或res.sendFile()前加res.set('Content-Type', 'text/html; charset=utf-8');；用res.render()时模板引擎（如 EJS）需单独配charset - Python
http.server：默认是iso-8859-1，必须自己继承并重写do_GET注入响应头，或改用python -m http.server --bind 0.0.0.0:8000并配合反向代理补头 - PHP：在
<?php标签最开头（前面不能有任何空格/BOM）调用header('Content-Type: text/html; charset=utf-8');
验证方法：F12 → Network → 刷新 → 点 HTML 请求 → Headers → Response Headers → 查 Content-Type 值。如果没出现 charset=utf-8，上面的配置就白写了。
JS/CSS 文件也得统一 UTF-8
HTML 页里引用的外部资源，编码不一致会直接报错：
-
<script src="app.js"></script>：如果app.js实际是 GBK 编码，Chrome 会报Uncaught SyntaxError: Invalid or unexpected token -
<link rel="stylesheet" href="style.css">：GBK 编码的 CSS 文件里中文注释会让整个样式表失效 - 验证 JS/CSS 编码：命令行跑
file -i app.js；或用 VS Code 以不同编码重开，看语法高亮是否异常 - CSS 文件可加
@charset "UTF-8";（必须在第一行，前面不能有任何字符），但 JS 没等效语法，只能靠文件本身编码
真正容易被忽略的是：AJAX 加载的 HTML 片段（比如 HTMX 或 jQuery .load()）、JSON 接口返回的中文字段，都依赖各自响应头的 charset。光修主页面没用，每个动态响应都得单独盯。
