alert() 本身不解析 HTML，但输入字符串若来自未转义的 DOM 属性、innerHTML 或服务端模板，可能因多重 HTML 实体编码（如 & 变成 &）导致显示异常；应优先用 textContent 获取纯文本，并对动态拼接内容手动转义 &、、"、' 五个字符。
showAlert 里直接拼接字符串会崩掉
浏览器的 alert() 函数本身不解析 HTML，但它对传入的字符串不做任何转义处理——这意味着你塞进去什么，它就原样显示什么。但问题出在「怎么把字符串塞进去」：如果这个字符串是从 HTML 属性、data- 属性或 innerHTML 中提取的，而这些地方本身含未转义的 &、、<code>>，那 JS 解析阶段就可能出错。比如：data-message="User & Admin" 被 JS 读成 "User & Admin"（中间多了一层实体），再传给 alert() 就变成字面量显示 User & Admin，而非预期的 User & Admin。
- 不要从
innerHTML或未过滤的 DOM 属性中直接取值传给alert() - 若数据来自服务端模板（如
{{ message }}），确认模板是否已做 HTML 转义；若未转义，需先用 JS 函数处理 - 避免用
eval()或new Function()动态执行含用户数据的字符串——这比alert()危险得多
用 textContent 提取原始文本最安全
想从某个 DOM 元素里读出“用户真正输入的内容”，别用 innerHTML 或 innerText，优先选 textContent。它返回纯文本内容，绕过 HTML 解析，天然避开 、<code>& 等被二次解码的问题。例如：<script>alert(1)</script> 在 div 里，div.textContent 返回的就是字面字符串 <script>alert(1)</script>，可直接传给 alert() 显示，不会触发执行，也不会被误解析。
-
innerText受 CSS 影响（如display: none的内容不计入），行为不稳定，不推荐用于提取原始值 - 若元素内含富文本（如嵌套
strong、a），textContent会连标签内容一起拉平，正好符合alert()需求 - 服务端返回 JSON 数据时，也应确保字段值是纯字符串，而非已转义的 HTML 字符串
动态构造 alert 内容时必须手动转义
如果你在 JS 里拼接字符串再调用 alert()（比如组合用户名和错误码），且其中某部分来自不可信源（表单输入、URL 参数、API 响应），就必须先做 HTML 字符转义。注意：这里不是防止 XSS（alert() 不执行 JS），而是防止显示错乱或截断——比如用户名含 " 或 &，拼进模板字符串时可能提前闭合引号或引发解析歧义。
- 转义顺序不能错：
&必须最先处理，否则后续替换生成的&会被当成新实体前缀 - 只转义 5 个基础字符：
&、、<code>>、"、'；其他 Unicode 字符（中文、emoji）无需处理 - 简单函数示例：
function escapeHtml(str) {<br> return String(str)<br> .replace(/&/g, '&')<br> .replace(/</g, '<')<br> .replace(/>/g, '>')<br> .replace(/"/g, '"')<br> .replace(/'/g, ''');<br>}
textarea 里显示 HTML 源码要双重确认
有些场景下，你会把 HTML 字符串放进 textarea 让用户查看或编辑（比如 CMS 的源码模式）。这时看似只是“显示”，但若原始字符串本身是已转义的（如服务端返回 <div>），前端再用 <code>innerHTML 赋值就会变成双层编码（显示为 <div>）。正确做法是：用 textContent 设置 textarea.value，或用 DOM 方法兜底。
立即学习“前端免费学习笔记（深入）”；
- 错误写法：
textarea.innerHTML = htmlStr（会触发 HTML 解析，再转义） - 正确写法：
textarea.value = htmlStr（前提是htmlStr是原始未转义字符串） - 保险写法：
textarea.value = document.createTextNode(htmlStr).textContent，强制还原为纯文本
& 就会变成 & 再变成 &。
