HTML国际化中敏感词过滤不能依赖前端正则，必须在服务端结合locale进行语言上下文感知的过滤：接收请求时同步传入locale、原始输入和词库版本号，按语言加载对应Trie词典，对插值内容单独归一化匹配，返回标准化动作结果；词库须工程化分离管理，DOMPurify仅负责结构安全，文本语义过滤必须前置。
HTML国际化内容里怎么过滤敏感词
不能靠前端正则或简单替换。国际化（i18n）意味着文本来自多语言资源文件（如 en.json、zh-CN.json），甚至动态拼接（formatMessage({ id: 'post.title', values: { user: name } })）。一旦敏感词嵌在翻译字符串中，或用户输入参与了插值，纯客户端过滤就彻底失效——你连原始文本在哪组装的都控制不了。
真正可行的做法只有一条：所有带国际化语境的用户生成内容（评论、标题、表单字段），必须在服务端完成「语言上下文感知」的过滤：
- 后端接收请求时，把
locale字段、原始输入、对应语言的词库版本号一并传给敏感词引擎 - 引擎根据
locale加载对应语言的 Trie 词典（比如zh用简体中文词库 + 拼音/形近变形规则，ja用日文平假名+片假名+汉字混合匹配） - 对插值内容（如
{user}）单独提取、归一化（转小写、去空格、半角化）、再查词，不和模板字符串混在一起匹配 - 返回结果中不暴露命中的具体词，只返回
{ action: 'block', reason: 'content_policy_violation' }
敏感词词库怎么工程化维护
硬编码在 JS 或 JSON 文件里等于公开招标让人绕过。工程化维护的核心是「词库与代码分离、加载与执行分离、权限与审计闭环」。
关键实操点：
立即学习“前端免费学习笔记（深入）”；
- 词库存放在独立服务或数据库中，前端/Worker 只能通过带鉴权的
/api/v1/sensitive-words/metadata获取版本号和校验哈希，**绝不下载完整词库** - 后端服务启动时拉取加密词库（AES-256-GCM），解密后构建内存 Trie 树；每次更新触发热重载，旧树延迟 GC
- 所有匹配操作记录完整上下文：
input_hash、word_id、matched_at、request_id，供合规审计回溯 - 运营后台提供「灰度开关」：某条词可设为仅记录（
action: 'log'）、仅提示（action: 'warn'）、全站拦截（action: 'block'），不同 locale 可独立配置
为什么 DOMPurify + i18n 一起用仍不安全
DOMPurify.sanitize() 只处理 HTML 结构安全，不管文本语义。比如国际化文案中出现 "The government announced new policies"，英文词库若没覆盖 “government” 在特定政治语境下的敏感性，它就完全放行——而这个词在中文 locale 下可能对应“政zhi”“当局”等变体，需跨语言映射识别。
更危险的是组合场景：
- 用户提交
<p>{msg}</p>，其中msg = "See you at the <b>party</b>"，party在英文词库中未标记，但中文 locale 下渲染为“党派”，触发违规 -
DOMPurify清洗后保留<p>See you at the <b>party</b></p>，服务端再做文本过滤时，已丢失原始大小写、空格、HTML 标签包裹等上下文线索 - 正确顺序只能是：先服务端文本过滤 → 再结构净化 → 最后交由 i18n 框架渲染
最容易被忽略的细节：locale 切换时的过滤上下文漂移
用户在页面上切换语言（如从 en-US 切到 zh-CN），前端可能重新渲染 DOM，但服务端并不知道这次切换是否伴随新输入。如果过滤逻辑依赖客户端传来的 Accept-Language 头，攻击者只要伪造 header 就能让词库错配。
必须强制要求：每个含用户输入的请求，显式携带 X-Client-Locale header 或 body 字段，并和服务端 session 中绑定的用户首选语言比对；不一致时拒绝请求，不降级、不猜测、不 fallback。
