# 站内信「全部 / 订单消息 / 普通消息」三 tab 统一用 `/admin/message/list` 一个接口 + `messageType` 参数区分

> 模块：管理后台 · 站内信/我的消息（顶部三 tab）
> 类型：**前端处理**（统一接口后端早已存在，无需改后端）
> 日期：2026-06-30
> 反馈来源：前端反馈「2 个接口、没有"全部"的接口，想融合成一个接口用参数区分订单和普通消息」
> 关联：56_（房务抢单后订单消息在「全部」tab 看不到——同一根因：前端用错了数据源）

## 结论（先看这条）
**前端要的「一个接口 + 参数区分订单/普通」后端早就有了**，就是 **`GET /admin/message/list`**，用 **`messageType`** 参数三态切换。**三个 tab 全部走这一个接口**，传不同 `messageType` 即可，**不需要新增/合并任何后端接口，也不要再用 `conversations`（会话列表）去拼「订单消息」tab**。

## 统一契约：`GET /admin/message/list`
| tab | 请求 | 返回 |
|-----|------|------|
| **全部** | `GET /admin/message/list?pageNo=1&pageSize=20`（**不传 messageType**） | 系统通知 + 聊天消息**混排**，按时间倒序 |
| **订单消息** | `GET /admin/message/list?pageNo=1&pageSize=20&messageType=ORDER` | 仅订单消息（实时聊天 kind=CHAT） |
| **普通消息** | `GET /admin/message/list?pageNo=1&pageSize=20&messageType=NORMAL` | 仅普通消息（系统通知 kind=NOTIFY） |

- `messageType` 取值：**留空=全部 / `ORDER`=订单消息 / `NORMAL`=普通消息**（仅这两个值，大写）。
- 三个 tab 同接口、同分页（`pageNo`/`pageSize`），`total` 都准确（后端把 `messageType` 转成等价 `kind` 等值条件下推 SQL，不是查全部再内存过滤，所以翻页和「共 N 条」都对）。
- 返回每条 `records[]` 自带 `messageType`（ORDER/NORMAL）+ `messageTypeLabel`（订单消息/普通消息），前端可直接按它渲染「类型」列，无需自己判断。

### 返回字段（已有，无变化）
```json
{
  "messageId": "雪花ID(String)",
  "title": "标题(订单消息=团号·联系人, 普通消息=通知标题)",
  "content": "正文",
  "messageType": "ORDER | NORMAL",
  "messageTypeLabel": "订单消息 | 普通消息",
  "kind": "CHAT | NOTIFY",
  "isRead": 0,
  "createTime": 1782788699000,
  "bizId": "订单id(订单消息有)",
  "bizType": "HOUSE...",
  "senderName": "发件人(订单消息有)",
  "conversationKey": "HOUSE:订单id(订单消息有, 点开聊天用)",
  "categoryCode": null,
  "link": "跳转链接(普通消息可能有)"
}
```

## 【前端处理】
1. **三个 tab 都改用 `GET /admin/message/list`**，仅靠 `messageType` 区分（空/ORDER/NORMAL）。**「全部」tab 不要在前端把"订单消息"和"普通消息"两次结果合并**——直接调不传 `messageType` 的 `list` 即可拿到混排全量。
2. **「订单消息」tab 不要再接 `conversations`（会话列表）接口**。`conversations` 是**聊天面板的会话列表**（一会话一行、点开进会话线程），不是收件箱「订单消息」消息流；用它当 tab 数据源会导致 56_ 那个 bug（房务抢单后新到的订单消息在「全部」里看不到）。收件箱三个 tab 统一走 `list`。
   - 若需要「点订单消息 → 打开聊天会话」，用该条的 `conversationKey` 调聊天线程接口即可，不影响收件箱列表本身的数据源。
3. 改完自检：房务抢单后，定制师抢单前发的消息应同时出现在「全部」和「订单消息」两个 tab（后端已确认该消息在 `list` 响应中，见 56_）。

## 备注（无后端改动）
本说明仅澄清既有接口契约，后端无任何代码改动。`unread-count`（顶部红点合并未读）、`{id}/read`（单条已读）、`read-all`（全部已读）等接口维持不变。
