先说结论：两者只能选其一时，遗漏输出编码通常更容易留下跨站脚本风险。输入过滤发生在数据进入系统时，输出编码则在内容即将交给浏览器解析时，针对实际位置处理特殊字符。数据可能来自表单、导入文件或旧记录，过滤规则不可能替所有输出位置兜底。设计跨站脚本攻击检测与防御策略时，应把输出编码作为关键防线，再用输入校验补充。
为什么输入过滤不能代替输出编码
过滤通常是按字符、格式或业务规则拒绝或改写输入。例如，账户昵称可以限制长度、禁止控制字符；这能改善数据质量，却不能保证内容在后续展示时安全。同一个昵称可能出现在页面文字、属性值、邮件模板或管理后台，允许字符与危险边界会随位置变化。
而且，内容未必来自用户刚提交的表单：旧数据库记录、批量导入数据、第三方接口返回值，也可能绕过当前过滤流程。若页面把这些内容直接作为可解析标记交给浏览器，单靠输入端规则就会留下缺口。过滤规则过严还会误删合法姓名或符号，维护成本随业务变化增加。
输出编码为什么更接近风险发生点
输出编码应按内容所在的上下文选择：普通文本、带引号的属性值和脚本数据有不同的解析规则。把一种编码方式套到所有位置，或者先编码后又经过解码，都可能失效。优先使用默认启用自动转义的模板机制；需要输出富文本时，则使用经过审查的清洗器，只开放确有需要的格式。
例如，用户在个人资料中填写的介绍，之后既展示在个人页面，也出现在审核人员使用的详情页。即便提交时做过输入校验，任一页面若使用了关闭自动转义的渲染路径，仍可能重新引入风险。因此跨站脚本攻击检测与防御策略要沿着数据流检查“来源—存储—每个输出点”，而不是只看表单校验是否存在。
检测与修复：按数据流逐项核对
- 列出不可信来源：检查表单、文件导入、外部接口和历史数据，并标明哪些字段允许富文本。
- 搜索输出位置：审查模板中的原样输出、关闭转义的选项，以及将字符串交给浏览器解析的调用；记录每个字段最终出现的上下文。
- 做安全测试：在测试环境输入包含尖括号、引号和与号的无害标记，查看页面显示结果及浏览器解析后的结构。若标记被当成普通文字呈现，通常说明转义生效；不要把测试内容放到真实用户页面。
- 修复并回归：在输出边界启用对应上下文的转义，移除不必要的原样输出；保留长度、字符范围等输入校验，再覆盖个人页面、审核页面等不同展示路径。
静态代码审查适合发现危险输出调用和关闭转义的路径，动态扫描适合检查可访问页面的响应，但都可能漏掉登录后页面、少见角色或未覆盖的模板。人工沿数据流复核，能补足工具对业务上下文理解不足的问题。
实际选择：把责任放在正确的位置
若只能优先补一项，先修复缺少输出编码的页面，尤其是能展示用户可控内容的位置。输入校验用于限定业务上可接受的数据，不应承担抵御所有解析方式的任务。富文本是例外情形之一：它需要经过专门清洗，并且展示时仍要避免将不可信内容放入错误上下文。落实跨站脚本攻击检测与防御策略，核心不是二选一，而是让输入校验、上下文转义和测试各自承担明确职责。
常见问题
只做输出编码，是否可以取消输入校验？
不可以。输出编码主要防止内容被错误解析；输入校验仍用于长度、格式和业务规则，减少异常数据与后续处理问题。
自动转义能覆盖所有输出场景吗？
不能。模板的自动转义通常适用于常见文本输出；原样输出、特殊上下文和脚本数据需要单独检查，不能仅凭模板名称判断安全。
内容安全策略能替代转义吗？
不能。浏览器策略可以作为额外缓解措施，但配置或覆盖范围可能有限，不能替代正确的上下文编码和输入处理。
最容易先检查哪里？
优先查找关闭自动转义的模板、原样输出调用，以及个人资料、评论和后台审核页等展示外部可控内容的路径。
