卡片式布局不改变XSS防御逻辑，关键在于后端通用模板统一处理用户输入；反射仅用于遍历String字段并自动转义，不能替代过滤逻辑，真正防护依赖转义函数、Wrapper/AOP入参清洗及CSP等多重机制。
卡片式布局本身不改变XSS防御逻辑，关键在于后端通用数据模板如何统一处理用户输入。反射在这里不是用来“动态执行脚本”，而是辅助实现通用参数遍历与自动转义——比如对模板中所有字符串字段自动调用HTML转义方法，避免逐个手动处理。
明确反射在XSS防御中的定位
反射（Reflection）在Java等语言中用于运行时获取类结构、字段名、类型和值。它不能替代过滤逻辑，但能支撑“通用模板+自动拦截”架构：当你有一个卡片数据类（如CardData），含title、content、author、tags等String字段，反射可帮你遍历全部String型字段，统一应用xssEncode()，而无需为每个字段写重复代码。
- 反射不参与校验规则制定，只负责“找到要处理的字段”
- 真正防XSS的是转义函数（如HtmlUtils.htmlEscape、Jsoup.clean）或白名单过滤器
- 必须配合包装器（如XssHttpServletRequestWrapper）或AOP，在入参阶段就完成清洗，不能只靠出参时反射处理
在通用卡片模板中用反射做自动转义的步骤
以Spring Boot为例，假设你有一组卡片DTO类继承自BaseCardDto，希望所有子类实例在序列化前自动清理敏感字段：
- 定义一个工具方法XssSanitizer.sanitize(Object obj)，用反射遍历obj所有public/protected/private String字段
- 对每个String字段值调用Jsoup.clean(value, safelist)（推荐）或HtmlUtils.htmlEscape(value)（基础转义）
- 通过Field.setAccessible(true)绕过访问限制，再用Field.set()写回清洗后值
- 在Controller返回前调用该方法，或封装进统一响应包装类ApiResponse<T>的构造逻辑中
比反射更可靠且推荐的落地方式
纯反射清洗存在隐患（如忽略嵌套对象、集合、JSON字段），生产环境建议组合使用以下方式：
- 全局Filter + Wrapper：沿用NewXssHttpServletRequestWrapper，在请求进入Controller前完成所有参数（包括JSON body）的递归清洗，卡片模板直接接收已净化的数据
- DTO层注解驱动：自定义@XssSafe注解，配合Spring Validation或AOP，在绑定参数时自动触发Jsoup.clean
- 模板引擎强制转义：Thymeleaf默认启用HTML转义，FreeMarker配置auto_escape=true，确保${card.title}输出即安全
- CSP头兜底：响应中添加Content-Security-Policy: script-src 'self'，阻断内联脚本与外部资源加载
不建议单独依赖反射的几个原因
反射清洗容易遗漏边界场景，例如：
- 字段是List<String>或Map<String, Object>，需递归处理，易栈溢出或死循环
- JSON字符串字段（如card.extraJson）被整体转义后，前端解析失败
- 日期、数字、布尔字段误判为String导致异常
- 字段含@JsonIgnore或@JsonRawValue等注解时，语义被破坏
