html解析器不负责解码，编码转换发生在字节流到字符流阶段；浏览器依据content-type或确定编码，且须位于前1024字节内，否则可能被忽略。
HTML解析器根本不解码文件内容
浏览器的HTML解析引擎在构建DOM树阶段完全不处理编码转换——它只按当前已确定的字符编码，逐字节读取并匹配词法规则。所谓“解码”，实际发生在解析完成后的文本节点渲染阶段，比如把还原为<code>，但这是实体解码（entity decoding），不是字符集解码（charset decoding）。如果你的HTML文件本身是GBK编码，而<meta charset="UTF-8">又写错了，解析器会用UTF-8去硬读GBK字节流，结果就是乱码，且这个过程不会报错，只会静默错乱。
如何让解析器拿到正确的字节流
关键不在HTML里写什么，而在字节源头是否对齐。浏览器确定编码顺序是：HTTP Content-Type响应头 > <meta charset>标签 > 编码探测（fallback）。所以：
- 服务端返回HTML时，必须设置
Content-Type: text/html; charset=UTF-8，且该值与文件真实编码一致 -
<meta charset="UTF-8">必须放在最开头（前1024字节内），否则可能被忽略 - 本地双击打开
file://协议的HTML时，Content-Type不可用，只能依赖<meta charset>或BOM；此时务必禁用UTF-8 with BOM——VS Code保存时选UTF-8而非UTF-8 with BOM - 用
fetch()或XMLHttpRequest加载HTML片段时，需显式指定responseType = 'text'，并确保响应头charset字段存在且正确
innerHTML赋值时的编码陷阱
通过element.innerHTML = rawString插入HTML字符串时，浏览器不会重新走完整解析流程，而是复用当前文档的编码上下文。这意味着：
- 如果
rawString是GBK编码的字符串（比如从旧接口取的），直接赋给innerHTML会导致乱码，因为当前文档是UTF-8 - 不能靠
decodeURIComponent()修复——它只处理URL编码，不解决字符集错位 - 正确做法是：服务端统一转UTF-8输出；前端若必须处理非UTF-8响应，先用
TextDecoder指定编码解码字节流，再赋值：const decoder = new TextDecoder('gbk');<br>const htmlString = decoder.decode(response.arrayBuffer());<br>el.innerHTML = htmlString;
模板引擎和前后端协作中最容易漏的一环
双重转义不是编码问题，而是流程错位。典型场景：Django模板里写{{ html_content|safe }}，但html_content已经是he.encode()过的字符串，结果页面显示<而不是。根本原因在于：
- 传输层（API响应）不该做HTML转义，应返回原始字符串
- 展示层（模板或JS）才决定是否转义：用
textContent就安全，用innerHTML就要确认来源可信 - Node.js中用
he.encode(str, { useNamedReferences: true })比默认数字编码更易调试 - React/Vue中不要对已标记
dangerouslySetInnerHTML或v-html的值再调用he.encode
真正难调试的，永远是那个没出现在控制台报错里、却让中文变成方块、让&变成&又变回&的隐性编码链路。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
