Waline：给博客加一个自己说了算的评论区

11次阅读

获取下载链

微信关注「软件教程管家」公众号，回复 waline

30 秒速读：博客评论区最怕两件事，一是数据不在自己手里，二是规则由别人说了算。Waline 是一套自托管评论方案，把评论、前台展示、审核和通知都装进你自己的服务端和数据库里。本文讲的自托管评论路线，适合愿意自己维护一个小服务的站长，不适合只想贴一段代码就完事的人。

项目信息

项目	内容
软件名称	Waline
软件类型	自托管评论系统
适用站点	个人博客、技术文档站、静态内容网站
部署方式	Vercel、Docker、自托管等多种平台
存储选择	PostgreSQL、MySQL、SQLite、TiDB、MongoDB、CloudBase
核心能力	Markdown 评论、登录、审核、通知、反滥用控制
费用口径	项目本身开源，服务器与数据库开销取决于所选平台

自托管评论怎么选：先定数据库，再定平台

结论先行：不要先挑部署平台，先看你手里已经有什么。已经有数据库和服务器的站，直接复用现有组合，别为了一个评论区另起一套陌生的架构；从零开始的个人博客，选一个你会备份、出了问题知道去哪里看日志的组合，比选一个看起来功能最多的组合更重要。平台与数据库的搭配关系，决定了你以后每一次升级、迁移和排障的成本，这个取舍要在动手之前定下来，而不是部署到一半再换。

取舍的标准就三条：第一，数据以后能不能完整带走；第二，评论写入、审核、通知这条通路你能不能独立复现；第三，服务器挂了、数据库满了、平台改了规则，你有没有人能处理。三个问题有一个答不上来，就先把规模缩小，先跑通再放大。

Waline 与另外两条路线的横向对比

维度	Waline 自托管	第三方托管评论	自己从零写评论
数据归属	存在自己的数据库里	存在服务商一侧	完全自己掌控
上手成本	中等，要部署服务端与客户端	最低，贴代码即可用	最高，从存储到审核全要自己写
审核与规则	自己定审核、频率与关键词规则	受服务商规则约束	全部自己实现
长期运维	要管备份、升级与平台变化	基本不用管运维	运维与功能迭代全是自己的活

一句话取舍：想要数据自主又不想从零造轮子，选 Waline；只想省事、不在乎数据放在谁手里，选托管服务；已有成熟后端团队、评论只是整体系统的一小块，才考虑自己写。

Waline 部署的关键卡点

部署不必一次做全，先把一条完整通路跑通，再开放给读者。关键卡点只有五个：

先定数据库。按上文的取舍定好存储后端，再去部署服务端，顺序反了容易返工。
再部署服务端。按所选平台的部署文档走完配置，拿到可用的服务端地址，先不要急着接前台。
把客户端接到页面。客户端负责前台的评论输入与展示，接好后先确认页面能正常加载评论区。
通路自测。自发一条测试评论，走完审核、通知、前台显示、文章计数这一整条线，任何一环不通都先修好再公开。
最后开放入口。确认审核与反垃圾规则已经生效，再把评论区交给真实读者。

最常见的返工，就是跳过第四步直接公开，结果通知没到、审核没拦、计数没变，回头再查反而更费时间。

装完必改的四个设置

以下四个设置建议在公开之前逐一改好，每个都直接影响读者的实际体验：

评论审核默认规则：入口在管理后台的审核相关设置里。改成先审后放，体感差别是垃圾评论不会直接出现在读者面前，你每天只需要处理待审队列，而不是去删已经公开的内容。
新评论通知渠道：入口在管理后台的通知设置里，按自己真正会看的渠道接通邮件、微信、QQ 或 Telegram 中的一种。体感差别是读者留言后你能及时知道，而不是隔几天才发现评论区已经积了一堆未读。
反垃圾组合：入口在管理后台的评论治理设置里，把评论频率限制、关键词限制、IP 禁止列表和重复内容检查搭配着开。体感差别是刷屏和重复灌水会被挡在门外，正常读者的评论不受影响。
登录方式与界面语言：入口在管理后台的登录与语言设置里，按读者群体定好登录方式和显示语言。体感差别是读者不用在登录环节卡住，也不会因为语言不对而放弃留言。

这四个设置改完，评论区才算从“能跑起来”变成“敢交给读者用”。