前端敏感词拦截基本没用，纯属心理安慰；真正有效的过滤必须落在服务端，前端仅作即时提示且不承担安全职责。
表单提交前用 JavaScript 做前端敏感词拦截有用吗
基本没用，纯属心理安慰。前端 onsubmit 或 addEventListener('submit') 里检查 input.value，用户禁用 JS、绕过表单、直接发 POST 请求，过滤就完全失效。
真正有效的过滤必须落在服务端，前端只做即时提示（比如输入时标红、禁用提交按钮），不承担安全职责。
- 敏感词库不能硬编码在 JS 里，否则会被直接扒走
- 前端提示建议用正则模糊匹配（如
/\b(政治|暴力|色情)\b/i），但别指望覆盖全量词库 - 若用
fetch提交，记得服务端仍要校验req.body.content，不能信req.headers['x-verified'] === 'true'
Node.js 后端用正则匹配敏感词为什么总漏判或误杀
因为中文分词和边界处理太粗糙。比如用 /政治/gi 匹配，会把“政治经济学”“不讲政治”全干掉；而“政zhi”“政汇”这类变形词又完全漏过。
推荐用基于词典的匹配，而不是简单正则。例如 node-bloomfilter 或轻量级 trie-tree 实现：
立即学习“前端免费学习笔记（深入）”；
Wechat Article Html
下载
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
const { Trie } = require('trie-js');
const trie = new Trie();
trie.add('政治'); trie.add('暴力'); trie.add('色情');
// 输入 "讨论政治话题" → trie.search('讨论政治话题') 返回 ['政治']
- 避免用
String.prototype.includes()，它无法识别嵌套、变形、拆字 - 注意大小写、全半角、常见替换（如 “*” 替 “口”，“z” 替 “智”）需预处理统一
- 性能上，10 万词以内
Trie查询是 O(m)，m 是字符串长度；正则回溯多时可能被 DoS
Django 表单 clean() 方法里过滤敏感词要注意什么
别只在 clean_content 里简单 replace()，这会让用户看不到原始输入，也破坏数据完整性。
更合理的做法是：检测 + 标记 + 报错/降权，而不是静默清洗：
- 用
django.core.validators.RegexValidator只适合极简黑白名单，不适合动态词库 - 在
clean()中调用独立的check_sensitive_words(text)，返回{ matched: [...], action: 'reject' | 'warn' } - 若需拦截，抛
ValidationError('含敏感词：xxx')；若仅记录，存到self.cleaned_data['sensitive_flags']供后续审核 - 数据库字段别设
max_length过小，替换后长度可能突增（如 “***” 替 “政治”）
用户提交含敏感词内容后，要不要返回具体哪个词被拦
不要。返回 "包含违规词汇" 就够了。暴露具体词或位置，等于教攻击者怎么绕过。
尤其当词库含未公开的运营黑词、临时封禁词、拼音缩写时，泄露会加速对抗升级。
- 日志里可以记完整原文和匹配结果，但绝不透出给前端或用户
- HTTP 响应状态别用
400 Bad Request细分，统一用400或422 Unprocessable Entity - 如果业务允许，对高频触发词的 IP 做短时限流（如
X-RateLimit-Limit: 5/h），比单纯报错更有效
敏感词系统真正的难点不在匹配速度，而在词库更新闭环、误判反馈机制、以及前后端责任边界的清晰切割——这些地方一模糊，后面全是补丁。
