Twikoo Cloudflare Workers 后端实践：把评论系统跑在边缘

项目地址：https://github.com/whq12520/twikoo-cf-workers

如果你和我一样，希望给静态博客配一套「免费、响应快、无运维」的评论后端，这个项目也许正好适合你。

这个项目是一个 Twikoo 1.6.45 的非官方后端实现，运行在 Cloudflare Workers 上，数据层使用 D1 + KV。

Cloudflare Workers 运行于 V8 隔离环境而非容器中，V8 隔离架构实现瞬时启动，启动时无需等待运行时加载到实例中，几乎完全消除了针对请求的冷启动。

目标很直接：在保证核心评论体验的前提下，尽量降低冷启动延迟和整体资源消耗。

为什么要做这个项目

原版 Twikoo 已经非常优秀，但不同运行环境总会有一些现实约束：

需要更贴近 Cloudflare workers 的实现方式
需要更稳定的边缘响应速度
进一步降低 Cloudflare workers 的配额消耗
不需要关心运维
~~依赖 Cloudflare 的高可用性~~（这么说好像 Cloudflare 在近一年内炸了两次来着❌）

所以这个项目不是简单“换个平台部署”，而是围绕 Cloudflare Workers + D1 + KV 做了后端逻辑重写。

架构选型

整体架构很轻：

Workers：承载所有 API 入口和评论区逻辑
D1 (SQLite)：存储评论与计数数据
KV：存储配置项（例如站点配置、邮件模板等）

这种组合的好处是不需要运维，上手成本低，天然贴近边缘计算场景。

做了哪些功能

目前已覆盖 Twikoo 的大部分核心后端流程，包括：

评论提交、读取、点赞
管理端登录、评论管理、配置管理
评论导入/导出（支持 Twikoo JSON）
访问量计数与评论数统计
邮件通知与即时推送
Cloudflare Turnstile 人机验证
图床上传（7bu/smms/piclist/lskypro/easyimage/chevereto）

此外还补充了一个可能不太实用的小功能：邮件退订（支持按评论 ID 或用户 UID 退订）。

和原版相比的差异与取舍

为了适配 Workers 运行时和 D1 特性，项目做了一些取舍：

XSS 过滤从 dompurify 调整为 xss
IP 归属地依赖 Cloudflare 请求头（地名为英文）
兼容性原因使用 axios-cf-worker 相关方案
暂未实现反垃圾完整项（当前主要依赖 Turnstile）
D1 分页能力受限，评论获取时是完整返回
配置存储在 KV，更改配置时存在同步延迟
URL 路径不会自动统一 /path/ 与 /path

这些限制并不一定是问题，关键在于你的站点场景是否能接受这些边界。

快速部署流程

部署步骤非常直接：

npm install
npm install wrangler
npx wrangler login
npx wrangler kv namespace create "twikoo_kv"
npx wrangler d1 create "twikoo_db"
npx wrangler d1 execute twikoo_db --remote --file=./schema.sql
npx wrangler deploy

然后将 Worker 地址作为前端 envId 配置即可。

如果站点本身也在托管在 Cloudflare，建议把路由挂到与站点同域名路径（例如 www.domain.com/twikoo/*），这样可以减少跨域预检和请求开销，大幅减少 workers 配额消耗。

适合哪些人

我认为它比较适合这几类：

博客部署在 Cloudflare，追求边缘响应
想要依赖 Cloudflare 的稳定性
不想运维传统服务器/容器

写在最后

这个项目本质上是一次“把评论系统工程化到 Cloudflare 原生栈”的实践，给Cloudflare workers这个特定场景一个更贴合的后端实现。

整个项目代码量非常少，不到1500行就实现了大部分功能（

如果你也在折腾静态博客评论系统，欢迎来试一试，也期待基于你的场景继续改造它！