对象池不执行敏感词过滤，仅管理对象生命周期；敏感词擦除应在对象归还前的reset()中清空rawInput、matchedKeywords等敏感字段，确保跨请求零残留。

对象池本身不负责敏感词擦除，它只管理可复用对象的生命周期。真正执行敏感词过滤的是业务逻辑组件（如文本清洗器、内容校验器），而“对象擦除”应理解为：在对象归还至池前，**主动清空其内部缓存的原始文本、中间结果或临时标记位，防止敏感数据残留和跨请求泄露**。

为什么不能靠对象池直接“擦除敏感词”

敏感词过滤是语义处理行为，需依赖词库、匹配算法（如 Trie 树或 AC 自动机）和上下文判断；对象池只是内存复用容器，不具备文本分析能力。若误将“擦除”理解为在池层面做字符串替换，会导致：

• 池化对象（如 ParserContext、SanitizerInstance）被强耦合具体业务逻辑，失去通用性
• 归还时统一擦除可能误删非敏感字段（如样式配置、节点 ID），破坏对象一致性
• 无法支持差异化策略（如不同租户用不同词库），因池通常是共享或单例的

正确做法：在对象使用链路中嵌入擦除点

把敏感词擦除作为对象“重置流程”的一部分，在 borrow → use → return 全周期中精准控制数据清理时机：

• 借出时（borrow）：不做擦除，但可注入当前请求的租户 ID 或策略标识，供后续过滤使用
• 使用中（use）：调用独立的 KeywordFilter 实例（从另一专用池获取）对文本执行过滤，返回净化后结果
• 归还前（before return）：在对象的 reset() 方法里显式清空敏感字段——例如：this.rawInput = null、this.matchedKeywords.clear()、Arrays.fill(this.tempBuffer, (byte)0)

关键实现细节

确保擦除动作真正生效且线程安全：

• 敏感字段声明为 volatile 或用 AtomicReference 包装，避免 CPU 缓存导致其他线程看到旧值
• reset() 中优先使用 Arrays.fill() 或 ByteBuffer.clear() 清零字节数组，而非仅置 null（防止 GC 前被 dump 出内存）
• 若对象含外部资源引用（如 MappedByteBuffer、native buffer），reset() 必须显式释放，否则擦除无意义
• 日志中记录擦除动作（如 “Sanitizer-123: cleared 42KB raw input”），便于审计与问题回溯

配合服务端二次校验形成闭环

对象池内的擦除属于“运行时防护”，不能替代最终的内容安全兜底：

• 前端传来的 HTML 或 Delta 数据，必须经服务端独立过滤器（如 Jsoup + 白名单 + 敏感词引擎）再落库
• 归还后擦除的对象，若下次被借出，其内部状态应完全干净——可通过单元测试验证 reset() 后字段是否为初始值
• 对高敏场景（如政务、金融编辑器），可启用 JVM 参数 -XX:+AlwaysPreTouch 配合内存池，降低敏感数据在堆外内存残留风险