社交场景设计

本文我们来做一个小场景：

【注意，本文借鉴内容偏多，引用的内容较多，如果想看原文，可以点击参考里面的链接查看原文】

1.引入

场景一：社交平台实时评论审核

用户在帖子下发表评论，内容需实时审核是否包含敏感词；
为了防止刷屏或恶意评论，需对每个用户或 IP 做限流。

这个时候我们要做一下：

入口限流
- 在网关层或前端 API 服务，应用令牌桶（Token Bucket）或漏桶（Leaky Bucket）算法，对单个用户（或单个 IP）做 QPS／TPS 限制。
DFA 过滤
- 请求通过限流后，进入文本审核模块。
- 利用 DFA 构建一棵敏感词自动机，对评论文字做单次扫描，时间复杂度 O(n)。
- 若检测到敏感词，则返回“含违规内容”，同时可记录复审日志。

场景二：评论/私信接口防刷与内容合规

电商平台的商品评论、卖家私信接口，既要防止机器刷单，又要保证留言内容不违规。
接口调用量巨大，对审核时延和吞吐都有严格要求。

还有平时我们发弹幕，发得太快了，系统会提示你 “发得太频繁了”【限流降级一下】，如果你还有违禁词，还会给你变成星星处理【敏感词处理】。

...... 等等等

我相信大家都或多或少遇到过该情况的。那么本文就来探讨一下限流和 敏感词过滤

2.限流算法

限流，也称流量控制。是指系统在面临高并发，或者大流量请求的情况下，限制新的请求对系统的访问，从而保证系统的稳定性。限流会导致部分用户请求处理不及时或者被拒，这就影响了用户体验。所以一般需要在系统稳定和用户体验之间平衡一下。

比如说秒杀抢购，保护自身系统和下游系统不被巨型流量冲垮等

①固定窗口限流

将时间切分为等长的固定窗口（如每秒、每分钟），对每个窗口内的请求计数，超过阈值即拒绝。

这种算法实现简单，计数操作开销低；适用于对“平均速率”要求不高的场景。

但是要想一下这种问题，那就是边界问题：窗口边界突刺：如限 100 次/分钟，59 秒内 100 次 + 新窗口开始（第61秒） 100 次，这三秒内瞬间可达 200 次。

如上图所示，加入每一秒的请求数最多四个的话，在窗口的边界，上图可以看到这六个请求都是被放行的。

public class FixedWindowLimit implements Limit {
 private final ConcurrentHashMap<String, Pair> resourceMap = new ConcurrentHashMap<>(2);
 // 默认每个资源每秒访问50次
 @Override
 public synchronized boolean isAccess(Resource resource) {
 long now = System.currentTimeMillis();
 Pair pair = resourceMap.computeIfAbsent(resource.getName(), k -> new Pair(50, 1000, System.currentTimeMillis()));
 long start = pair.getWindowStart();
 int windowSize = pair.getWindowSize();
 if (now - start >= windowSize) { // 超过窗口时间，重置窗口
 pair.setInit(now);
 return true;
 } else {
 pair.add();
 // 超过窗口内最大请求数，拒绝
 return pair.getCount().get() <= pair.getMaxCount();
 }
 }
 @Data
 private static class Pair {
 private int maxCount; // 窗口内最大请求数
 private int windowSize; // 窗口大小，单位毫秒
 private Long windowStart; // 窗口开始时间
 private AtomicInteger count; // 窗口内请求数
 public Pair( int maxCount, int windowSize, Long windowStart) {
 this.maxCount = maxCount; this.windowSize = windowSize;
 this.windowStart = windowStart; this.count = new AtomicInteger(0);
 }
 public void add() {
 this.count.incrementAndGet();
 }
 public void setInit( long newTime) {
 this.count.set(1);
 this.windowStart = newTime;
 }
 }
}

②滑动窗口限流

基本思想

时间窗口动态滑动：将时间划分为多个小的时间片段（如1秒分为10个100ms的格子），窗口随着时间推移向前滑动。
统计窗口内请求数：仅统计当前时间点向前滑动一个完整窗口时长内的请求数量，超出阈值则拒绝请求。

为了平滑限流，将时间窗口动态滑动，通过两个相邻固定窗口的加权计数来近似当前窗口内请求数。

如上图所示，滑动窗口将窗口划分为了多个小的时间片段，只统计当前窗口内的请求数就可以了，窗口移动的时候，将前面的时间槽丢弃掉。

限流精准：避免固定窗口的边界问题，流量控制更平滑。
灵活调整：时间片粒度可调（越细越精准，但开销越大）。

public class SlidingWindowLimit implements Limit {
 private static final ConcurrentHashMap<String, Pair> map = new ConcurrentHashMap<>(2);
 @Override
 public synchronized boolean isAccess(Resource resource) {
 long now = System.currentTimeMillis();
 Pair pair = map.computeIfAbsent(resource.getName(), k -> new Pair(100, 1000, 10));
 pair.refreshSlot(now);
 // 窗口内计数器总和超过阈值，则丢弃后续请求
 if (pair.getSum() >= pair.getMaxCount()) {
 return false;
 } else {
 pair.add();
 return true;
 }
 }
 @Data
 private static class Pair {
 private int maxCount; // 阈值
 private int windowSize; // 窗口大小[毫秒]
 private int slotCount; // 窗口内区间个数
 private int slotSize; // 区间大小[毫秒] windowSize/slotCount
 private long lastRefreshTime;
 private Queue<Integer> slots; // 区间计数器队列
 public Pair( int maxCount, int windowSize, int slotCount) {
 this.maxCount = maxCount;
 this.windowSize = windowSize;
 this.slotCount = slotCount;
 this.slotSize = windowSize/slotCount;
 this.slots = new LinkedList<>();
 for (int i = 0; i < slotCount; i++) {
 slots.offer(0);
 }
 this.lastRefreshTime = System.currentTimeMillis();
 }
 public void add() {
 Integer poll = slots.poll();
 poll = poll == null ? 0 : poll;
 slots.offer(poll + 1);
 }
 public int getSum() {
 return this.slots.stream().mapToInt(Integer::intValue).sum();
 }
 public void refreshSlot( long now ) {
 long timePassed = now - lastRefreshTime; // 已流逝的时间
 if ( timePassed >= slotSize ) { // 超过区间时间 -- 说明要移动窗口
 int goAhead = (int) timePassed / slotSize; // 需要往前移动几个区间
 int end = Math.min(slotCount, goAhead);
 for (int i = 0; i < end; ++i ) {
 // 移除窗口
 slots.poll();
 slots.offer(0); // 添加区间
 }
 lastRefreshTime += (long) goAhead * slotSize;
 }
 }
 }
}

他有什么缺点呢？

实现复杂：需维护多个时间片的计数器和滑动逻辑。
资源消耗高：时间片越多，内存和计算开销越大。

实际上我们可以借助Redis的zset来辅助实现滑动窗口的限流：

Redis ZSET 特性：

用 ZSET 存储请求的时间戳（score）和唯一标识（member）。
通过 ZREMRANGEBYSCORE 删除过期的请求，通过 ZCOUNT 统计当前窗口内的请求数。

主要是下面两个命令：

ZREVRANGEBYSCORE key min max 移除有序集合中给定的分数区间的所有成员

ZCARD key 获取有序集合的成员数

import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.data.redis.core.ZSetOperations;
import java.util.concurrent.TimeUnit;
public class SlidingWindowLimiter {
 private final RedisTemplate<String, String> redisTemplate;
 private final String keyPrefix; // 限流Key前缀（如 "rate_limit:api1"）
 private final long windowMillis; // 时间窗口长度（毫秒）
 private final int maxRequests; // 窗口内允许的最大请求数
 public SlidingWindowLimiter(RedisTemplate<String, String> redisTemplate, String keyPrefix, 
 long windowMillis, int maxRequests) {
 this.redisTemplate = redisTemplate;
 this.keyPrefix = keyPrefix;
 this.windowMillis = windowMillis;
 this.maxRequests = maxRequests;
 }
 /**
 * 检查是否允许请求
 * @param userId 用户标识（用于区分不同用户）
 * @return true: 允许；false: 拒绝
 */
 public boolean allowRequest(String userId) {
 String key = keyPrefix + ":" + userId;
 long now = System.currentTimeMillis();
 long windowStart = now - windowMillis;
 // Lua脚本保证原子性操作
 String luaScript = 
 "local key = KEYS[1]\n" +
 "local now = tonumber(ARGV[1])\n" +
 "local windowStart = tonumber(ARGV[2])\n" +
 "local maxRequests = tonumber(ARGV[3])\n" +
 "local member = ARGV[4]\n" +
 "\n" +
 "-- 删除窗口外的旧数据\n" +
 "redis.call('ZREMRANGEBYSCORE', key, 0, windowStart)\n" +
 "\n" +
 "-- 获取当前窗口内的请求总数\n" +
 "local count = redis.call('ZCARD', key)\n" +
 "\n" +
 "-- 判断是否超过阈值\n" +
 "if count >= maxRequests then\n" +
 " return 0\n" +
 "else\n" +
 " -- 添加当前请求\n" +
 " redis.call('ZADD', key, now, member)\n" +
 " -- 设置Key的过期时间（避免冷数据长期占用内存）\n" +
 " redis.call('PEXPIRE', key, windowMillis + 1000)\n" +
 " return 1\n" +
 "end";
 // 执行Lua脚本
 Long result = redisTemplate.execute(
 new DefaultRedisScript<>(luaScript, Long.class),
 List.of(key),
 String.valueOf(now),
 String.valueOf(windowStart),
 String.valueOf(maxRequests),
 String.valueOf(now) + ":" + UUID.randomUUID() // 唯一标识
 );
 return result != null && result == 1;
 }
}
/*
(1) 原子性保障
Lua脚本：将 ZREMRANGEBYSCORE（清理旧数据）、ZCARD（统计请求数）、ZADD（记录新请求）合并为原子操作，避免并发问题。
(2) 内存管理
自动过期：通过 PEXPIRE 设置 Key 的过期时间（窗口长度 + 缓冲时间），防止长期不用的 Key 占用内存。
*/

③令牌桶限流

令牌桶算法的原理是系统会以一个恒定的速度往桶里放入令牌，而如果请求需要被处理，则需要先从桶里获取一个令牌，当桶里没有令牌可取时，则拒绝服务。【引用的参考链接1中的图片】

优点

支持突发：令牌在空闲时累积，请求可一次性消耗多枚令牌，应对短时高峰
平均速率可控：长期看，令牌生成速率决定了整体吞吐上限，既可平滑亦可灵活

缺点

需令牌维护：要定期“填充”令牌，并维护当前令牌数状态，带来额外逻辑开销
可能延迟突发处理：如果令牌已被消耗，突发请求仍然会被拒绝或延后处理

public class TokenBucketLimit implements Limit {
 private static final int MAX_TOKEN = 50; // 每个桶最大50个
 private static final int FILL_RATE = 5; // 每秒往桶中放5个令牌
 private final ConcurrentHashMap<String, Pair> limitMap;
 public TokenBucketLimit() {
 limitMap = new ConcurrentHashMap<>(2);
 }
 @Override
 public synchronized boolean isAccess(Resource resource) {
 long now = System.currentTimeMillis();
 String name = resource.getName();
 Pair pair = limitMap.get(name);
 if (pair == null) { // 说明该接口没有被访问过
 limitMap.put(name, new Pair(now, MAX_TOKEN));
 return true;
 } else {
 // 1.先放令牌
 addToken(now, pair);
 // 2.取令牌
 if (pair.getToken().get() > 0) {
 pair.getToken().decrementAndGet();
 return true;
 }
 }
 return false;
 }
 private void addToken(long now, Pair pair) {
 long during = now - pair.lastFillTime;
 int v = (int) (during * 1.0 / 1000 * FILL_RATE);
 if (v > 0) {
 pair.setToken(Math.min(MAX_TOKEN, pair.getToken().get() + v));
 pair.lastFillTime = now;
 }
 }
 @Data
 @AllArgsConstructor
 @NoArgsConstructor
 private static class Pair {
 private long lastFillTime; // 上一次填充令牌的时间戳
 private AtomicInteger token; // 令牌桶
 public Pair(long lastFillTime, int token) {
 this.lastFillTime = lastFillTime;
 this.token = new AtomicInteger(token);
 }
 public void setToken(int token) {
 this.token.set(this.token.get() + token);
 }
 }
}

④漏桶

漏桶算法是一种经典的流量整形（Traffic Shaping）和限流（Rate Limiting）算法，通过固定速率处理请求，无论请求的到达速率如何波动，系统的处理速率始终保持恒定，从而平滑突发流量，保护下游系统不被压垮。其核心思想类似于“水桶漏水”——无论水流多快，漏水的速率是固定的。

漏桶容器：
- 所有请求先进入漏桶队列（桶的容量固定）。
- 若桶已满，新请求被拒绝（溢出）。
恒定漏水速率：
- 漏桶以固定速率（如每秒10次）处理队列中的请求，无论请求的到达速率多快。如下图【引用的参考链接1中的图片】

队列版漏桶

我发现它相较于上面三个限流算法，有一个很不一样的点，那就是中间有一个缓冲区，假设它的容量是k，然后漏水的速率也就是请求放行的速率是v，客户端发送过来的请求速率是v1。如果v1 > v的话，缓冲区就会缓存任务，该请求会存在等待的行为。这就是它区别于上述其他三种限流算法的一点。所以，我认为它严格平滑输出（恒定服务速率），适用于能够接受一定排队延迟的场景。

public class LeakyBucketLimiter {
 private final Queue<Request> bucket; // 漏桶队列
 private final int capacity; // 漏桶容量
 private final int leakRate; // 漏水速率（请求/秒）
 private final ScheduledExecutorService scheduler;
 public LeakyBucketLimiter(int capacity, int leakRate) {
 this.capacity = capacity;
 this.leakRate = leakRate;
 this.bucket = new LinkedBlockingQueue<>(capacity);
 this.scheduler = Executors.newScheduledThreadPool(1);
 // 启动漏水任务（固定速率处理）
 scheduler.scheduleAtFixedRate(this::leak, 0, 1000 / leakRate, TimeUnit.MILLISECONDS);
 }
 /** 尝试将请求放入漏桶 */
 public boolean tryAccept(Request request) {
 if (bucket.size() >= capacity) {
 return false; // 桶已满，拒绝请求
 }
 return bucket.offer(request);
 }
 /** 漏水（处理请求） */
 private void leak() {
 if (!bucket.isEmpty()) {
 Request request = bucket.poll();
 processRequest(request); // 实际处理请求的方法
 }
 }
 private void processRequest(Request request) {
 // 实际业务逻辑（如调用下游API）
 System.out.println("处理请求: " + request.getId() + " at " + System.currentTimeMillis());
 }
 /** 关闭限流器 */
 public void shutdown() {
 scheduler.shutdown();
 }
 /** 请求对象示例 */
 static class Request {
 private final String id;
 public Request(String id) { this.id = id; }
 public String getId() { return id; }
 }
 public static void main(String[] args) {
 LeakyBucketLimiter limiter = new LeakyBucketLimiter(10, 5); // 容量10，速率5请求/秒
 // 模拟请求
 for (int i = 0; i < 20; i++) {
 System.out.println("请求 " + i + " 是否被接受: " + limiter.tryAccept(new Request("" + i)));
 }
 }
}

计量版漏桶

该版本不维护显式队列，只用一个计数器（桶水位）和固定的泄漏速率来判定请求是否合规：每次到来请求前，先按漏桶速率“泄漏”令水位下降；若水位加上该请求的水量仍不超过桶容量，则通过并累加水量，否则立即拒绝。【但是这个我觉得不是很符合漏桶算法的模型，并且这个很像令牌桶，令牌桶是先放令牌，再拿走令牌；这里是先漏水，再加水】

public class LeakyBucketLimiter2 {
 // 最大容量（可接受的最大突发量）
 private final double capacity;
 // 泄漏速率：每毫秒可泄漏的“水量”
 private final double leakRatePerMillis;
 // 当前桶中“水位”
 private double water;
 // 上次执行泄漏操作的时间戳（毫秒）
 private long lastTime;
 public LeakyBucketMeter(double capacity, double leakRatePerSecond) {
 this.capacity = capacity;
 this.leakRatePerMillis = leakRatePerSecond / 1000.0;
 this.water = 0.0;
 this.lastTime = System.currentTimeMillis();
 }
 public synchronized boolean tryAcquire() {
 leak(); // 先按速率泄漏旧水
 if (water + 1.0 <= capacity) {
 water += 1.0;
 return true; // 请求合规
 }
 return false; // 请求超限，直接拒绝
 }
 private void leak() {
 long now = System.currentTimeMillis();
 double leaked = (now - lastTime) * leakRatePerMillis;
 // 水位不能低于0
 water = Math.max(0.0, water - leaked);
 lastTime = now;
 }
}

⑤ 其他

单机场景：优先选择Guava RateLimiter（简单）

分布式微服务：推荐Sentinel（功能全面、见后续文章）或Redisson（与Redis深度集成）

网关层防护：Nginx或Spring Cloud Gateway内置限流模块，结合黑白名单策略

3.敏感词过滤

敏感词过滤旨在从用户生成内容（如社交媒体、聊天室、评论区）中识别并移除涉及暴力、色情、政治敏感、隐私泄露等违规词汇或表达。

现在了解到的比较好的方案大致如下：

机器学习与深度学习：结合自然语言处理（NLP）技术分析上下文语义，减少误判（如区分“苹果”作为水果或品牌）；
DFA/Trie树：利用确定有限状态自动机或字典树提升匹配效率，适用于海量敏感词库；

本文就不考虑深度学习了，直接看第二种，我们来手动实现一个简易的dfa算法。

DFA（Deterministic Finite Automaton，确定有限状态自动机）是一种高效的模式匹配算法，尤其在敏感词过滤、文本分析和词法解析领域应用广泛。它的构建基于状态转移树，每个状态对应敏感词中的一个字符，通过嵌套的哈希表或字典树（Trie树）实现层级关系。

具体构建步骤：首先初始化根节点，创建一个初始状态（根节点），通常用Map表示，作为所有敏感词匹配的起点；然后逐字符构建状态转移，例如敏感词“王八蛋”，按顺序处理字符“王”→“八”→“蛋”，对每个字符检查当前层级是否存在对应的子节点。若不存在，新建节点并标记字符，若存在则直接跳转到该节点；最后在敏感词的最后一个字符节点上设置结束标志（如isEnd: true），表示匹配完成。如下json表示【词库： ”王八“、”王八蛋“、”王八儿子“、”傻“】

{
 "王": {
 "isEnd": false,
 "八": { 
 "isEnd": true,
 "蛋": {
 isEnd: true
 },
 "儿":{
 isEnd: false,
 "子": {
 isEnd: true
 }
 }
 }
 },
 "傻": { 
 "isEnd": true 
 }
}
/*
根节点
├── 王 → 八 →（结束标记）
│ ├── 蛋 →（结束标记）
│ └── 儿 → 子 →（结束标记）
└── 傻 →（结束标记）
*/

从上面结构可以看出，王八蛋和王八儿子，他们是共享的前缀，以此来节省空间。

那么，匹配是怎么做到的呢？如果来了一句话 “张三是个王八蛋”：

逐字符扫描与状态跳转

初始状态：从根节点开始扫描文本。
字符“张”“三”“是”“个”：均不在Trie树根节点的子节点中，跳过。
字符“王”：匹配到根节点的子节点“王”，跳转到该节点。
字符“八”：继续匹配到子节点“八”，此时路径“王→八”已构成敏感词“王八”（若需要最短匹配可触发拦截）
字符“蛋”：继续匹配到子节点“蛋”，路径“王→八→蛋”触发敏感词“王八蛋”（最长匹配规则优先）

匹配终止与处理

命中规则：当路径完整匹配敏感词时（如到达“蛋”节点且标记为结束），触发拦截或替换逻辑。
替换示例：将“王八蛋”替换为“*”，输出结果为“张三是个*“

可以看到上述算法，只需要将目标字符串遍历一遍就可以了，时间复杂度是O(n)，在我们最开始的场景来说效率还行，反正一条评论、聊天消息或者弹幕的话，字数通常也不会太多。

public class TrieNode {
 // 子节点(key是下级字符，value是对应的节点)
 private final Map<Character, TrieNode> subNodes = new HashMap<>();
 // 是否是关键词的结尾
 private boolean isKeywordEnd = false;
 // 添加子节点
 public void addSubNode(Character c, TrieNode node) {
 subNodes.put(c, node);
 }
 // 获取子节点
 public TrieNode getSubNode(Character c) {
 return subNodes.get(c);
 }
 // 判断是否是关键词结尾
 public boolean isKeywordEnd() {
 return isKeywordEnd;
 }
 // 设置关键词结尾
 public void setKeywordEnd(boolean keywordEnd) {
 isKeywordEnd = keywordEnd;
 }
}
// 过滤器
public class SensitiveWordFilter {
 private final TrieNode rootNode = new TrieNode(); // 根节点
 private static final char FILTER_FLAG = '*';
 // 0.加载敏感词
 public void loadSensitiveWords(Set<String> sensitiveWords) {
 for (String word : sensitiveWords) addWord(word);
 }
 // 2.过滤敏感词
 public String filter(String text) {
 if (text == null || text.isEmpty()) return text;
 text = normalizeText(text); // 转换为小写并处理全角字符
 StringBuilder result = new StringBuilder(text);
 // 文本长度
 int length = text.length();
 // 遍历文本每个字符作为起始位置
 for (int i = 0; i < length; ++i ) {
 // 从当前位置开始检查敏感词
 int sensitiveWordLength = checkSensitiveWord(text, i);
 if (sensitiveWordLength > 0) {
 // 替换为相同长度的*
 for (int j = 0; j < sensitiveWordLength; j++) {
 result.setCharAt(i + j, FILTER_FLAG);
 }
 // 跳过已处理的敏感词长度
 i = i + sensitiveWordLength - 1;
 }
 }
 return result.toString();
 }
 // 1.添加敏感词到Trie树
 private void addWord(String keyword) {
 if (keyword == null || keyword.isEmpty()) return;
 keyword = normalizeText(keyword); // 转换为小写并处理全角字符
 TrieNode currentNode = rootNode;
 for (int i = 0; i < keyword.length(); ++i) {
 char c = keyword.charAt(i);
 TrieNode node = currentNode.getSubNode(c);
 if (node == null) {
 node = new TrieNode();
 currentNode.addSubNode(c, node);
 }
 currentNode = node;
 // 设置结束标识
 if (i == keyword.length() - 1) {
 currentNode.setKeywordEnd(true);
 }
 }
 }
 // 3.从文本中检查敏感词
 private int checkSensitiveWord(String text, int beginIndex) {
 TrieNode currentNode = rootNode;
 int length = 0;
 boolean isSensitiveWord = false;
 // 从beginIndex开始逐字符检查
 for (int i = beginIndex; i < text.length(); i++) {
 char c = text.charAt(i);
 // 过滤空格，支持如"傻 狗"这样的敏感词检测
 if (c == ' ') {
 length++;
 continue;
 }
 // 获取下一级节点
 currentNode = currentNode.getSubNode(c);
 if (currentNode == null) {
 // 没有匹配的继续字符，终止检查
 break;
 } else {
 // 匹配到一个字符，长度加1
 length++;
 // 如果是关键词结尾，则标记为敏感词
 if (currentNode.isKeywordEnd()) {
 isSensitiveWord = true;
 }
 }
 }
 // 如果不是敏感词，返回0
 if (!isSensitiveWord) length = 0;
 return length;
 }
 // 将文本转换为小写并处理全角字符
 private String normalizeText(String text) {
 StringBuilder sb = new StringBuilder();
 for (char c : text.toCharArray()) {
 // 全角转半角
 if (c >= 65281 && c <= 65374) {
 c = (char) (c - 65248);
 }
 // 统一大小写
 if (Character.isUpperCase(c)) c = Character.toLowerCase(c);
 sb.append(c);
 }
 return sb.toString();
 }
}

DFA通过Trie树实现敏感词的高效匹配，其核心在于公共前缀合并和逐字符状态跳转。实际应用中需结合词库动态更新、语义分析等策略提升准确性。现在我们就实现了这一种过滤方法。但是，这肯定是不足够应对我们这些聪明的人类的，首先如果我们的词库里面有“黄色”，假如说有一条评论是“这个香蕉还没有变成黄色的，不能吃”，那么上面这个dfa算法就不适用了，所以这就引入了一种上下文语境的问题。

// 测试一下
public class SensitiveTest {
 public static void main(String[] args) {
 SensitiveWordFilter filter = new SensitiveWordFilter();
 filter.loadSensitiveWords(Set.of("傻", "王八", "王八蛋", "王八儿子", "黄色"));
 String text = "张三是个大王八，真的是服了，这个黄色的香蕉是留给他的";
 String str = filter.filter(text);
 System.out.println(str);
 }
}
// 张三是个大**，真的是服了，这个**的香蕉是留给他的

敏感词过滤识别当然不可能会这么简单，实际场景可能比我们想到的复杂千百倍，除了上下文语境问题，还可能会有方言、同音词替换、用首字母骂人等等。最佳的肯定是通过人工智能与自然语言处理技术实现精准识别，结合动态规则与上下文分析降低误判率。本文仅简单探索一下DFA算法的实现。

end.参考

https://blog.csdn.net/crazymakercircle/article/details/130035504 【CSDN-限流】

敏感词过滤 + 限流