我建议为内置的 [details] 功能添加一个最大嵌套深度限制，或者引入一个站点设置，允许管理员配置此限制。
问题描述
最近，我论坛上的一个用户创建了一篇包含 24 层嵌套 [details] 部分 的帖子。
这导致了几个问题：
- 浏览器性能： 用户报告说，展开多个层级会导致 Firefox 变得极其缓慢或无响应。
- Markdown 端点超时： 访问该主题的
.md端点变得极其缓慢。我们观察到请求耗时分别为 19.8 秒和 31.1 秒。 - 服务器错误： Markdown 端点有时返回“Oops”错误页面。Discourse 日志在 Markdown 转换期间也显示了 Pitchfork 工作进程超时警告。
- 潜在的资源耗尽： 由于搜索引擎和 AI 爬虫频繁请求
.md端点，深度嵌套的帖子可能会反复触发昂贵的处理过程并消耗服务器资源。
在删除问题帖子后，Markdown 端点返回 HTTP 200，响应时间约为 1.7 秒。
受影响的主题为：
https://meta.appinn.net/t/topic/87672
（问题回复已被移除。）
建议的改进
我认为以下任一措施都会很有用：
- 将
[details]的嵌套限制在合理的深度，例如 2 或 3 层。 - 添加一个站点设置，例如
details_max_nesting_depth，允许管理员配置最大嵌套深度。
为了向后兼容，该设置的默认值可以设为无限制，同时允许管理员在需要时强制实施限制。
如果用户超过配置的限制，Discourse 可以拒绝该帖子并显示清晰的验证消息。
临时解决方案：一个插件
我创建了一个小插件，将 [details] 的嵌套限制为最多 2 层：
GitHub - scavin/discourse-details-depth-limit · GitHub
该插件在服务器端验证帖子，并拒绝包含超过两层嵌套可折叠部分的帖子。
我已在本地 Discourse 开发环境中成功测试了该插件。
对于遇到类似问题的管理员，在官方解决方案可用之前，此插件可作为一个临时解决方案。
我认为，在内置的 Details 插件中提供可配置的限制，将是防止意外或过度嵌套的有用保障措施。