Predicate仅用于条件判断，不执行敏感词过滤；真正处理由专用过滤服务完成，应在DTO构建前完成识别与脱敏，确保content字段安全，并通过扩展DTO字段实现处理意图显性化与可追溯。
在多级评论区的 DTO 转换过程中，Predicate 本身不负责过滤或剔除敏感词，它只是条件判断工具（如用于 JPA 查询、集合筛选等）。真正执行敏感词识别与内容处理的，是专门的过滤服务。DTO 转换阶段应配合该服务完成“标记 + 剔除/脱敏”，而非依赖 Predicate 实现文本替换。
敏感词应在 DTO 构建前完成识别与处理
用户提交评论后，流程应为：接收原始内容 → 过滤服务扫描并返回处理结果（是否含敏感词、脱敏后文本、命中词列表）→ 再构建 DTO。这样可确保 DTO 中的 content 字段已是安全态：
- 若业务要求直接剔除整条评论，过滤服务返回 null 或标记 isBlocked = true，DTO 构造时跳过该条目
- 若要求保留但脱敏，则传入 maskWords(content) 后的结果，DTO 的 content 字段即为星号替换后的文本
- 若需后台人工复核，DTO 可额外携带 sensitiveHitList（命中词数组）和 rawContentHash（原文哈希），不存明文
用 Predicate 辅助筛选待处理/待展示的评论子集
Predicate 可用于查询层或内存筛选，快速分离需特殊处理的评论节点，例如：
- 只查 status == PENDING 且 content 长度 > 10 的评论（避免空评干扰过滤逻辑）
- 在已加载的树形评论列表中，用 Predicate 找出所有 parent_id != 0 的子评论，统一走轻量级二次校验（因父评论已过滤过，子评可能绕过）
- 结合审核状态与敏感词命中标志：Predicate.isEqual(true).negate() 筛出未被标记为敏感的评论，供前端渲染
DTO 层建议增加结构化敏感信息字段
不要让 DTO 只有 content 一个字符串字段。可扩展如下字段，使过滤意图显性化、可追溯：
- filtered：boolean，表示该评论是否经过敏感词处理
- maskLevel：int（0=未处理，1=局部替换，2=全文屏蔽，3=拒绝入库）
- hitCount：int，命中敏感词数量（便于前端显示“内容含违规词，已处理”提示）
- auditId：String，关联审核记录 ID（如 Redis key 或数据库 audit_log.id），方便溯源
避免常见误用陷阱
有人试图在 MapStruct 或 Dozer 的 @AfterMapping 方法里写 Predicate.test(content) 再调 replaceAll，这会导致：
- 重复加载敏感词库（每次转换都 new FilterService()）
- 忽略中文分词干扰（如“和-谐”未归一化就匹配失败）
- 无法记录日志（Predicate 没有上下文，不知道触发的是哪个词、来自哪条 IP）
- 线程不安全（若 FilterService 内部缓存未加锁）
