用 set 的 has 方法做关键词黑名单过滤可实现毫秒级响应，关键在于标准化关键词（大小写、空格、编码、全半角统一）、一次性初始化 set、轻量预处理输入，并避免在 has 前执行重操作。
用 Set 的 has 方法做关键词黑名单过滤，本身就能做到毫秒级响应——关键不在“有没有用 has”，而在于“怎么准备数据”和“怎么处理输入”。只要避开几个常见陷阱，单次判断稳定在 0.1ms 以内完全可行。
关键词必须标准化后存入 Set
黑名单不是原样扔进去就完事。用户输入的关键词往往带干扰信息，而 Set 是严格区分字符串内容的：
- 统一转小写或大写（如
input.toLowerCase()后再查） - 去除首尾空格（
input.trim()必不可少，否则"admin "查不到"admin"） - URL 编码需解码（比如前端传来的
"user%40example.com"要先decodeURIComponent再比对） - 全角/半角字符要归一（如中文顿号、英文逗号、全角空格等，按业务约定统一替换）
Set 初始化要一次到位，避免运行时动态扩容
高频调用场景下，反复 add 会触发内部哈希表重散列，带来毛刺。推荐做法：
- 黑名单规则从配置文件或远程服务加载后，一次性构造 Set：
new Set(blacklistArray.map(s => s.trim().toLowerCase())) - 若规则可能更新，用
Object.freeze()或封装为只读对象，防止误改 - 不建议在请求中实时 new Set，而是复用全局初始化好的实例
匹配逻辑要轻量，别在 has 前做复杂操作
has 方法本身是 O(1)，但前面的预处理如果拖慢，整体就不是毫秒级了：
- 避免在每次调用时重复正则替换、分词、切片等重操作
- 如果需支持模糊匹配（如前缀、子串），Set 不适用，应换 Trie 或分词+倒排索引
- 纯关键词拦截场景，直接
blacklistSet.has(normalizedKeyword)即可，不要包装成函数再加日志、计数等副作用 - 移动端或低配服务端注意 V8 / JavaScriptCore 对短字符串的优化，过长关键词（如超 200 字符）建议截断或走其他机制
配合简单缓存提升批量判断效率
当一次请求含多个关键词（如评论含 5 个词），逐个 has 没问题；但若频繁判断相同组合，可加一层记忆：
- 对关键词数组排序后拼接成 key，缓存结果（适合固定组合场景，如标签校验）
- 更通用的做法：用
Array.every(word => blacklistSet.has(word))判断是否全部安全，或Array.some快速发现首个命中项 - 不推荐用 Map 缓存每个关键词的布尔结果——Set 本身已是最佳结构，额外缓存反而增加内存和管理成本
