与之前的一些错误类似，如果您查看帖子链接框中显示的帖子数量，它会显示帖子编号。然而，这与右侧导航栏中显示的数字不匹配。
我认为以下主题可以说明这个问题：Migrate a phpBB3 forum to Discourse - #580 by gerhard
因此，该主题的最后一篇帖子（在撰写本文时）被称为“第 580 号帖子”，但滚动条显示为 256 / 257。查看该主题中的第二篇帖子，其编号为 #303，因此我猜测在此之前有一些私密消息（whispers）。
此外，在此帖子之后，数字也存在间隔：Migrate a phpBB3 forum to Discourse - #307 by Canapin
也许那里也有一条私密消息？
不，那只是一堆被删除的帖子，不是 bug。
好的，如果该话题确实存在这种情况，请检查一个包含“悄悄话”的话题（或者在此处发送悄悄话然后发布一条测试回复？），因为你会遇到同样的效果。
不幸的是，我的论坛中一些敏感或多疑的成员已经注意到了这个漏洞，他们凭空想象出了一些可怕的事情：
你设想这如何运作？
如果问题在于不信任员工，也许你的社区需要将所有的 Moderation 等操作完全公开透明地进行？
帖子编号 # 应与滚动条中计算的帖子编号相匹配，从而“跳过”非管理员的私信。链接到私信帖子仍可提供支持，但或许可以使用略有不同的 URL 格式，例如 /topicid/w-postid，其中前缀 ‘w’ 表示该帖子 ID 为私信。
我们非常开放，但这仍无法阻止一些人指出他们觉得某个话题中有多少条私信，并试图煽风点火。
听起来工作量巨大，却没有任何切实的好处。
如果你的社区不喜欢可以使用私信这一功能，可以通过设置“启用私信”将其关闭，这可能会有所帮助。
但这仍然无法改变一个事实：如果主题中有已删除的帖子，计数就会不准确。用户们仍会对这种差异感到担忧或多疑……而且你会不必要地失去悄悄话功能。
只需向用户简单解释一下为什么数字存在差异（原因是已删除的帖子）就足够了。除此之外，用户们需要克服他们毫无根据的恐惧（或阴谋论）。
经典的豪言壮语 
如果我们忽略帖子永久链接中的密语，那么管理员该如何链接到密语呢？那样的话，我们就需要为密语添加一种新的 URL 格式，就像你提议的那样。
对此我之前的回复是：
所以我们这是在原地打转。
我上一篇文章只是请求对帖子编号与计数不匹配的问题进行“外观”上的修正，如截图所示——您曾表示其他内容工作量太大而收益甚微，因此我便放弃了。
这是一个多年来一直存在的问题，我们曾尝试改进，最终形成了现在的局面。
我认为这是必要的透明度与不易被察觉性之间的一种结合。（是的，这存在某种程度的矛盾。）
我们不愿在按顺序显示帖子的立场上做出妥协（例如大型平台如 Twitter 处理已删除帖子问题的方式）。这些编号上的差异似乎是为此必须付出的代价。
你愿意详细说明或提供相关链接，说明 Twitter 具体在做什么吗？我不是 Twitter 用户，所以没有参考依据来比较或对比 Discourse 在此处的做法。
这是精简版：
请核对日期
通过不断打乱回复的显示顺序，被删除或不需要的回复可以被轻易地掩盖，而您很难证明这种情况正在发生。
此外，煽动性的回复可能被算法推至顶部，从而火上浇油，加剧争吵而非平息事态。
啊……关于精选排序的问题。我没想到这会对已删除帖子的记录等产生影响。
没错——我完全同意这一点。
正因如此，我认为如果同一屏幕上显示的两个“帖子编号”能够一致会更好（截图在我上面的帖子中），即使 URL 中的帖子编号（通常需要滚动才能看到）仍然会暴露实际的帖子顺序号。
既然页面滚动器知道每篇帖子的“可见”编号，我不明白为什么不能将其复用于帖子对话框，不过我也没有查看过相关代码！
我也不清楚代码是如何处理的，但我猜测，统计总数可以通过聚合数据库查询快速完成，利用 PostgreSQL 索引来统计未被删除且非“密语”的帖子。
另一方面，显示每篇帖子的实际编号（忽略密语和已删除的帖子）可能会导致巨大的性能损耗，而带来的收益却微乎其微。当然，也可以通过后台进程来实现：每当有新帖子创建或删除时，就更新帖子的编号（但这期间编号可能会出现错误）。
这两种方案在我看来都不理想，尽管我大概猜到了总数是如何计算的（如果先获取帖子 ID，再计算总数，那么实现你提出的需求可能带来的性能损耗会更小）。
（这里我仅考虑更改显示编号，而不涉及 URL 的更改，因为更改 URL 会更糟糕，随着时间推移，链接可能会指向错误的帖子）
我认为关于编号的这个问题本质上是一个权衡：虽然这不是最理想的场景，但在其他可能性中，我认为当前的实现方式是最佳选择。此外，究竟什么样的实际场景才算最理想呢？（这也是为什么我说这是一种权衡）
另一项需要在后台完成的工作是更新其他主题中引用链接的 URL。
这里也可能出现问题：分享到其他网站的链接。
如果为了匹配时间轴而更改了 URL，它们将与之前分享的 URL 不匹配。
我无法用这个话题进行测试，因为数字是正确的。但如果时间线上的当前数字是正确的，并且可以与帖子关联，那么这只需要在前端做一点小改动。所以，是的，这可以在没有负面影响的情况下实现（只要更改的是帖子编号，而不是 URL）。
没错——正是如此。时间线已经正确实现了该功能，因此只需复用其数据或逻辑来处理帖子编号（但不包含在 URL 中）即可。
