# Discourse是否应该努力成为一个有竞争力的评论平台？

**URL:** <https://meta.discourse.org/t/should-discourse-make-an-effort-to-become-a-viable-comment-platform/274455>\
**Category:** Community Building\
**Created:** [2023年八月9日 04:53 UTC](https://meta.discourse.org/t/should-discourse-make-an-effort-to-become-a-viable-comment-platform/274455 "2023-08-09T04:53:00Z")\
**Posts on this page:** 20\
**Page:** 3

<div class="post-metadata">

**Author:** ![jordan-violet](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/jordan-violet/32/281428_2.png) [@jordan-violet](https://meta.discourse.org/u/jordan-violet)\
**Post date:** [2024年五月12日 23:34 UTC](https://meta.discourse.org/t/should-discourse-make-an-effort-to-become-a-viable-comment-platform/274455/41 "2024-05-12T23:34:09Z")

</div>

我才刚跟上这个帖子——但我当然认为答案是肯定的 🙂

由于我们企业社区的成功（无论是在用户中，还是在我们公司内部），我们的文档团队联系我们，询问我们是否可以为 [documentation.sailpoint.com](http://documentation.sailpoint.com) 构建一个评论系统。从目前来看，我们至少能够实现我们想要完成的_几乎_所有事情：

- 嵌入评论（嵌入功能）
  - 我们还希望根据嵌入内容使用不同的用户发帖，并应用不同的标签集。此功能即将推出：

> <https://github.com/discourse/discourse/pull/26868/files>
>
> Beyond the general settings for embeddings, this PR adds the ability to set \*\*\`t…ags\`\*\* and \*\*\`authors\`\*\* on individual \*\*\`EmbeddableHost\`\*\* records. This allows admins more precise control over content embedded from external hosts into Discourse topics.
> 
> 
> 
> !\[CleanShot 2024-05-10 at 10 44 57\](https://github.com/discourse/discourse/assets/3180866/2606b403-04ca-4e3a-9b10-2eb6114ccf19)

从那里开始，文档团队（和我的团队）想要的一切都在 Discourse 中，使我们能够有效地将此体验与我们其他的“日常”论坛使用区分开来，同时仍然让人们能够评论、接收回复通知等。

- 指定哪些用户可以评论，哪些用户不能评论
- 将分类版主分配给相关主题
- 将这些文档的大量分类从我们的主站点中隐藏起来
  - 分类不可搜索
  - 使用主题组件将其从主分类列表中隐藏
  - 在摘要中隐藏
  - 添加到默认的已静音分类中

- 评论在 n 天后删除
- 其他一些设置……

我当然希望看到这里提到的许多功能得以实现！

---

<div class="post-metadata">

**Author:** ![simon](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/simon/32/339122_2.png) [@simon](https://meta.discourse.org/u/simon)\
**Post date:** [2024年五月13日 01:34 UTC](https://meta.discourse.org/t/should-discourse-make-an-effort-to-become-a-viable-comment-platform/274455/42 "2024-05-13T01:34:25Z")

</div>

> [@jordan-violet](#):
>
> 我们的文档团队联系我们，询问是否可以为 [documentation.sailpoint.com](http://documentation.sailpoint.com) 构建一个评论系统。

目标是允许用户在 [https://documentation.sailpoint.com/](https://documentation.sailpoint.com/) 上创建评论，还是您乐于将评论嵌入到文档网站中，让用户访问您的 Discourse 网站来评论文章？

---

<div class="post-metadata">

**Author:** ![jordan-violet](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/jordan-violet/32/281428_2.png) [@jordan-violet](https://meta.discourse.org/u/jordan-violet)\
**Post date:** [2024年五月13日 01:36 UTC](https://meta.discourse.org/t/should-discourse-make-an-effort-to-become-a-viable-comment-platform/274455/43 "2024-05-13T01:36:48Z")

</div>

前者是我期望并_非常希望拥有_的功能（请CDCK开发），但后者至少满足了我们的最低要求。

我实际上将在不久的将来探索一个想法，让Discourse提供我们的markdown文档（不是在主题中，而是在传统的markdown风格文档中），在这种情况下，评论以及注册发表评论将是全包的。但这项探索尚未开始。

---

<div class="post-metadata">

**Author:** ![simon](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/simon/32/339122_2.png) [@simon](https://meta.discourse.org/u/simon)\
**Post date:** [2024年五月13日 01:56 UTC](https://meta.discourse.org/t/should-discourse-make-an-effort-to-become-a-viable-comment-platform/274455/44 "2024-05-13T01:56:47Z")

</div>

我目前正在研究的方法，在技术上可以允许 Discourse 评论直接在 MkDocs 页面上生成，但这需要使用服务器端框架（Remix、Rails 等）来提供 MkDocs 页面。这将使得在文档站点上对用户进行身份验证（使用 [DiscourseConnect](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974)）成为可能，并且还可以使用内存数据库来缓存之前返回的评论。

（编辑：需要说明的是，我指的是使用 Discourse 作为网站的身份提供者，而不是网站作为 Discourse 的身份提供者。后一种方法是可行的，但对于大多数用例来说过于不灵活。）

不过，要求您的团队做出这样的重大改变可能有些困难。

> [@jordan-violet](#):
>
> 我实际上将在不久的将来探索一个想法，让 Discourse 提供我们的 markdown 文档（不是在主题中，而是在传统的 markdown 风格文档中）

我确信从您的角度来看，如果这一切都在 Discourse 内部完成会更直接，但也可以将 Discourse 用作内容管理系统。在这种情况下，markdown 文档将作为常规的 Discourse 主题生成。Discourse Webhooks 将用于触发在外部站点上生成文档页面。这实际上是我正在设置的 Discourse 评论演示站点所基于的。

---

<div class="post-metadata">

**Author:** ![jordan-violet](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/jordan-violet/32/281428_2.png) [@jordan-violet](https://meta.discourse.org/u/jordan-violet)\
**Post date:** [2024年五月13日 02:27 UTC](https://meta.discourse.org/t/should-discourse-make-an-effort-to-become-a-viable-comment-platform/274455/45 "2024-05-13T02:27:22Z")

</div>

我喜欢这个平台就是因为这一点：它为实现这些（或两者兼有！）目标奠定了所有基础。

---

<div class="post-metadata">

**Author:** ![simon](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/simon/32/339122_2.png) [@simon](https://meta.discourse.org/u/simon)\
**Post date:** [2025年一月18日 07:17 UTC](https://meta.discourse.org/t/should-discourse-make-an-effort-to-become-a-viable-comment-platform/274455/48 "2025-01-18T07:17:23Z")

</div>

鉴于此主题今天已被[链接](https://meta.discourse.org/t/current-projects-january-2025/347311/10?u=simon)，我想我应该根据我研究这个想法后得出的结论来更新它。

我仍然认为 Discourse 是一个很好的评论平台，原因在我最初的帖子中已经阐述。

关于如何实现这一点，我认为工作应该在 Discourse 端完成——最好是通过改进 Discourse 的评论嵌入脚本。这可以逐步完成。

通过在 Discourse 客户端（例如 [WP Discourse](https://github.com/discourse/wp-discourse) 插件）上完成所有工作，技术上可以实现将 Discourse 用作评论平台的服务器，但由于需要在客户端和 Discourse 之间管理状态以及绕过速率限制问题，这变成了一个复杂的问题。这肯定比我愿意负责维护的任何事情都复杂。

此主题中的一些帖子表明，人们有兴趣仅仅允许用户在博客网站上\_创建\_ Discourse 评论。从我的角度来看，这不是一个很好的解决方案，但现在可以通过 Discourse API 实现。复杂之处在于尝试创建一个完整的评论系统，让用户能够以类似于他们在典型主流新闻网站上与评论互动的方式，在网站上与 Discourse 评论进行互动。

---

<div class="post-metadata">

**Author:** ![volanar](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/volanar/32/318163_2.png) [@volanar](https://meta.discourse.org/u/volanar)\
**Post date:** [2025年二月4日 16:43 UTC](https://meta.discourse.org/t/should-discourse-make-an-effort-to-become-a-viable-comment-platform/274455/49 "2025-02-04T16:43:05Z")

</div>

这里正在开发一个 Drupal 集成模块，您可以通过 API 在 Drupal 端撰写 Discourse 评论。  
[https://www.drupal.org/project/discourse\_comments\_plus](https://www.drupal.org/project/discourse_comments_plus)

 ![图片是关于在 Drupal 中集成 Discourse 评论的功能和说明的文本文件的屏幕截图，重点是关于访问者使用 SSO 登录以直接从 Drupal 添加评论的关键部分。（AI 图像说明）](https://global.discourse-cdn.com/meta/original/4X/c/f/8/cf87b79a4c43381e9cd92158db7a43f583507eb6.jpeg)

---

<div class="post-metadata">

**Author:** ![angus](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/angus/32/341715_2.png) [@angus](https://meta.discourse.org/u/angus)\
**Post date:** [2025年二月4日 17:45 UTC](https://meta.discourse.org/t/should-discourse-make-an-effort-to-become-a-viable-comment-platform/274455/50 "2025-02-04T17:45:13Z")

</div>

鉴于我在 ActivityPub 和 [WP Discourse](https://github.com/discourse/wp-discourse) 方面的经验，我认为通过嵌入式 JavaScript 实现双向评论是可行的。嵌入脚本将包含以下内容：

1. 未经身份验证的“读取”功能，其工作方式类似于当前的 JS 嵌入（并进行了一些优化）。
2. 远程客户端（即用户的浏览器）[注册用户 API 密钥客户端](https://meta.discourse.org/t/feasibility-of-allowing-a-user-api-key-client-to-register-a-valid-auth-redirect/312901)，该客户端特定于用户的会话，并将相关详细信息存储在浏览器的本地存储中。
3. 用户将看到“登录以发表评论”。
4. 用户进行身份验证（使用 Discourse）以检索会话用户 API 密钥，该密钥存储在浏览器的本地存储中。
5. 每项活动（评论、点赞等）都将直接发布到一个专用端点，并附带适当的安全措施、处理和任务管理。

> [@sam](#):
>
> 我认为唯一可行的前进道路是让第三方原型化/构建解决方案。如果范围正确且有合适的团队负责，我将考虑赞助至少一部分。

如果有足够的预算，我认为我可以在 6-8 个月内完成 v1 的生产准备并与 `discourse/discourse` 集成。在初始发布之后，我可以做以下事情：

1. 为 WordPress、Ghost 和其他选定平台添加明确的支持。
2. 编写文档。
3. 提供支持。

抄送 @pmusaraj @mcwumbly

---

<div class="post-metadata">

**Author:** ![simon](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/simon/32/339122_2.png) [@simon](https://meta.discourse.org/u/simon)\
**Post date:** [2025年二月4日 21:14 UTC](https://meta.discourse.org/t/should-discourse-make-an-effort-to-become-a-viable-comment-platform/274455/51 "2025-02-04T21:14:38Z")

</div>

尝试以一种对非技术用户有意义的方式来实现它。现有的平台，如 Disqus 和 Facebook 评论，可能提供了很好的例子。

更多身份验证选项：

- 客户端站点成为 [DiscourseConnect](https://meta.discourse.org/t/13045?silent=true) 客户端。这很容易实现，但需要为客户端站点添加服务器端代码。
- 用户在客户端进行身份验证，并通过 postMessage API 将其身份验证状态传递到 iframe：[Window: postMessage() method - Web APIs | MDN](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage)
- 用户直接通过 iframe 登录 Discourse

我不愿纯粹在客户端开发，是因为考虑到了系统在任何规模下运行的问题。本质上，我不得不排队处理 API 请求并处理来自排队请求的响应。我认为它不够健壮，无法处理例如 1000 个并发用户。通过 JavaScript 嵌入方法，我会有类似的担忧，但原因不同。我怀疑这比尝试在客户端同步所有内容要容易得多。

---

<div class="post-metadata">

**Author:** ![angus](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/angus/32/341715_2.png) [@angus](https://meta.discourse.org/u/angus)\
**Post date:** [2025年二月5日 13:01 UTC](https://meta.discourse.org/t/should-discourse-make-an-effort-to-become-a-viable-comment-platform/274455/52 "2025-02-05T13:01:10Z")

</div>

感谢您的反馈 🙂

昨天我对此进行了更深入的思考，因为该主题被顶上来了（这就是我最终在这里发帖的原因）。我认为仅客户端的解决方案（即 JavaScript 嵌入）是唯一真正合理的解决方案。否则，我们实际上是在讨论许多特定于平台的实现，每个实现都有自己的一系列问题。

您说得对，并发和负载是问题。ActivityPub 在并发和负载方面存在严重问题，因为单个 ActivityPub 帖子可能会为您带来来自 Fediverse 的大量传入和传出请求。在这种情况下，这实际上可能稍微容易一些，因为远程客户端是受控的。此外，在这种情况下，并发和负载实际上只在服务器端（即 Discourse 端）存在问题，尽管它们确实是问题，但我认为可以通过后台作业、缓存和互斥锁来解决。但是的，这些是需要考虑的重要问题。

---

<div class="post-metadata">

**Author:** ![sam](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/sam/32/102149_2.png) [@sam](https://meta.discourse.org/u/sam)\
**Post date:** [2025年二月6日 04:01 UTC](https://meta.discourse.org/t/should-discourse-make-an-effort-to-become-a-viable-comment-platform/274455/55 "2025-02-06T04:01:30Z")

</div>

坦白说，我最大的担忧是时机。

Composer v2 即将推出，在这个时候开始这项冒险却不利用我们新的 composer 将是疯狂的，但我们需要大量前期工作才能在轻量级应用程序中使用它。

我认为在这里应该做的就是关注新的 composer 大约 2-3 个月，然后重新讨论这个问题。

---

<div class="post-metadata">

**Author:** ![volanar](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/volanar/32/318163_2.png) [@volanar](https://meta.discourse.org/u/volanar)\
**Post date:** [2025年二月6日 11:21 UTC](https://meta.discourse.org/t/should-discourse-make-an-effort-to-become-a-viable-comment-platform/274455/56 "2025-02-06T11:21:57Z")

</div>

我认为可以并行处理。您需要对讨论进行 2 处更改。  
“回复”按钮应向未注册用户显示。  
 ![reply](https://global.discourse-cdn.com/meta/original/4X/f/2/3/f23987e396a8ba6747166443ef9cc60032be2f1a.png)

当未注册用户单击此按钮时，应显示此内容：  
 ![login](https://global.discourse-cdn.com/meta/original/4X/f/8/0/f806b86ffb943a7f64eac585a8ed57f7a6606c59.png)  
接下来，您需要弄清楚如何使用评论插入。这些很可能是小的代码更改，而不是大量工作。

---

<div class="post-metadata">

**Author:** ![madrush](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/madrush/32/119502_2.png) [@madrush](https://meta.discourse.org/u/madrush)\
**Post date:** [2025年七月25日 04:49 UTC](https://meta.discourse.org/t/should-discourse-make-an-effort-to-become-a-viable-comment-platform/274455/61 "2025-07-25T04:49:14Z")

</div>

我想知道在 Composer v2 发布后，是否还有兴趣开发此功能。我仍然希望看到并使用它。

---

<div class="post-metadata">

**Author:** ![Falco](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/falco/32/179432_2.png) [@Falco](https://meta.discourse.org/u/Falco)\
**Post date:** [2025年十二月11日 20:07 UTC](https://meta.discourse.org/t/should-discourse-make-an-effort-to-become-a-viable-comment-platform/274455/62 "2025-12-11T20:07:27Z")

</div>

我在 [Discourse Full App Embed Test](https://discourse-full-embed.pages.dev/embed-test) 搭建了一个概念验证。

---

<div class="post-metadata">

**Author:** ![Thiago\_Mobilon](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/thiago_mobilon/32/177756_2.png) [@Thiago\_Mobilon](https://meta.discourse.org/u/Thiago_Mobilon)\
**Post date:** [2025年十二月11日 21:32 UTC](https://meta.discourse.org/t/should-discourse-make-an-effort-to-become-a-viable-comment-platform/274455/63 "2025-12-11T21:32:33Z")

</div>

![Screenshot 2025-12-11 at 18.30.02](https://global.discourse-cdn.com/meta/original/4X/8/d/a/8daf65f428b604e55229a2d677002908477c1cf4.png)

当我点击“回复”或“点赞”按钮时，我遇到了（看起来是）一个 CSP 错误。

![Screenshot 2025-12-11 at 18.26.11](https://global.discourse-cdn.com/meta/original/4X/3/a/f/3afd132e24459cd4a54af2f2d92cfdeebbba8a59.png)

---

<div class="post-metadata">

**Author:** ![Falco](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/falco/32/179432_2.png) [@Falco](https://meta.discourse.org/u/Falco)\
**Post date:** [2025年十二月11日 22:00 UTC](https://meta.discourse.org/t/should-discourse-make-an-effort-to-become-a-viable-comment-platform/274455/64 "2025-12-11T22:00:38Z")

</div>

要进行概念验证，您想访问 [https://discourse-on-a-pi5.falco.dev](https://discourse-on-a-pi5.falco.dev) 并在加载演示之前登录。

---

<div class="post-metadata">

**Author:** ![Thiago\_Mobilon](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/thiago_mobilon/32/177756_2.png) [@Thiago\_Mobilon](https://meta.discourse.org/u/Thiago_Mobilon)\
**Post date:** [2026年一月8日 21:45 UTC](https://meta.discourse.org/t/should-discourse-make-an-effort-to-become-a-viable-comment-platform/274455/65 "2026-01-08T21:45:50Z")

</div>

是否可以隐藏第一篇帖子，使其看起来像这样？

 ![Screenshot 2026-01-08 at 18.42.13](https://global.discourse-cdn.com/meta/original/4X/7/6/3/763177effa5c9773620940caba279a73dc7dc669.jpeg)

另外，iframe需要固定高度吗，还是可以像当前的嵌入那样根据评论数量自适应？

还有一个问题：GTM/Analytics 代码会在此嵌入中加载还是被阻止？理想情况下是不加载它，否则统计数据将会重复（博客 + Discourse 同时触发两次页面浏览）。

---

<div class="post-metadata">

**Author:** ![Falco](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/falco/32/179432_2.png) [@Falco](https://meta.discourse.org/u/Falco)\
**Post date:** [2026年一月9日 02:17 UTC](https://meta.discourse.org/t/should-discourse-make-an-effort-to-become-a-viable-comment-platform/274455/66 "2026-01-09T02:17:35Z")

</div>

> [@Thiago\_Mobilon](#):
>
> 是否可以隐藏第一篇帖子，使其看起来像这样？

我很乐意这么做。

我的最终目标是隐藏标题和 OP（原始发帖人），以便第二篇帖子首先显示。

> [@Thiago\_Mobilon](#):
>
> 另外，iframe 需要固定高度，还是可以使其适应评论数量，就像当前的嵌入一样？

创建消息传递到父级并非不可能，但我还没有探索过。

> [@Thiago\_Mobilon](#):
>
> 还有一个问题：GTM/Analytics 代码是否会在此嵌入中加载或被阻止？理想情况下是不加载它，否则统计数据将被复制（博客 + discourse 同时触发两次页面浏览）。

这也是一个应该很容易添加的功能。

---

<div class="post-metadata">

**Author:** ![Falco](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/falco/32/179432_2.png) [@Falco](https://meta.discourse.org/u/Falco)\
**Post date:** [2026年二月19日 17:39 UTC](https://meta.discourse.org/t/should-discourse-make-an-effort-to-become-a-viable-comment-platform/274455/67 "2026-02-19T17:39:32Z")

</div>

我合并了我的[实验性工作](https://github.com/discourse/discourse/pull/36613)以实现全页面嵌入，所以现在可以进行测试了，如果您想试用的话。

您需要：

1. 更新到最新版本
2. 切换隐藏设置 `embed_full_app`
3. 在配置页面上嵌入的 JS 代码片段中添加 `fullApp: true`

对于尚未登录的用户来说，登录流程仍然很粗糙，但在您社区中用户已经拥有有效 cookie 的情况下，它可能非常合适。

请告诉我进展如何，这将有助于指导我们接下来的方向。

---

<div class="post-metadata">

**Author:** ![Slaune](https://avatars.discourse-cdn.com/v4/letter/s/aca169/32.png) [@Slaune](https://meta.discourse.org/u/Slaune)\
**Post date:** [2026年三月7日 11:38 UTC](https://meta.discourse.org/t/should-discourse-make-an-effort-to-become-a-viable-comment-platform/274455/68 "2026-03-07T11:38:40Z")

</div>

您好 @Falco！

感谢您所做的一切努力 🙂

我正尝试在我的托管 Discourse 实例（通过 Communiteq/discoursehosting.net）上使用 `fullApp` 嵌入，但遇到了问题。

我做了以下操作：

- 让 Communiteq 启用了隐藏设置 `embed_full_app`
- 在 JS 代码片段中添加了 `fullApp: true`
- 我的嵌入主机在允许的主机列表中

以下是发生的情况：

**没有 `discourseEmbedUrl` 时：**

```plaintext
DiscourseEmbed = {
  discourseUrl: 'https://my-forum-url/',
  fullApp: true
};

```

→ 我收到“嵌入错误”

**有 `discourseEmbedUrl` 时：**

```plaintext
DiscourseEmbed = {
  discourseUrl: 'https://my-forum-url/',
  discourseEmbedUrl: 'https://my-platform-url/page-where-I-want-discourse-embedded',
  fullApp: true
};

```

→ 它没有加载完整的论坛，而是抓取了 embedUrl，被重定向（我的平台需要登录），并以重定向 URL 作为标题创建了一个垃圾主题。

它的行为就像一个常规的评论嵌入，完全忽略了 `fullApp: true`。

即使在 `fullApp` 模式下，是否也需要 `discourseEmbedUrl`？

如果是这样，是否有办法阻止它创建主题，而是只渲染完整的论坛？

非常感谢您的指导。

乐意提供更多详细信息或测试任何内容。

谢谢！

[上一頁](https://meta.discourse.org/t/should-discourse-make-an-effort-to-become-a-viable-comment-platform/274455.md?page=2)

[下一頁](https://meta.discourse.org/t/should-discourse-make-an-effort-to-become-a-viable-comment-platform/274455.md?page=4)