用户输入经过模板渲染后仍可能成为浏览器脚本。模板替换变量不等于自动完成安全输出。
本文使用Velocity 1.7、Java 7 与 UTF-8 模板，代码为模板片段。模板引擎负责把模型渲染成文本，不应该直接承担下单、数据库查询或权限判断。模板上下文只放页面真正需要的数据，可以减少隐式依赖。
1. 从现象推到机制
HTML 文本、属性、URL 和脚本字符串需要不同编码规则。简单替换尖括号只覆盖部分场景，不能用于任意上下文。原始业务值与已编码值要区分，重复编码也会破坏正常展示。
图中的四个节点分别表示原始文本、输出位置、专用编码、浏览器解析。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
让用户文本只进入普通文本节点，并由经过审查的输出工具编码。示例中的 esc 是项目显式提供的工具，不是 Velocity 自动内置能力。
1
2
3
<p>$esc.html($comment.text)</p>
<!-- esc 需要由应用配置并提供 -->
<!-- 避免把不可信文本直接放进 script 或事件属性 -->
在固定输入下渲染到字符串或测试文件，保留模板名与最终输出。HTML（超文本标记语言）编码、字符集编码和业务权限是不同层面的约束，需要分别确认。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 文本包含尖括号与引号 | 应显示为文本而非执行 |
| 编码后的值再次编码 | 可能出现实体文本重复展示 |
| 同一值进入脚本上下文 | HTML 编码本身不够 |
对照 1：文本包含尖括号与引号
应显示为文本而非执行。观察时记录浏览器最终解析的 DOM。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：编码后的值再次编码
可能出现实体文本重复展示。观察时记录每一层是否知道值已编码。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：同一值进入脚本上下文
HTML 编码本身不够。观察时记录输出所处的语法上下文。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
输入校验和输出编码各司其职。若允许富文本，应使用明确的标签与属性白名单处理，而不是通过关闭全部编码实现。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“同一值进入脚本上下文”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
