textContent + innerHTML 组合最稳妥，浏览器自动转义 &、、"、' 等字符；错误做法是直接 innerHTML 拼接，正确写法为创建 div、设 textContent、取 innerHTML；不适用于服务端，且需注意前后端转义策略对齐。
直接用 textContent + innerHTML 组合最稳妥
浏览器原生机制能自动处理所有需要转义的字符，包括 &、、<code>>、"、'，且无需维护正则列表或担心遗漏。核心逻辑是：先让浏览器把字符串当纯文本塞进节点，再取它的 innerHTML —— 此时所有特殊字符已被安全编码。
常见错误是直接拼接字符串后赋值给 innerHTML，比如 el.innerHTML = '<div>' + userInput + '</div>'，这等于主动执行 XSS 风险操作。
- 正确写法：
const escaped = document.createElement('div'); escaped.textContent = str; return escaped.innerHTML; - 不适用于服务端（Node.js 等无 DOM 环境）
- 性能上比正则略低，但对多数前端场景可忽略
escapeHtml 函数里漏掉 ' 很容易被忽略
很多手写正则转义函数只处理 &、、<code>>、"，但单引号 ' 在属性值用单引号包裹时（如 data-id='user'）同样危险。一旦用户输入 user' onclick="alert(1)"，就会突破属性边界。
如果你必须用正则，确保覆盖全部五类基础字符：
立即学习“前端免费学习笔记（深入）”；
.replace(/&/g, '&').replace(/, '.replace(/>/g, '>').replace(/"/g, '"').replace(/'/g, ''')
注意顺序：必须先转 &，否则后续替换生成的 里的 <code>& 可能被二次处理。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
jQuery 的 $('<div></div>').text(str).html() 本质和 DOM 方法一致
这个写法只是 DOM 方式的 jQuery 封装，原理完全相同：创建空 div → 设 text → 取 html。它不是 jQuery 特有功能，也不依赖 jQuery 的事件系统或选择器引擎。
容易踩的坑：
- 误以为
$.text()或$.html()单独就能转义 —— 它们不能，必须组合使用 - 在循环中反复调用该模式却没缓存
div元素，造成轻微 DOM 创建开销 - 项目已弃用 jQuery，硬套这行代码反而引入冗余依赖
服务端转义不能依赖前端补救
如果 HTML 内容来自后端（如模板渲染、API 返回），必须在服务端完成转义。前端补做只是“多一层保险”，不是替代方案。例如 PHP 的 htmlspecialchars($str, ENT_QUOTES, 'UTF-8')、Python 的 html.escape(str)、Java 的 StringEscapeUtils.escapeHtml4()。
关键点：
- 前后端转义策略要对齐：比如都启用单引号转义，否则某端漏掉会出问题
- 服务端转义后，前端不要再用
innerHTML赋值原始字段，而应直接插入 —— 否则可能双重转义（如&） - 富文本场景例外，但需明确区分「纯文本展示」和「可执行 HTML」两个通道
真正难处理的是混合场景：比如后端返回了部分已转义的 HTML 字符串，前端又动态插入新内容。这时候必须确认每个数据源的转义状态，而不是统一套一个函数完事。
