给评论区加装“防弹衣”：Cloudflare Workers 敏感词过滤与高性能缓存实战

前两天刚分享了如何用 Cloudflare D1 + Workers 搭建零成本评论系统，结果一上线就发现，自建系统虽然爽，但面临的安全压力也不小。为了防止网站被不文明言论搞得“查水表”，也为了防御恶意爆破，今天我给评论区来了一次全方位的“防弹衣”升级。

一、敏感词过滤：从本地到云端

首先是解决敏感词问题。我在 GitHub 找了一个包含近 5 万条记录的常用敏感词库（腾讯版）。如果不处理，直接在代码里判断效率极低。

我的方案：

• 存储：将 5 万条敏感词整合成 JSON 数组，存入 Cloudflare 的 KV 存储中。
• 拦截：在 Worker 逻辑中，提交评论前先从 KV 获取词库进行 some.includes() 比对。一旦命中，直接返回 400 错误码并提示用户。

二、高性能：内存缓存大法

如果每发一条评论都要去请求一次 KV 数据库，不仅会增加几十毫秒的延迟，还会产生大量的 KV 读取额度消耗。

优化方案：利用 Worker 的“热启动”特性，在 export default 外层定义一个全局变量 let cachedSensitiveWords = null;。

脚本逻辑变为：如果缓存为空，才读一遍 KV；只要 Worker 还在运行（热启动状态），后续请求全部走内存。这让拦截速度达到了毫秒级，几乎零感知。

三、IP 记录与一键和谐

为了后续能够精准封禁恶意用户，我对 D1 数据库进行了结构升级：

ALTER TABLE comments ADD COLUMN ip TEXT;

通过 Worker 获取 request.headers.get('CF-Connecting-IP') 并静默存入数据库。同时，对于历史上已经产生的顽固脏话，我通过 SQL 的 REPLACE 函数进行了一键批量和谐。

四、防刷机制：基于 IP 的频率限制

虽然 Cloudflare 有付费版的 WAF，但咱们个人站长能省则省。我直接在代码层写了个频率限制逻辑：

SELECT count(*) as count FROM comments 
WHERE ip = ? AND created_at > datetime('now', '-1 minute')

同一 IP 每分钟发言超过 5 次即直接拦截。经过测试，这种方式消耗的 D1 查算力极低，但防御效果非常显著。

五、前端交互优化

由于回复表单是动态生成的，之前报错提示老是弹在页面最底部。我重构了 showStatus 函数，让它能接收一个 targetForm 参数，从而让拦截提示能精准弹出在对应的输入框上方。

总结

经过这一套组合拳，评论区不仅更安全了，性能反而因为缓存机制变快了。如果你也在用 Cloudflare 搭建服务，这套“敏感词 KV + 内存缓存 + IP 限流”的方案非常值得参考。

最后说一句：折腾也是一种乐趣！下次咱们聊聊怎么接入更强的 Turnstile 验证码。