diff --git a/changelogs-v2/2026-06/56_房务抢单后定制师预留言未刷进消息列表_前端收CHAT-SSE要刷列表_前端处理-管理后台.md b/changelogs-v2/2026-06/56_房务抢单后定制师预留言未刷进消息列表_前端收CHAT-SSE要刷列表_前端处理-管理后台.md
new file mode 100644
index 0000000..d368c0d
--- /dev/null
+++ b/changelogs-v2/2026-06/56_房务抢单后定制师预留言未刷进消息列表_前端收CHAT-SSE要刷列表_前端处理-管理后台.md
@@ -0,0 +1,26 @@
+# 房务抢单后，定制师「抢单前发的联系房务消息」红点有、消息列表看不到（前端收 CHAT SSE 要刷列表）
+
+> 模块：管理后台 · 站内信/我的消息 + 房务抢单
+> 类型：**前端处理**（后端已正确，无需改后端）
+> 日期：2026-06-30
+> 反馈来源：wx 手动测试
+
+## 现象
+定制师在**房务还没抢单时**发「联系房务」消息；房务抢单后，**顶部铃铛红点 +1（有未读）**，但「我的消息」列表里**看不到那条新消息**（列表停在抢单前的旧数据），需手动刷新才出现。
+
+## 后端现状（已正确，勿改后端）
+1. 抢单/转单后，order-v3 经 Feign 调 user-service `bindHouseClaimer`，把抢单前的 pending（receiver=0）消息**归属迁移给真实抢单房务**（admin_message.admin_id 改判为 claimer）。实测：该消息已正确落到房务名下（kind=CHAT / messageType=ORDER）。
+2. 迁移「真有新消息送达」时，后端发 **SSE 信令**（Redis 频道 `admin-notify`），payload 字段齐全：
+   ```json
+   { "type": "CHAT", "adminId": <抢单房务id>, "unreadCount": <合并未读数>,
+     "conversationKey": "HOUSE:<orderId>", "senderName": "<定制师名>", "preview": "<消息预览>", "priority": "..." }
+   ```
+3. 列表接口 `GET /admin/message/list`（含 `messageType=ORDER` 订单消息 tab）**已正确返回该消息**（实测置顶），未读数接口 `GET /admin/message/unread-count` 也正确 +1。**后端数据一致**。
+
+## 根因（前端）
+前端收到 `type=CHAT` 的 SSE 信令后，**只用 `unreadCount` 刷新了顶部红点角标，没有刷新/更新「我的消息」列表**（把 CHAT 信令仅当聊天面板信令处理，没联动站内信「订单消息」列表）。→ 红点更新了、列表没更新，造成「有红点、列表看不到」。
+
+## 【前端处理】
+收到 `type=CHAT` 的 SSE 信令时，除刷新顶部红点角标（`unreadCount`）外，**同时刷新/重拉「我的消息」列表**（尤其「订单消息」tab）——或按 payload 的 `conversationKey`/`senderName`/`preview` 在列表插入/置顶该会话最新消息。否则房务抢单后新到的订单消息在列表里看不到（红点有、列表无），用户需手动刷新。
+
+> 补充：定制师抢单前发的消息属「订单消息」（kind=CHAT / messageType=ORDER），抢单后归属迁移给抢单房务即应出现在其「我的消息 → 订单消息」中——这是后端既有行为，前端只需在 CHAT 信令到达时刷新列表即可。