HTML转义仅处理5个关键字符：<、>、&、"、'，用于防止语法解析错误；Unicode字符如中文、emoji等无需转义；仅在属性含引号冲突或需原样显示标签时强制用实体；innerHTML直接拼接仍存XSS风险，应优先用textContent或严格转义动态内容。
HTML转义会处理哪些特殊字符
HTML转义只处理有明确语义冲突的5个基础字符，不是“所有看起来奇怪的字符”都归它管。浏览器解析HTML时，仅当字符出现在标签结构上下文中可能破坏语法时，才需要转义——比如 < 会被当成开始标签，> 被当成结束标签，& 被当成实体起始符，" 和 ' 则用于属性值包裹。
像 ©、€、ñ、中文、emoji 这类 Unicode 字符，只要编码正确（UTF-8 声明+文件保存一致），直接写进 HTML 就能正常显示，无需转义。强行用 © 或 € 反而增加冗余，还可能因解码链路出错导致乱码。
什么时候必须用 HTML 实体而不是直接写字符
只有两类场景绕不开实体：一是属性值里含双引号但又用双引号包裹（title="他说："你好"" ❌ → 必须写成 title="他说:"你好"" ✅）；二是内容里要原样显示 HTML 标签符号本身（比如文档中讲解 <div> 写法，就得转义成 <div>，否则浏览器会真去解析它）。
<ul>
<li>XML/XHTML 环境下，<code>' 是合法实体；HTML5 中不推荐依赖它，用 ' 更稳妥
是唯一常用“不可见但有语义”的实体，用于强制不换行空格，不能用普通空格替代© 替代 © —— 除非你明确需要在老旧 IE6/7 下兼容（现代环境纯属多此一举）JavaScript 中 innerHTML 赋值时的转义陷阱
很多人以为 element.innerHTML = "<span>test</span>" 就安全了，其实不然：如果字符串来自用户输入且未过滤，仍可能触发 XSS。因为 innerHTML 是“解析后渲染”，不是“纯文本插入”。真正安全的做法是先创建文本节点：element.textContent = userInput；或者用 DOM API 手动构造元素。
立即学习“前端免费学习笔记（深入）”；
若必须用 innerHTML 插入已知结构的 HTML 片段，确保所有动态部分都经过严格转义——但注意：JavaScript 没有内置 HTML 转义函数，encodeURIComponent 是 URL 编码，JSON.stringify 加引号也不对。常见做法是用一个极简函数：
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
function escapeHtml(str) {
return str
.replace(/&/g, '&')
.replace(/</g, '<')
.replace(/>/g, '>')
.replace(/"/g, '"')
.replace(/'/g, ''');
}
这个函数只覆盖那5个关键字符，不多不少——加多了反而影响可读性和性能。
服务端模板（如 Jinja2、EJS）里的自动转义不是万能的
像 {{ user_input }} 在 Jinja2 默认开启 autoescape 时，确实会转义 <、& 等，但它不会处理 CSS 或 JS 上下文中的注入。比如 <div onclick="alert('{{ user_input }}')">，即使 user_input 是 "); alert(1); //，转义后变成 "); alert(1); //，依然能执行 JS。
所以关键不是“有没有转义”，而是“在哪种上下文里转义”：
- HTML 内容上下文 → 用 HTML 实体转义（默认行为）
- HTML 属性值（双/单引号内）→ 需额外转义引号和反斜杠
- JS 字符串字面量 → 要用 JavaScript 字符串转义规则（
\x27,\u2028等） - CSS
content或 URL → 各自有一套编码边界
最常被忽略的是：模板引擎的“自动转义”只保 HTML 主体层，一旦你把变量拼进 JS 或 CSS 字符串里，就等于主动退出了安全区。
