我最近想给博客加评论系统。
一开始看了一圈方案，发现评论这件事很容易被做复杂：GitHub Issues、Discussions、Vercel、Serverless、云数据库、对象存储、验证码、邮件通知、反垃圾服务。每一个单独看都不难，但拼在一起，就会变成一个小型运维项目。
我的需求其实很朴素：
- 不想把评论托管到 GitHub。
- 不想为了评论系统再引入一堆云服务。
- 数据最好在自己手里，能备份，能迁移。
- 早期博客流量不大，不需要一上来就搞复杂架构。
所以最后我选了 Waline，并且准备直接部署在自己的 VPS 上，用 SQLite 存评论数据。
这不是最“现代云原生”的方案，但它足够简单，也足够可控。
为什么不是 GitHub 托管评论
GitHub Issues 类评论系统最大的好处是轻。比如 utterances、giscus 这类方案，本质上是把每篇文章对应到 GitHub 的 issue 或 discussion，前端加载一个组件，评论就能跑起来。
如果博客本来就是面向开发者，并且读者都有 GitHub 账号，这确实很舒服。
但我不太想这么做。
第一，评论数据不在自己手里。它当然可以导出，但日常形态还是依赖 GitHub。哪天想迁移，评论和文章之间的映射、用户身份、回复关系，都要再处理一次。
第二，评论门槛变高。很多读者只是想随手留一句话，让他登录 GitHub，心理成本其实不低。
第三，我不希望一个中文个人博客的互动入口默认绑定到开发者平台。博客可以聊 AI、工具、交易、内容运营，也可以聊一些更日常的东西。评论系统最好别先替读者筛选身份。
所以我的方向是：评论系统可以轻，但数据要尽量留在自己这边。
为什么选 Waline
Waline 对我来说比较像一个平衡点。
它不是只有前端组件，也不是完整论坛系统。它有服务端，有管理后台，有数据库，也有比较成熟的博客主题集成。对 Hugo 来说，接入成本很低，我现在用的 Dream 主题本身就支持 Waline。
我看重的点主要有几个：
- 可以匿名评论，不强迫读者用 GitHub 登录。
- 有后台管理，评论、审核、用户都能看。
- 支持评论审核，刚上线时可以先人工放行。
- 支持多种数据库，早期可以 SQLite，后面需要再迁移。
- 前端接入轻，Hugo 里加一段配置或 partial 就够。
它不是最强大的社区系统，也不应该被当成论坛。但给个人博客做评论区，刚好合适。
为什么不用 Vercel + 云数据库
Waline 官方推荐过 Vercel 这类部署方式，早期博客用免费额度也确实能跑。
但我想了一下，还是觉得没必要。
Vercel 本身不复杂，云数据库也不复杂，可是一旦组合起来，事情就变成：
- Vercel 项目在哪里。
- 数据库在哪里。
- 环境变量在哪里。
- 免费额度还够不够。
- 域名怎么绑。
- 以后迁移时评论数据怎么搬。
这些都能解决，但它们不是我真正关心的问题。
评论系统对我来说不是核心业务，只是博客旁边的一张小桌子。我希望它安静地放在那里，能用，能备份，别让我为了它维护一串服务依赖。
既然我已经有 VPS，那最简单的方案就是把 Waline 跑在 VPS 上。
VPS + SQLite 的好处
这个方案的结构很直接：
fomoxx.com 文章页面
|
| 加载 Waline 前端组件
v
comments.fomoxx.com
|
| Nginx / Caddy 反向代理
v
Waline Docker 容器
|
v
SQLite 文件
它的优点很明显。
第一，依赖少。一个 Docker 容器，一个数据目录，一个反代配置，就可以跑。
第二，数据清楚。评论都在 SQLite 文件里，备份就是备份一个目录。相比一堆云服务控制台，这种朴素反而让人安心。
第三，成本稳定。VPS 反正已经在付钱，评论系统多占一点点 CPU、内存和磁盘，不需要额外为 Serverless 或数据库免费额度分神。
第四，迁移不难。以后如果评论量真的起来，再迁到 PostgreSQL 或 MySQL，也比一开始就为了“可能的规模”把架构做重更合理。
大概怎么部署
我会用 Docker Compose 跑 Waline，把服务只暴露到本机端口，再用 Nginx 或 Caddy 做 HTTPS 反代。
一个简化版配置大概是这样：
services:
waline:
image: lizheming/waline:latest
container_name: waline
restart: unless-stopped
ports:
- "127.0.0.1:8360:8360"
volumes:
- ./data:/app/data
environment:
TZ: Asia/Shanghai
SQLITE_PATH: /app/data
SQLITE_DB: waline.sqlite
JWT_TOKEN: "换成一串足够长的随机字符串"
SITE_NAME: fomoxx
SITE_URL: https://fomoxx.com
SECURE_DOMAINS: fomoxx.com,comments.fomoxx.com
COMMENT_AUDIT: "true"
IPQPS: "60"
这里有几个配置我会优先打开。
COMMENT_AUDIT=true 表示评论需要审核后再展示。博客刚开评论区时，我宁愿多点一次审核，也不想让垃圾评论直接出现在文章下面。
SECURE_DOMAINS 用来限制允许调用评论服务的站点域名，避免别人随便拿我的 Waline 服务当公共接口。
IPQPS=60 是频率限制，同一个 IP 不要太频繁提交。它挡不住所有攻击，但能挡掉一部分低成本刷接口。
反代层我会单独使用 comments.fomoxx.com，而不是把评论服务挂在主站路径下。这样以后迁移、替换、限流、加防护都更清楚。
最重要的是备份
SQLite 最大的优点是简单，最大的风险也是简单：它就是一个文件。
所以这个方案一定要做备份。
我的最低要求是每天备份一次 Waline 的 data 目录，并且至少保留最近 7 天。如果 VPS 本身还有快照，那更好，但不要只依赖快照。
备份可以很朴素：
tar -czf waline-$(date +%F).tar.gz /opt/waline/data
然后再把压缩包同步到另一台机器、对象存储或本地 NAS。
个人博客的评论量不会像交易系统一样高，但评论一旦积累起来，就是内容的一部分。它不一定值钱，但很值得保留。
我的最终选择
所以这次的选择很简单：
- 评论系统：Waline
- 部署位置：自己的 VPS
- 数据库：SQLite
- 访问域名：
comments.fomoxx.com - 展示策略：默认开启审核，通过后显示
- 运维重点：备份数据目录，而不是追求复杂架构
我喜欢这个方案的地方在于，它没有假装自己很高级。
它只是把评论系统放回了它该在的位置：一个轻量、独立、可备份的小服务。