alert() 本身不解析 HTML,但输入字符串若来自未转义的 DOM 属性、innerHTML 或服务端模板,可能因多重 HTML 实体编码(如 & 变成 &)导致显示异常;应优先用 textContent 获取纯文本,并对动态拼接内容手动转义 &、、"、' 五个字符。

showAlert 里直接拼接字符串会崩掉
浏览器的 alert() 函数本身不解析 HTML,但它对传入的字符串不做任何转义处理——这意味着你塞进去什么,它就原样显示什么。但问题出在「怎么把字符串塞进去」:如果这个字符串是从 HTML 属性、data- 属性或 innerHTML 中提取的,而这些地方本身含未转义的 &、、>,那 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 解析,天然避开 、& 等被二次解码的问题。例如:<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 个基础字符:
&、、>、"、';其他 Unicode 字符(中文、emoji)无需处理 - 简单函数示例:
function escapeHtml(str) {<br> return String(str)<br> .replace(/&/g, '&')<br> .replace(/, ' .replace(/>/g, '>')<br> .replace(/"/g, '"')<br> .replace(/'/g, ''');<br>}
textarea 里显示 HTML 源码要双重确认
有些场景下,你会把 HTML 字符串放进
关键点在于:alert 本身不解析 HTML,但它的输入来源常常混着 HTML 解析链路。真正容易出问题的不是弹窗函数,而是你从哪取值、怎么拼接、有没有无意间触发了多层转义。稍不注意,textarea 让用户查看或编辑(比如 CMS 的源码模式)。这时看似只是“显示”,但若原始字符串本身是已转义的(如服务端返回 innerHTML 赋值就会变成双层编码(显示为 textContent 设置 textarea.value,或用 DOM 方法兜底。
textarea.innerHTML = htmlStr(会触发 HTML 解析,再转义)textarea.value = htmlStr(前提是 htmlStr 是原始未转义字符串)textarea.value = document.createTextNode(htmlStr).textContent,强制还原为纯文本& 就会变成 & 再变成 &。
前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!











