# 引入嵌套回复功能
**URL:** https://meta.discourse.org/t/introducing-nested-replies/402812
**Category:** Announcements
**Tags:** nested-replies
**Created:** [2026年五月12日 23:21 UTC](https://meta.discourse.org/t/introducing-nested-replies/402812 "2026-05-12T23:21:22Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@markvanlan](https://meta.discourse.org/u/markvanlan)
#### Post date: [2026年五月12日 23:21 UTC](https://meta.discourse.org/t/introducing-nested-replies/402812/1 "2026-05-12T23:21:22Z")
有意义的对话发生在房间里每个人都听到彼此想法的时候，而在 Discourse 上，扁平、线性的时间线一直是实现这一点的最佳方式。但扁平结构并不适合所有社区。在规模更大、节奏更快的论坛中，单个时间线上成千上万条回复会让任何人难以跟上。因此，我们今年一直在谨慎地试验完全嵌套的回复视图，并认为它非常适合那些已经超出扁平格式承载能力的社区。
这一功能最初作为一个实验性插件启动，现已转变为直接集成在 Discourse 中的项目。以下是目前嵌套主题的样子：
当某个特定帖子被链接（来自分享链接或通知）时，我们会显示单线程视图：
## 在您的站点上启用该功能
启用此功能的站点设置可在管理界面中找到。导航至“嵌套回复”部分，以控制该功能、默认排序模式、最大嵌套深度等选项。
## 路线图
截至撰写本文时，嵌套回复仍处于早期阶段，路线图尚未完全明确。我们已知将推进以下几项工作：
- 改善移动端体验
- 重新思考嵌套视图下的主题时间线。目前，在嵌套回复模式下，主题没有时间线显示
- 至少新增一种帖子排序模式，支持按时间衰减排序，类似于主题列表中的“热门”排序
## 限制
- 当为某个分类启用嵌套功能时，已存在的主题仍保持扁平模式。每个主题均可通过管理员扳手单独切换，但目前尚无方法将整个现有分类转换为嵌套模式。
## 我们期待您的反馈
我们需要您的反馈以及使用该功能的实际体验，以帮助指导其开发。如果这看起来适合您的社区，不妨尝试一下，并告诉我们您和您的用户有何看法！
---
### Author:  [@Lilly](https://meta.discourse.org/u/Lilly)
#### Post date: [2026年五月12日 23:56 UTC](https://meta.discourse.org/t/introducing-nested-replies/402812/2 "2026-05-12T23:56:27Z")
OMG 太棒了！时机也刚刚好。今晚我要把论坛迁移到带有两个容器的新服务器上，几周后常规赛和我们的体育竞猜池就要开始了，我迫不及待想把这个切换到新版本。这也将是一个很好的测试用例。
拥有平铺式和嵌入式讨论的选项真是太酷了——感谢 @markvanlan 和团队。
看看会出什么乱子也会很有趣：laughing
---
### Author:  [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [2026年五月13日 05:43 UTC](https://meta.discourse.org/t/introducing-nested-replies/402812/3 "2026-05-13T05:43:12Z")
需要说明的是：当树的多个分支中出现新回复时，单线程视图似乎一次只显示一条。我不得不多次返回查看，未读数量每次减少一个。
---
### Author:  [@gilles](https://meta.discourse.org/u/gilles)
#### Post date: [2026年五月13日 06:15 UTC](https://meta.discourse.org/t/introducing-nested-replies/402812/4 "2026-05-13T06:15:54Z")
尽管 Discourse 已更新，我仍然找不到启用此功能的选项！
我是自行托管的，也许这就是原因：😅
---
### Author:  [@Lilly](https://meta.discourse.org/u/Lilly)
#### Post date: [2026年五月13日 07:03 UTC](https://meta.discourse.org/t/introducing-nested-replies/402812/5 "2026-05-13T07:03:23Z")
> [@gilles](#):
>
> 我是自托管的，所以这可能是原因：😅
请更新您的 Discourse 实例，然后进入所有站点设置并搜索“嵌套”。
您可以在创建新主题时通过主题管理扳手来切换该选项。
如果您希望其在某个分类中默认为启用状态，可以在分类设置标签页中进行启用。
我自托管并且它完全正常运行。
---
### Author:  [@gilles](https://meta.discourse.org/u/gilles)
#### Post date: [2026年五月13日 07:05 UTC](https://meta.discourse.org/t/introducing-nested-replies/402812/6 "2026-05-13T07:05:14Z")
感谢你的高效：+1:
---
### Author:  [@Richie](https://meta.discourse.org/u/Richie)
#### Post date: [2026年五月13日 14:15 UTC](https://meta.discourse.org/t/introducing-nested-replies/402812/7 "2026-05-13T14:15:29Z")
> [@markvanlan](#):
>
> 当为某个分类启用嵌套模式时，已存在的主题仍保持扁平模式。每个主题都可以单独通过管理员扳手图标进行切换，但目前没有方法将现有分类批量转换为嵌套模式。
能否通过“选择帖子 \> 批量操作”选项对现有主题进行批量更改或更新？
或者是否有通过 Rails 控制台批量更新所有现有主题的选项？
---
### Author:  [@markvanlan](https://meta.discourse.org/u/markvanlan)
#### Post date: [2026年五月13日 14:20 UTC](https://meta.discourse.org/t/introducing-nested-replies/402812/8 "2026-05-13T14:20:57Z")
> [@Richie](#):
>
> 是否可以通过“选择帖子 \> 批量操作”选项批量更改/更新现有主题？
是的，切换是批量操作的一个选项 🙂
---
### Author:  [@Richie](https://meta.discourse.org/u/Richie)
#### Post date: [2026年五月13日 14:37 UTC](https://meta.discourse.org/t/introducing-nested-replies/402812/9 "2026-05-13T14:37:39Z")
好的，不确定批量切换功能对于拥有数万条主题的分类是否可行。是否可以考虑使用 Rails 的批量/批处理转换任务？🤔
另外，这个操作可逆吗？能否将线程化主题重新转换为扁平主题？
---
### Author:  [@markvanlan](https://meta.discourse.org/u/markvanlan)
#### Post date: [2026年五月13日 14:59 UTC](https://meta.discourse.org/t/introducing-nested-replies/402812/11 "2026-05-13T14:59:44Z")
是的，我同意你的看法。这目前是一个 **限制** ，我们一定会继续思考这个问题。
我之所以选择在启用该功能时不转换类别中的历史主题，主要原因是用户的交互方式可能会有所不同。在扁平模式下，各种 `回复` 按钮的重要性降低了。帖子会出现在主题底部。我不确定用户是否总是有意点击“正确的那个”，以便在嵌套视图中正确显示。
基本上，我担心管理员会为历史主题启用该功能，随后导致对话变得难以阅读。我们会继续思考这个问题。我能想到的最简单的改进是：当切换类别设置时，弹出一个模态对话框，询问“是否将此设置应用到现有主题？”
---
### Author:  [@asc](https://meta.discourse.org/u/asc)
#### Post date: [2026年五月13日 18:34 UTC](https://meta.discourse.org/t/introducing-nested-replies/402812/12 "2026-05-13T18:34:24Z")
太棒了！很高兴看到这个！👏
---
### Author:  [@ToddZ](https://meta.discourse.org/u/ToddZ)
#### Post date: [2026年五月13日 19:19 UTC](https://meta.discourse.org/t/introducing-nested-replies/402812/13 "2026-05-13T19:19:48Z")
> [@markvanlan](#):
>
> 在扁平模式下，各个回复按钮的重要性降低了。帖子会出现在主题底部。我不确定用户是否总是有意点击那个在嵌套视图中对应正确的按钮。
我一直觉得“回复”标签可以更加具体——所以 [不久前](https://meta.discourse.org/t/is-there-a-way-to-link-replies-after-they-are-posted/320175/16) 我使用了一些自定义 CSS 来添加上下文：
> **截图**
>
> 
> **CSS**
>
> ```css
> /* 为主题原始帖子（即主题本身）的回复按钮添加文本 */
> #post_1 nav.post-controls {
> .actions {
> button.reply {
> span.d-button-label:after {
> // 在“回复”后添加此内容
> content: " 回复此主题";
> }
> }
> }
> }
>
> /* 为所有后续帖子（我称之为评论）的回复按钮添加文本 */
> nav.post-controls {
> .actions {
> button.reply {
> span.d-button-label:after {
> // 在“回复”后添加此内容
> content: " 回复此评论";
> }
> }
> }
> }
>
> /* 为页面底部出现的蓝色“回复（主题）”按钮添加文本 */
> #topic-footer-buttons {
> .topic-footer-main-buttons {
> button.btn-primary.create {
> span.d-button-label:after {
> // 在“回复”后添加此内容
> content: " 回复主主题";
> }
> }
> }
> }
>
> ```
---
### Author:  [@Lilly](https://meta.discourse.org/u/Lilly)
#### Post date: [2026年五月13日 19:25 UTC](https://meta.discourse.org/t/introducing-nested-replies/402812/14 "2026-05-13T19:25:28Z")
此方案的问题在于，对于偏好设置中语言为非英语的成员，其用户界面将不会进行翻译。
---
### Author:  [@Richie](https://meta.discourse.org/u/Richie)
#### Post date: [2026年五月13日 19:37 UTC](https://meta.discourse.org/t/introducing-nested-replies/402812/15 "2026-05-13T19:37:07Z")
> [@markvanlan](#):
>
> 我选择不在启用该功能时转换某个分类中的历史主题，因为用户可能会以不同的方式进行互动。
> [@markvanlan](#):
>
> 我担心管理员会为历史主题启用该功能，然后突然之间的对话变得无法阅读。
有意思……
这是否意味着我们应该先在社区中进行隔离测试，然后再决定对所有现有主题进行转换？🤔
> [@markvanlan](#):
>
> 我能想到的最简单的改动是：当切换分类设置时，弹出一个模态窗口，询问“是否将此设置应用于现有主题？”
这确实可行，前提是该功能能够支持数万个主题。
但必须非常明确地告知用户，此操作不可逆转 😅
* * *
该功能会先在 meta 上实施，还是在 [https://try.discourse.org](https://try.discourse.org) 上实施，以便我们在非生产环境中进行测试？
---
### Author:  [@markvanlan](https://meta.discourse.org/u/markvanlan)
#### Post date: [2026年五月13日 19:47 UTC](https://meta.discourse.org/t/introducing-nested-replies/402812/16 "2026-05-13T19:47:16Z")
> [@Richie](#):
>
> 这是否意味着我们应该先在我们的社区中进行隔离测试，然后再由大家一致决定转换所有现有主题？🤔
如果是我自己的社区，我会先进行隔离测试。另一方面，如果您为整个社区启用该功能，我们也能更快地获得更有价值的反馈 😉 。玩笑归玩笑，我认为隔离测试可能是明智之举，但这里并没有破坏性的数据迁移。该功能可以安全地启用和禁用。您在此做出的任何决定都不会将您锁定在任一方向上。
> [@Richie](#):
>
> 但必须非常明确地说明，一旦启用就无法回退 😅
我想我有点无意中回答了这部分！启用嵌套功能只是为数据库中的每个主题创建一个 `nested_topic` 记录，并启动一个任务来计算祖先树中的回复数量。禁用嵌套则会移除该 `nested_topic` 记录，您会回到扁平结构，没有任何问题。
> [@Richie](#):
>
> 此功能会先在 meta 上实施，还是在 [https://try.discourse.org](https://try.discourse.org) 上实施，以便我们可以在生产环境之外进行测试？
欢迎在此类别中随意尝试：
> **[Nested Replies Testing](https://meta.discourse.org/c/nested-replies-testing/213)**
>
> Category used to test the very experimental plugin https://github.com/discourse/discourse-nested-replies/
---
### Author:  [@darkpixlz](https://meta.discourse.org/u/darkpixlz)
#### Post date: [2026年五月13日 20:15 UTC](https://meta.discourse.org/t/introducing-nested-replies/402812/18 "2026-05-13T20:15:53Z")
为什么这个功能只能由工作人员切换，而不能由普通用户切换？当我看到它即将在 Meta 上线时，我本以为它会被添加到帖子类型菜单中，但这个切换选项却被隐藏在工作人员扳手图标后面。
我不确定我是否有具体的使用场景，我只是以为它会像 [帖子投票功能](https://meta.discourse.org/t/discourse-post-voting/227808) 一样实现。
---
### Author:  [@markvanlan](https://meta.discourse.org/u/markvanlan)
#### Post date: [2026年五月13日 20:18 UTC](https://meta.discourse.org/t/introducing-nested-replies/402812/19 "2026-05-13T20:18:05Z")
我们不希望这是用户自行决定或偏好的事项。这应由管理员来决定其网站应如何运作。这两种范式截然不同，用户不应在同一内容上表现出如此不同的交互方式。至少这是我们目前的想法。
---
### Author:  [@eisammy](https://meta.discourse.org/u/eisammy)
#### Post date: [2026年五月13日 20:39 UTC](https://meta.discourse.org/t/introducing-nested-replies/402812/20 "2026-05-13T20:39:16Z")
广告区块在这种布局下运行不佳，且主题转换通常会引发一个 Bug，导致屏幕上的项目消失，仅能编辑标题。
---
### Author:  [@nicolsdennis](https://meta.discourse.org/u/nicolsdennis)
#### Post date: [2026年五月14日 03:55 UTC](https://meta.discourse.org/t/introducing-nested-replies/402812/22 "2026-05-14T03:55:24Z")
这个功能很棒！不过🤔，我其实更关心“热门/最新/旧”排序，而不是嵌套布局本身。我在自己的移动应用（一个 Discourse 客户端）中已经实现了类似的排序控制，非常希望能原生支持这一功能，而不是像现在这样变通实现（尽管目前的方法也能用，如下所示）。
查看源码后我发现，`GET /n/{slug}/{topic_id}.json?sort={top|new|old}&page={n}` 接口可以按指定模式对嵌套视图中的主题进行排序。我的问题是：是否有意在现有的 `/t/{slug}/{topic_id}.json` 端点中仅暴露 **排序功能** （例如 `?sort=top`），以便平铺视图的客户端也能受益？
如果平铺视图也能支持排序，第三方客户端就可以在不采用嵌套视图渲染模型的情况下选择启用该功能。
我理解嵌套视图的数据结构（根帖子 + 懒加载子帖子）使得服务器端排序更易实现，而平铺视图的分页方式不同。如果出于性能考虑实现完整的平铺排序不太现实，那么即使提供一个可选的 `?sort=top&limit=N` 参数，也足以支持“精选”视图的实现。
---
### Author:  [@Kevin7](https://meta.discourse.org/u/Kevin7)
#### Post date: [2026年五月14日 21:05 UTC](https://meta.discourse.org/t/introducing-nested-replies/402812/25 "2026-05-14T21:05:44Z")
[下一頁](https://meta.discourse.org/t/introducing-nested-replies/402812.md?page=2)