把评论字符串交给 innerHTML，浏览器会按 HTML 解析，而不只是显示文字。
本文使用ECMAScript 5.1 与浏览器 DOM，代码可放入独立演示页。JavaScript（脚本语言）的作用域、函数调用与事件调度，需要与浏览器提供的接口区分。本文主体使用当时已经可用的语法，不把语言版本和宿主环境混为一谈。
1. 从现象推到机制
不可信输入一旦进入代码或标记上下文，就可能改变页面结构与行为。纯文本场景使用 textContent 可以避免把内容当成 HTML。允许富文本则需经过专门白名单处理，字符串替换几个符号并不完整。
图中的四个节点分别表示不可信内容、输出场景、安全写入、结构验证。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
构造包含尖括号的演示文本，分别通过两种属性展示。只在隔离页面观察，不使用真实用户数据或外部脚本地址。
1
2
3
4
var comment = "<b>demo</b>";
var node = document.getElementById("comment");
node.textContent = comment;
// 需要富文本时，先采用经过审查的白名单处理
先记录输入、调用位置与控制台结果，再逐个改变条件。事件和异步实验保留触发顺序，避免在生产页面执行带有未知副作用的调试代码。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 用户只需要普通文本 | 应显示字面内容而非解释标签 |
| 同值写进 HTML 属性 | 需要相应上下文的处理 |
| 业务允许有限富文本 | 应限制标签属性及链接协议 |
对照 1：用户只需要普通文本
应显示字面内容而非解释标签。观察时记录最终 DOM 是否新增元素。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：同值写进 HTML 属性
需要相应上下文的处理。观察时记录属性边界与引号。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：业务允许有限富文本
应限制标签属性及链接协议。观察时记录清理后的实际结构。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
客户端处理不能代替服务端信任边界。数据也可能被其他页面或导出使用，输出位置不同应分别采用合适策略。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“业务允许有限富文本”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
