# 未读计数显示“未读 (14)”，但 /unread 为空 **URL:** \ **Category:** Bug\ **Created:** [2026年五月28日 10:00 UTC](https://meta.discourse.org/t/unread-count-shows-unread-14-but-unread-is-empty/403986 "2026-05-28T10:00:42Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![Orioni](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/orioni/32/542679_2.png) [@Orioni](https://meta.discourse.org/u/Orioni)\ **Post date:** [2026年五月28日 10:00 UTC](https://meta.discourse.org/t/unread-count-shows-unread-14-but-unread-is-empty/403986/1 "2026-05-28T10:00:42Z")
在这个美好的周四早晨，我向大家提出一个有趣的难题。我发现我的网站上似乎出现了一个误报的未读计数器。 ### 问题现象 顶部导航栏显示“未读 (14)”。但当我点击它并进入 `/unread` 页面时， **没有任何未读主题** 列出。页面提示“没有未读内容”。 其他非管理员用户也遇到了同样的问题，只是未读数量各不相同。 在 iOS 上的 Discourse 应用中，我也看到了未读计数，即使实际上并没有未读主题，而且有时这个数字也不一致。 - **平台** ：桌面网页版和 iOS 上的 Discourse 应用 - **影响范围** ：多名用户 - **站点** ：`eurth.org` ### 我已进行的测试 我在安全模式下进行了测试： - `https://eurth.org/?safe_mode=no_themes,no_plugins` - `https://eurth.org/unread?safe_mode=no_themes,no_plugins` 问题依然存在，因此似乎并非由主题或客户端插件自定义引起。任何主题中都没有“耳语”（whispers），所以也不太可能是这个原因。 我也无法使用 **忽略** 功能，因为当未读列表为空时，`/unread` 页面上根本没有 **忽略** 按钮。 ### 预期行为 如果导航栏显示“未读 (14)”，我应该在 `/unread` 页面上看到 14 个未读主题，或者至少看到一些可见的未读主题。 ### 实际行为 - 导航栏显示“未读 (14)” - `/unread` 页面为空 - 没有可用的 **忽略** 按钮 - 问题在安全模式下依然存在 ### 问题 - 是否有已知的方法可以重建或重置某个用户的未读状态？ - 是否存在服务器端的不一致，导致即使 `/unread` 页面为空，未读计数仍然显示？ * * * 此前，我曾在 [ask.discourse.org](http://ask.discourse.org) 上向 AI 咨询过该问题，最终它建议我在这里发布一个错误报告。 ---
**Author:** ![Lilly](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/lilly/32/575047_2.png) [@Lilly](https://meta.discourse.org/u/Lilly)\ **Post date:** [2026年五月28日 10:15 UTC](https://meta.discourse.org/t/unread-count-shows-unread-14-but-unread-is-empty/403986/2 "2026-05-28T10:15:34Z")
啊，幽灵未读消息问题又困扰你的网站了！ 你最近是否更改过任何分类权限，或将某些话题移动到了安全分类？有某些操作改变了追踪状态。 > [@Orioni](#): > > 其他非管理员用户也遇到了同样的问题，只是未读数量不同。 > [@Orioni](#): > > 有没有已知的方法可以重建或重置单个用户的未读状态？ 既然其他用户也遇到同样的问题，难道不应该为所有用户重置吗？ 我认为可以通过 Rails 控制台为所有用户修复此问题，但操作有点复杂，我需要先研究并测试一下。我现在正在用手机，但如果没人先提出解决方案，我稍后会尝试发布一个解决方法。 ---
**Author:** ![chapoi](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/chapoi/32/537252_2.png) [@chapoi](https://meta.discourse.org/u/chapoi)\ **Post date:** [2026年五月28日 10:40 UTC](https://meta.discourse.org/t/unread-count-shows-unread-14-but-unread-is-empty/403986/3 "2026-05-28T10:40:00Z")
您好， 我们已知晓此漏洞并正致力于解决。对此我们也深感困扰 😉 ---
**Author:** ![Orioni](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/orioni/32/542679_2.png) [@Orioni](https://meta.discourse.org/u/Orioni)\ **Post date:** [2026年五月28日 11:35 UTC](https://meta.discourse.org/t/unread-count-shows-unread-14-but-unread-is-empty/403986/4 "2026-05-28T11:35:18Z")
> [@Lilly](#): > > 你最近是否更改过任何分类权限，或将某些话题移动到了安全分类？似乎有什么东西改变了追踪状态。 是的。我们的工作人员私下里一直在开发一个类似于 #Documentation 的分类，该分类在完成后最近已公开。 > [@Lilly](#): > > 如果其他人也遇到同样的问题，难道你不应该为所有用户重置它吗？ 是的，确实如此。我原本的想法是先在自己身上测试，然后再为所有人修复。由于这是一个非常复杂的 bug（至少对我来说），在找到可行的解决方案之前，我不想让大家抱有不切实际的期望。 > [@chapoi](#): > > 我们已知晓此 bug 并正在尝试解决。 感谢您的信心。今天早上我注意到了 [2026 年 5 月月度发布](https://meta.discourse.org/t/may-2026-monthly-release/403981) `v2026.05`，原以为它可能会修复这个问题，但问题仍然存在。我相信团队正在处理。Discourse 非常棒。 > [@Lilly](#): > > 啊，幽灵未读消息又困扰你的站点了！ 哦，天哪。😳 老实说，我已经查阅了所有相关的 #Contribute > Bug 报告。有一会儿，我甚至考虑直接从导航栏隐藏“未读”标签，干脆忽略它。但这并不能解决任何问题，对吧？看起来它甚至在这里的 Meta 上也如影随形。 ---
**Author:** ![Lilly](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/lilly/32/575047_2.png) [@Lilly](https://meta.discourse.org/u/Lilly)\ **Post date:** [2026年五月28日 13:41 UTC](https://meta.discourse.org/t/unread-count-shows-unread-14-but-unread-is-empty/403986/5 "2026-05-28T13:41:44Z")
好的，这个 Rails 脚本将作为全局“全部标记为已读”功能，强制将所有用户的 `unread`（未读）计数重置为 `0`。因此，很遗憾，它不仅会清除那些虚假的未读标记，也会清除任何真实的未读计数。我们可以在 Rails 中通过 SQL 命令实现这一点。但请注意，这并不能修复根本的 bug。另外，如果你手边有最近的备份，这是个很好的主意；不过我已经在我的开发论坛测试过，它运行正常。 `cd /var/discourse` `./launcher enter app` `rails c` 粘贴以下整个代码块并按回车键执行 ```rb sql = <<~SQL UPDATE topic_users SET last_read_post_number = topics.highest_post_number FROM topics WHERE topics.id = topic_users.topic_id AND COALESCE(topic_users.last_read_post_number, 0) < topics.highest_post_number AND topic_users.notification_level IN (2, 3, 4) -- 跟踪、关注、关注首帖 SQL # 执行更新 result = ActiveRecord::Base.connection.execute(sql) puts "已成功全站清除 #{result.cmd_tuples} 个未读主题。" # 强制客户端浏览器清除缓存状态并与数据库同步 MessageBus.publish("/topic-tracking-state", { clear: true }) ``` 用户可能需要强制刷新页面才能看到已清除的 `unread`（未读）状态。 ---
**Author:** ![Orioni](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/orioni/32/542679_2.png) [@Orioni](https://meta.discourse.org/u/Orioni)\ **Post date:** [2026年五月28日 16:32 UTC](https://meta.discourse.org/t/unread-count-shows-unread-14-but-unread-is-empty/403986/6 "2026-05-28T16:32:00Z")
运行备份。下载备份。SSH 登录服务器。运行脚本。 ![South Park: And It's Gone Meme](https://global.discourse-cdn.com/meta/original/4X/6/6/5/665c4027abdd4ad254c8ced7c08bce220789e360.webp) ✅ 问题已解决。 非常感谢 @Lilly。如果选项可用，我会将其标记为解决方案。不过，一个点赞也能表达心意。🚀 祝您有美好的一天！ ---
**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:** [2026年五月29日 04:53 UTC](https://meta.discourse.org/t/unread-count-shows-unread-14-but-unread-is-empty/403986/7 "2026-05-29T04:53:30Z")
请注意，一旦我们完成部署，虚假未读标记将会消失： > [@Small post actions no longer tracked or watched](https://meta.discourse.org/t/small-post-actions-no-longer-tracked-or-watched/404058/1): > > Discourse has a special post type that denotes “small action”. It looks like this: This happens when you close or open topics; it can happen when you assign topics and in various other conditions. Over the years, we have heard many complaints from people who simply do not want to be notified about this administrivia. This is particularly noticeable when admins bulk close topics or can come as a surprise when topics are auto-closed due to timers. We are partway through rolling out a… 希望不会太久。 ---
**Author:** ![RalfJung](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ralfjung/32/51654_2.png) [@RalfJung](https://meta.discourse.org/u/RalfJung)\ **Post date:** [2026年六月1日 07:41 UTC](https://meta.discourse.org/t/unread-count-shows-unread-14-but-unread-is-empty/403986/9 "2026-06-01T07:41:38Z")
> [@Lilly](#): > > 啊，幽灵未读消息问题也困扰你的网站了！ 你说的“幽灵未读消息”是指实际上并没有未读内容，只是计数错误吗？ 我最近在多个 Discourse 实例中遇到过相反的情况：确实存在未读消息，计数也是正确的，但“未读”页面却没有显示它们。 这听起来和这里讨论的 Bug 不同，但我的 [Bug 报告](https://meta.discourse.org/t/unread-tab-is-not-listing-all-thread-with-unread-messages/404151) 却被标记为与本文重复而关闭了。 ---
**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:** [2026年六月1日 08:01 UTC](https://meta.discourse.org/t/unread-count-shows-unread-14-but-unread-is-empty/403986/10 "2026-06-01T08:01:20Z")
> [@RalfJung](#): > > 我最近在多个 Discourse 实例上看到了相反的情况：确实有未读消息，数量也正确，但「未读」页面却没有显示它们。 这是同一个问题…… 我们抑制了小型操作，但我们的实现只完成了一半。 > [@Small post actions no longer tracked or watched](https://meta.discourse.org/t/small-post-actions-no-longer-tracked-or-watched/404058/1): > > Discourse has a special post type that denotes “small action”. It looks like this: This happens when you close or open topics; it can happen when you assign topics and in various other conditions. Over the years, we have heard many complaints from people who simply do not want to be notified about this administrivia. This is particularly noticeable when admins bulk close topics or can come as a surprise when topics are auto-closed due to timers. We are partway through rolling out a… 因此，这些很可能是在主题末尾有小型操作的主题（例如关闭等……）。 ---
**Author:** ![RalfJung](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ralfjung/32/51654_2.png) [@RalfJung](https://meta.discourse.org/u/RalfJung)\ **Post date:** [2026年六月1日 08:13 UTC](https://meta.discourse.org/t/unread-count-shows-unread-14-but-unread-is-empty/403986/11 "2026-06-01T08:13:45Z")
> [@sam](#): > > 所以这些很可能是那些在主题末尾有小幅操作（例如关闭等）的主题。 不，我在 bug 报告中描述的那些缺失的主题确实有新帖子。正如我在 bug 报告中所说： > “未读”是我跟进对话的方式，因此这有很高的风险让我完全错过需要回复的内容。 我不太在意错过“主题已关闭”的通知，但这个 bug 可能会导致我错过实际的帖子。 ---
**Author:** ![LarisaHaster](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/larisahaster/32/577281_2.png) [@LarisaHaster](https://meta.discourse.org/u/LarisaHaster)\ **Post date:** [2026年六月1日 09:20 UTC](https://meta.discourse.org/t/unread-count-shows-unread-14-but-unread-is-empty/403986/12 "2026-06-01T09:20:17Z")
我想补充说明，自周三（5 月 27 日）起，作为 OpenAI 社区论坛的用户，我在 iOS 和桌面端也遇到了同样的问题。 ![GIF_2852759167](https://global.discourse-cdn.com/meta/original/4X/6/a/2/6a2129e03d3f141ac8b4f28c43bb5c4addc9d065.webp) 补充：这里的屏幕录制看起来非常缓慢，对此深感抱歉。 ---
**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:** [2026年六月2日 02:21 UTC](https://meta.discourse.org/t/unread-count-shows-unread-14-but-unread-is-empty/403986/13 "2026-06-02T02:21:14Z")
对此我们深表歉意，@zogstrip 正在修复中，应该很快就能解决。 @RalfJung 请先稍候，一旦我们完成修复，如果问题仍未解决，我们可以进一步调试。 ---
**Author:** ![LarisaHaster](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/larisahaster/32/577281_2.png) [@LarisaHaster](https://meta.discourse.org/u/LarisaHaster)\ **Post date:** [2026年六月2日 06:12 UTC](https://meta.discourse.org/t/unread-count-shows-unread-14-but-unread-is-empty/403986/14 "2026-06-02T06:12:30Z")
别担心！我只是想让大家注意到这个 bug，因为我在 OpenAI 社区也遇到了同样的问题。很高兴听到修复工作已经在进行中。 ---
**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:** [2026年六月3日 00:11 UTC](https://meta.discourse.org/t/unread-count-shows-unread-14-but-unread-is-empty/403986/15 "2026-06-03T00:11:03Z")
@zogstrip 在此处修复了导致此问题的回归问题： > > > The "Unread (N)" badge could count a topic that did not appear on the > /unread pa…ge (and, conversely, a genuinely unread topic could be hidden > from /unread). See https://meta.discourse.org/t/-/403986. > > Both the count and the list bound their results by the user's "old > unread" cutoff, \`user\_stats.first\_unread\_at\`, which is computed from > \`topics.updated\_at\`. The count (TopicTrackingState) filters on > \`topics.updated\_at \>= first\_unread\_at\`, but since 17555ae8798 (#40127) > the /unread list (TopicQuery#apply\_max\_age\_limit) filtered on > \`topics.bumped\_at\` instead. A small action at the tail of a topic > (close, auto-close, category change, ...) moves \`updated\_at\` but not > \`bumped\_at\`, so such a topic passed the count's filter yet failed the > list's filter: it was counted but never listed. > > \#40127 switched to \`bumped\_at\` for suggested topics, where bounding by > last visible activity is the desired behaviour, so reverting it is not > an option. Instead, \`apply\_max\_age\_limit\` now takes an explicit > \`age\_column\` that defaults to \`updated\_at\` (keeping the unread and new > lists consistent with the count), and the suggested-topics callers pass > \`age\_column: :bumped\_at\` to preserve their behaviour. OpenAI 刚刚部署完成（还剩 2 分钟）。 ---
**Author:** ![LarisaHaster](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/larisahaster/32/577281_2.png) [@LarisaHaster](https://meta.discourse.org/u/LarisaHaster)\ **Post date:** [2026年六月3日 06:31 UTC](https://meta.discourse.org/t/unread-count-shows-unread-14-but-unread-is-empty/403986/16 "2026-06-03T06:31:07Z")
从今天上午起，我的未读列表显示有 21 个由 OpenAI 员工关闭的话题，而这些话题我之前已经看过或阅读过了。 ![IMG_3670](https://global.discourse-cdn.com/meta/original/4X/3/f/c/3fc117cf691c37e2a13d514f3327d000a3cb1597.jpeg) ---
**Author:** ![zogstrip](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/zogstrip/32/512781_2.png) [@zogstrip](https://meta.discourse.org/u/zogstrip)\ **Post date:** [2026年六月24日 16:31 UTC](https://meta.discourse.org/t/unread-count-shows-unread-14-but-unread-is-empty/403986/19 "2026-06-24T16:31:40Z")