我意识到，对于大多数使用场景来说，这并不实用，但我想知道：
我正在运行两个 Discourse 实例，一个是私有 Wiki，另一个是公共论坛。在这两个实例中，用户都遇到了这个限制。
虽然可以将主题帖子拆分为单独的回复，但这并不理想；而且关键在于，对于 Wiki 来说，这会使得 DiscoTOC（自动目录插件）无法使用（而这正是我们在长 Wiki 中所需要的）。
最后，如果无法通过 Discourse 代码提高该限制，是否有办法让我深入 Docker 镜像并覆盖此设置？
将此项设置得过高带来的最大后果是，处理超大文档时，Markdown 渲染的成本会变得相当高。
这个限制在一定程度上是任意的。我认为，在一个非常受控的环境中，将其提高到 20 万或 30 万也不会引发任何严重问题。
覆盖这一行设置的唯一规范方式是通过自定义插件：discourse/config/site_settings.yml at 3610709b6cf859f674a02394f1430bb51f68d117 · discourse/discourse · GitHub
我曾一两次收到提高我们“最大”限制的申请，但这显然并不是一个常见的需求。
不幸的是，我一生中从未写过一行 Ruby 代码，所以我完全不知道该如何操作。系统管理的工作对我来说轻而易举，但编程却让我感到不适。
我想有人能在大约 1 小时内为你开发这个插件，所以在 Marketplace 上预算 50-200 美元就能轻松实现这个改动。
我强烈不建议在这里进行分叉（fork）来实现此改动，因为这会让你的论坛面临巨大的长期风险；容器层面的修改将导致网页更新失效。