多态通过统一ContentChecker接口实现内容审核的可扩展与解耦，各子类（Text/Image/Hybrid等）独立实现check逻辑，运行时按contentType动态路由，返回结构化结果并支持配置与审计。
多态本身不直接“做审核”，而是让文字、图片等不同内容类型的过滤校验逻辑能共用同一套调用方式，新增类型不改老代码——关键在于把“要不要拦”“怎么拦”抽象成接口，再让各类审核器各干各的事。
定义统一的内容审核行为契约
先不管它是文本还是图片，只约定“我需要回答一个问题”：当前内容是否合规？
例如声明一个 ContentChecker 接口：
- 只含一个方法：check(Content content)，返回 CheckResult（含通过/拦截/异常等状态 + 原因）
- Content 是泛型基类或接口，可承载 text、imageBytes、metadata 等字段
- 接口不暴露数据库查询、OCR调用、云API细节，只暴露语义明确的校验能力
为不同内容类型提供独立实现
每种内容的审核逻辑天然不同，多态正好隔离差异：
立即学习“Java免费学习笔记（深入）”；
- TextContentChecker：加载敏感词 Trie 树，走 DFA 匹配；支持拼音/谐音扩展，返回命中词和位置
- ImageContentChecker：调用百度云 AIP 或本地 Tesseract+规则引擎，先 OCR 提取文本，再交由 TextChecker；同时用 CNN 模型判断图像违规等级
- HybridContentChecker：组合前两者，对图文混排内容分别校验并加权决策（如文本违规+图像低风险 → 人工复审）
- 后续加新类型（如语音转写后文本、PDF 元数据），只需新增实现类，不碰已有逻辑
运行时按内容类型自动路由
怎么知道该用哪个 Checker？靠内容本身的元信息动态分发：
- 从请求中解析 contentType（如 "text/plain"、"image/jpeg"、"application/pdf"）
- 用 Spring 的 @Qualifier 或轻量工厂映射：checkerMap.get(contentType).check(content)
- 调用方始终面向 ContentChecker 接口编程，JVM 自动调用实际子类 —— 这就是多态在起作用
- 配合注解如 @Audit(contentType = "image")，AOP 切面自动注入对应实例，业务代码零耦合
让审核过程可配置、可追溯
多态不只是换实现，更是为了交付可控：
- 每个 Checker 返回结构化 CheckResult，含拦截数、耗时、命中的敏感词/违禁图特征
- 支持配置开关：开发环境用内存 Trie，生产环境切百度云 API；图片审核可设“仅 OCR 不鉴黄”灰度模式
- 组合场景下（如评论带图），用 CompositeChecker 封装执行顺序与失败策略（跳过 or 中断），并记录每步快照供审计
- 批量审核完成后生成报告：文本违规率 0.3%、图片 OCR 准确率 92.1%、平均响应 86ms
