# 同一帖子超过 1 条回复时，通知将合并显示

**URL:** <https://meta.discourse.org/t/notification-are-grouped-for-the-more-than-1-reply-on-the-same-post/403440>\
**Category:** Development\
**Created:** [2026年五月20日 15:00 UTC](https://meta.discourse.org/t/notification-are-grouped-for-the-more-than-1-reply-on-the-same-post/403440 "2026-05-20T15:00:39Z")\
**Posts on this page:** 1\
**Showing post:** 1

<div class="post-metadata">

**Author:** ![nitinkg](https://avatars.discourse-cdn.com/v4/letter/n/eb8c5e/32.png) [@nitinkg](https://meta.discourse.org/u/nitinkg)\
**Post date:** [2026年五月20日 15:00 UTC](https://meta.discourse.org/t/notification-are-grouped-for-the-more-than-1-reply-on-the-same-post/403440/1 "2026-05-20T15:00:39Z")

</div>

我们在使用 Discourse 通知 API 和数据探索器查询时，观察到以下通知合并/分组行为：

- 回复/评论通知（`notification_type = 2`）
- 表情反应通知（`notification_type = 25`）

观察到的现象：

- 即使在短时间内同一主题/帖子下仅有 2 条回复或评论，通知也会被合并或分组。
- 第二个操作并不总是创建独立的通知行。
- 现有的通知行似乎被更新或替换，而不是插入新行。
- 较旧的通知行有时会从 `notifications` 表中消失。
- 表情反应通知也表现出类似的合并现象。
- 用户界面可能显示如“2 条回复”这样的分组计数，而数据库或 API 中仅反映单条通知行。

我们发现了以下相关设置：

- `linked notifications consolidation window mins`
- `likes notification consolidation window mins`
- `notification_consolidation_threshold`

问题：

1. 这些设置是否仅与用户界面分组相关，还是也控制数据库或 API 级别的通知合并？
2. 由于即使只有 2 次操作也会触发通知合并，Discourse 是否在达到合并阈值之前就在内部重用或更新现有的通知行？
3. 是否有受支持的方法可以完全禁用通知合并，以确保每条回复或反应都生成独立的通知记录？
4. `notifications` 表是否被有意设计为对关联通知和反应通知非仅追加（non-append-only）？
5. 对于表情反应通知（`notification_type = 25`），是否有可靠且受支持的方法从通知负载或 API 中识别执行反应的用户？

我们主要希望了解通知系统的预期行为，以及是否支持完全独立的每操作通知。

---

_[View the full topic](https://meta.discourse.org/t/notification-are-grouped-for-the-more-than-1-reply-on-the-same-post/403440)._