HTML转义仅处理、&、"、'这5个字符，因其在解析中分别触发标签起止、实体开始及属性界定；其余Unicode字符属纯数据，无需转义。
为什么只转义 、&、"、' 这5个字符
浏览器解析 HTML 时，只有这五个字符触发语法解析： 启动/结束标签，& 启动实体（如 ©），" 和 ' 分别在双引号、单引号属性中界定值边界。其余 Unicode 字符（中文、emoji、数学符号）不参与解析，不会导致 XSS 或结构错乱——它们只是“数据”，不是“控制符”。
常见错误现象包括：innerHTML = userInput 直接插入 <img onerror="alert(1)" alt="HTML文档结构中字符实体转义引发的渲染安全问题剖析" >，浏览器还原后立即执行；或服务端返回 {"title": "John & Jane"}，前端用模板字符串拼成 <div>${data.title}</div>，结果被截断为 John ，后面内容消失。
- IE 对
'支持不一致，统一用'更稳妥 和 <code>>虽在纯文本上下文非必需，但保持对称可避免意外闭合和解析错位- 数字实体（如
）比命名实体（<code>）更通用：IE8 不支持 <code>'，而'可靠；中文、emoji 等无命名实体的字符只能靠数字形式（如 ❤️ 是❤️）
textContent + innerHTML 是最稳的前端转义方式
手动正则替换（如 str.replace(/, '）极易漏掉嵌套或边界情况，比如 <code> 里再塞一个 &，就可能生成无效实体或截断后续内容。浏览器原生 API 能准确复现 HTML 解析器行为：把原始字符串设为 textContent，再读取其 innerHTML —— 浏览器会自动把它转成合法实体。
实操写法：
立即学习“前端免费学习笔记（深入）”；
function escapeHtml(str) {
const temp = document.createElement('div');
temp.textContent = str;
return temp.innerHTML;
}
注意两个关键点：
- 千万别反着来：
temp.innerHTML = str; temp.textContent会执行 HTML，有 XSS 风险 - 别用
innerText：innerText会吃掉换行和多余空格，还受 CSSdisplay: none影响
服务端转义后前端仍可能翻车的三种场景
后端已用 htmlspecialchars()（PHP）、html.escape()（Python）或 he.escape()（Node.js）处理过数据，不代表前端就安全了。真正危险的是二次拼接。
- 模板字符串插值：
el.innerHTML = <div>${data.content}</div>—— 此时 JS 字符串插值绕过 HTML 解析上下文，服务端那层转义完全失效 - 框架默认行为误判：Vue 的
{{ data }}自动转义，但v-html不转；EJS 默认转义，但跳过；Twig 的{{ data|raw }}完全放行。上线前必须逐个确认变量插值路径 - 双重转义：服务端返回的已是转义后的字符串（如
<p>Hello</p>），前端又调用一次escapeHtml()，结果页面显示<p>Hello</p>
XML 中含 HTML 实体时的解析与渲染陷阱
当 XML 字符串里嵌套了 HTML 实体（如 <parameterizedstring><DIV><P>Action Field 001</P></DIV></parameterizedstring>），直接用 DOMParser 解析没问题，但提取后若误用 textContent 就只剩纯文本，丢失结构；若直接赋给 innerHTML 又可能触发 XSS（如果内容不可信）。
正确做法是分两步：
- 先用
DOMParser解析 XML：new DOMParser().parseFromString(strXML, "application/xml")，它原生支持实体解码 - 从
<parameterizedstring></parameterizedstring>提取内容后，**先判断可信度**：若来自内部系统且已清洗，可用DOMPurify.sanitize()处理再塞进innerHTML；若仅为展示，应走textContent路径 - 切忌把 XML 解析结果的
textContent当作 HTML 字符串再喂给innerHTML—— 这会导致实体被二次编码（如<变成）
复杂点往往藏在“已解码”和“需渲染”的边界上：XML 解析器返回的是已解码的文本，而你要的是可执行的 HTML 结构，中间差的不是转义，是信任判定与净化动作。
