欢迎 PR，/assign @Menci

@Menci 非常感谢你的建议。

建议现在 issue 中描述一下具体的实现思路后再写代码。

大体看了一下项目架构，感觉应该在 handleCommentNewEvent 中（也就是发邮件的地方）处理评论后的逻辑。

首先在评论设置里加入两个选项：「Akismet API Key」和「评论过滤设置」。在「评论过滤设置」中可以选择：删除垃圾评论和垃圾评论需要审核。

原「SMTP 服务」改为「通知设置」，将原有的两个二级 Tab 改为一个二级 Tab「SMTP 服务」，并添加一个二级 Tab「Telegram Bot」，其中包含四个设置项：

• Telegram Bot Token
• Telegram 收件人
• Telegram API 地址（可能有用户需要使用反向代理）
• 代理服务器地址（可能有用户需要使用正向代理）

在 handleCommentNewEvent 中将构造的文本信息发往 Telegram 时，如果该评论需要审核，则提供通过/拒绝的选项。当博主回复该消息时自动回复该评论（当博主修改/删除消息时自动修改/删除对应评论？可能有点难？就需要记录更多状态了）。

原「SMTP 服务」改为「通知设置」

和我的想法一致，之前二级 Tab 中的 发送测试 可以去掉了，改为在 SMTP 服务下面加一个测试按钮，其中的收件人默认为管理员邮箱，内容也可以我们固定好。

如果该评论需要审核，则提供通过/拒绝的选项。当博主回复该消息时自动回复该评论（当博主修改/删除消息时自动修改/删除对应评论？可能有点难？就需要记录更多状态了）。

个人建议提供 通过拒绝回复 这三个功能就行了。

嗯，需要审核评论就显示 通过拒绝 ，不需要审核就显示 删除 。

另外提一下，建议评论过滤和 Telegram 通知分为两个 PR 提交。

前段时间忙了很多事情，最近大概可以有空来做这个了。这段时间接触了一些 microservice 和 serverless 的东西，想到了一种比直接在 Halo 里添加这两个功能更好的思路：webhook。就像 GitHub 的 webhook 一样。

用户可以在 Halo 中配置 webhook：设置一个私钥，和一些 webhook 地址。并且用户可以设置在一些事件（比如，目前只有被评论这一个事件）发生时，让 Halo 去调用 webhook。

每当有新评论时，用户配置的接受评论事件的 webhook 就会被调用，传入带签名的 payload，payload 中有评论的信息、内容还有带签名的显示/隐藏/删除评论的 POST 链接，用户可以在 webhook handler 里实现各种功能，比如内容过滤和通知。

这样的好处一是整个系统的可扩展性会提高，二是把这部分功能放在外部可以更方便用其他语言写逻辑。

然后原本的过滤和通知的功能，我打算基于 Cloudflare Worker 的写一个 webhook handler 来实现。

@Menci 是的，Webhook 会更具有扩展性，这个 issue 也提到了。#1585 (comment)

我之前没接触过 Java 开发，对 Java 特别是 Spring 编码模式不太了解 …… 根据在 Nest 里的经验，初步的想法是：

• 加入两个 Entity：Webhook，WebhookRecentDelivery
• 加入一个 Service 和一个 ServiceImpl：WebhookService
• 在 BaseCommentService 的 Impl 中的 create 方法中加入对 WebhookService 中 invokeWebhook 相关函数的调用
• 加入 WebhookController，处理对 Webhook 的 CRUD 和对 WebhookRecentDelivery 的操作