线程池钩子函数不能清洗图文链接，它仅用于监控执行生命周期；链接清洗必须在富文本解析阶段通过dom解析器实现，并嵌入业务任务中统一处理。
这个问题存在根本性概念混淆，无法按字面实现。
“动态线程池钩子函数”不是链接清洗工具
线程池钩子（如 beforeExecute、afterExecute）用于监控或增强线程执行生命周期，比如打日志、统计耗时、传递上下文，它不处理业务数据内容。它看不到“图文混合排版”里的 HTML 文本，更无法识别或改写其中的 <a href="http://example.com"></a> 这类链接。
清洗外部链接应在内容解析/渲染阶段完成
真正可行的位置是：
-
富文本解析器入口：在后端接收到 Markdown、HTML 或自定义富文本结构后，用 DOM 解析器（如 Java 的 Jsoup、Python 的 BeautifulSoup、Node 的 jsdom）遍历所有
<a></a>标签 -
链接安全策略检查点：对每个
href值判断是否为外部域名、是否使用http://（非https://）、是否属于白名单域、是否含危险协议（如javascript:、data:） -
自动加固动作：对未加密的
http://外链，可选择重写为https://（若目标站支持）、添加rel="noopener noreferrer"、或替换为跳转网关链接（如/out?url=xxx）
线程池可辅助，但不能替代业务逻辑
如果你的系统并发处理大量图文任务，可以用线程池提升吞吐，但“清洗链接”必须作为独立业务步骤嵌入任务单元中，例如：
- 每个图文处理任务 Runnable 内部调用
LinkSanitizer.sanitize(html) - 在线程池钩子里仅做轻量操作：记录该任务是否触发了外链清洗、统计不安全链接数量，用于告警或灰度控制
- 绝不在线程钩子里直接修改 HTML 字符串——这违反单一职责，且会导致状态混乱和线程安全问题
安全加固需分层设计
单纯“洗链接”只是基础。生产环境还需：
- 服务端 CSP 头限制外链加载行为
- 前端渲染时二次校验（防绕过服务端）
- 定期扫描存量内容中的不安全链接并批量修复
- 对用户提交的富文本启用白名单标签+属性过滤（如只允许
a[href][rel]，禁止onerror等事件属性）
把“线程池钩子”当作通用业务拦截器，是典型的架构误用。重点应放在内容处理流水线的设计合理性上，而非强行给基础设施组件赋予它不具备的能力。
