起源：Valine + LeanCloud

博客最早期用的评论系统是 Valine.js。当时整套方案完全是前端操作，后端找一个 SaaS 提供对象存储服务。在 2017、2018 年左右，大部分博客系统推荐的都是 Valine.js + LeanCloud 这套组合 —— 存储免费、够用也好用，基本上大家都用 LeanCloud。

中途 Valine 爆出过漏洞。毕竟它是纯前端的，Token 之类的敏感信息都直接写在页面里，很容易泄露。一旦泄露，别人就能拿你的 Token 去读写数据 —— 更恶心的是，可以往里面乱写一通，直接把你的博客评论刷满无意义内容甚至危险内容。

漏洞出来后没多久，就有人在 Valine 的基础上做了一个新框架 —— Waline。主要改进有几点：在 Valine 上套了一层 Web 服务，可以直接跑在 Vercel 上；把敏感信息都放到了后端，所有数据操作都通过后端服务完成；另外还提供了一个管理后台，方便内容管理。

我当时也注意到了 Valine 的安全问题，所以 Waline 一出来我就跟着换了。当时博客主题还不支持 Waline，我自己手动改的支持，用着也算稳定。

至于 Waline 本身，体感反而一般，主要是 breaking changes 太多。最开始用的是 V1，后来升到 V2，按它的使用方式，客户端一直引用最新版本，而服务端是自己部署、版本写死的，随着不断迭代，很容易出现客户端升级了但服务端没升级、两边版本不 match、系统直接用不了的情况。所以中间有段时间我干脆把客户端也锁了版本，不让它自动升级。

迁移的契机

今天下午我发现评论区有几个明显是影视资源网的人，组团过来刷广告评论。内容看着挺多，但一看就是 AI 生成的。

把这些垃圾评论屏蔽之后，我突然意识到 —— 我已经多久没正经看过自己的评论系统了？甚至我几乎连 LeanCloud 这个平台叫什么都差点想不起来。一想到博客这么多年的评论数据都躺在一个我连名字都快忘了的服务上，心里有点没底：万一这家公司哪天悄悄关停，数据不就一起没了？于是琢磨着把评论数据导出来，看要不要迁移到其他平台，比如 Cloudflare。

结果一登录 LeanCloud，担心立刻就应验了 —— 他们宣布要在 2027 年 1 月停止对外服务了（公告链接）。

这里也提醒一下大家：LeanCloud 这个服务马上就要关停了，很多老用户可能还在用 Waline 或 Valine 这种基于 LeanCloud 的方案，突然不能用的话挺麻烦的，记得提前做好数据迁移。

实际迁移

真正动手的时候，我本来想图省事 —— 只迁数据源，前端那些都不动。

不看不知道，一看发现这次大版本升级，数据源都换了，连数据表结构都有变化。当然，可能是因为 LeanCloud 不再支持，他们直接换了。但是文档里把 LeanCloud 相关的部分全删了，搞得好像 LeanCloud 从来没出现过一样 —— 现在直接推荐的数据源已经变成了 Vercel 的 PostgreSQL，这变化挺让人疑惑的，对老用户的迁移也实在不友好。

旧数据源迁移挺不好办的，只能根据历史数据的字段对着看。还好之前都是对象存储，字段都在，能猜出来大概是什么、该怎么映射。虽然官方提供了一个数据迁移工具，但只能迁 comment（评论内容）。我尝试把计数表也塞进去，发现不行 —— counter（计数器）这部分官方工具转不了。

干脆直接上 CodeX。把数据库连接字符串和新表的 SQL 定义都丢给它，让它自己执行映射导入就完事了。

数据源搞定之后，还得把服务端和客户端也同步升级到 V3。

服务端这边，我当初是按官方 example 目录建了一个仓库，再部署到 Vercel 上的 —— 所以升级服务端，本质上就是把这个仓库更到 V3 最新的 example。当时是一键创建的，本地没有这份仓库，索性这事也继续丢给 CodeX 去搞。流程大致是这样：先开一个新分支部署一个版本，看看功能行不行；确认 OK 之后再合并到 master 全量发布；服务端管理页面跑通了，再把博客客户端那边也从 V2 升到 V3，顺便检查页面显示、阅读数、评论的展示和发送是不是都正常。这些都过了，基本就 OK 了。

这里有个坑要单独提一下：V3 把 JS 改成了 Module 方式导入。如果你还在用普通的 <link> 或 <script> 标签导入，会直接报错，必须用 type="module" 才能正常解析和显示。

现状与后续

现在评论数据和访问量数据都迁到 Vercel 的数据库了，Waline 也顺便升到了 V3，至少 LeanCloud 那边的隐患算是解了。

不过升上来之后，又发现了一个新的吐槽点：评论下方多了一个订阅评论的 RSS 功能。我觉得挺鸡肋的 —— 我已经开了邮件回复提醒，完全没必要再订阅 RSS。更难受的是只能在客户端找到一个关闭显示的选项，服务端关不掉，有点浪费资源，只能把前端入口先隐藏掉。说到底，一个评论系统真的需要这么多新功能吗？我觉得并不需要。

折腾完这一圈，我倒是冒出来一个新想法 —— 既然现在 AI 这么强，那干脆自己造一套轮子算了，把评论系统重新手写一遍。

而且我还有一个一直没解决的需求：博客除了 Waline，还另外跑着一套 Umami 做访问数据统计，数据源是某个 SaaS 数据库（好像是 TiDB）。Umami 比 Waline 的统计详细得多 —— 除了访问量，还有请求来源、地区、浏览器、操作系统等等。它和 Waline 的功能其实有不少重合，但 Waline 缺少一个专门显示统计信息的地方，所以一直是分两套用。

如果真要自己写，那就索性把这两套一起整了 —— 评论 + 详细统计放进同一套系统里，数据源也归到一处，省得过几年又翻出来，发现自己的数据躺在某个谁都没听说过的服务上，跟今天的 LeanCloud 一样。