diff --git a/changelogs-v2/2026-07/17_4739_房务待处理未读消息标签缺失-前端待处理-管理后台.md b/changelogs-v2/2026-07/17_4739_房务待处理未读消息标签缺失-前端待处理-管理后台.md
index 9f2445b..c425354 100644
--- a/changelogs-v2/2026-07/17_4739_房务待处理未读消息标签缺失-前端待处理-管理后台.md
+++ b/changelogs-v2/2026-07/17_4739_房务待处理未读消息标签缺失-前端待处理-管理后台.md
@@ -57,7 +57,28 @@ const showUnreadMessageTag = Number(row.unreadMessageCount || 0) > 0
 - `unreadMessageCount > 0`：展示标签“有未读消息”，并保留未读数字气泡。
 - `unreadMessageCount === 0`：不展示该标签。
 
-### 2. 标签用于解释已完成订单仍在待处理中的原因
+### 2. 待处理原因标签是多标签并列，不是互斥状态
+
+待处理列表行的原因标签应支持多个独立标签同时展示。
+
+示例：
+
+| 场景 | 期望展示 |
+|------|----------|
+| 只有未读消息 | `有未读消息` |
+| 只有改需求 | `改需求` |
+| 只有酒店超时 | `酒店超时` 或现有超时文案 |
+| 同时有未读消息 + 改需求 + 酒店超时 | 同一行展示 3 个独立标签：`有未读消息`、`改需求`、`酒店超时` |
+
+前端不要把“有未读消息”做成覆盖其他原因的单一状态，也不要因为订单已有“已完成 / 配房中”等状态标签就隐藏原因标签。
+
+建议实现口径：
+
+- 订单状态标签：表达当前房务状态，例如 `已完成`、`配房中`。
+- 待处理原因标签：表达为什么出现在待处理列表，例如 `有未读消息`、`改需求`、`酒店超时`。
+- 多个待处理原因同时存在时，按独立标签数组渲染，互不覆盖。
+
+### 3. 标签用于解释已完成订单仍在待处理中的原因
 
 已完成订单进入待处理列表时，列表行必须让用户看到触发原因。
 
@@ -66,12 +87,13 @@ const showUnreadMessageTag = Number(row.unreadMessageCount || 0) > 0
 - 与订单状态标签“已完成”同一组标签区域；或
 - 与未读数字气泡相邻，保证一眼能识别原因。
 
-### 3. 读完消息后的刷新
+### 4. 读完消息后的刷新
 
 用户点击处理/联系定制师并读完消息后，前端需要刷新列表数据：
 
 - 未读数字消失。
 - “有未读消息”标签消失。
+- 如果该订单仍有其他待处理原因，例如改需求或酒店超时，应保留对应原因标签。
 - 如果该订单没有其他待处理原因，应从待处理列表移除。
 
 ## 验收标准
@@ -80,8 +102,9 @@ const showUnreadMessageTag = Number(row.unreadMessageCount || 0) > 0
 |------|------|
 | `HL20260702232101505` 未读数为 `2` | 列表行显示“有未读消息”标签，并显示未读数量 `2` |
 | `HL20260702232103376` 未读数为 `0` | 不显示“有未读消息”标签 |
+| 同一订单同时存在未读消息、改需求、酒店超时 | 同一行展示 3 个独立原因标签，不互相覆盖 |
 | 已完成订单因未读消息进入待处理 | 用户能通过标签理解进入待处理的原因 |
-| 读完消息并刷新 | 标签和数字同步消失；无其他待处理原因时订单退出待处理列表 |
+| 读完消息并刷新 | “有未读消息”标签和数字同步消失；其他原因标签保留；无其他待处理原因时订单退出待处理列表 |
 
 ## 影响范围