danyang-match/实时聊天、消息通知与反骚扰机制详细设计.md

# 丹阳公益婚恋服务平台
# V1.0 实时聊天、消息通知与反骚扰机制详细设计

版本：V1.0  
适用范围：微信小程序用户端、公益红娘工作台、运营管理后台  
核心目标：只在双方明确同意后建立沟通、保证消息稳定送达、降低骚扰与诈骗风险、保护聊天隐私、确保拉黑/封禁即时生效

---

# 第一章 设计目标

V1.0聊天模块不是社交娱乐平台。

它只服务于一个明确场景：

> 双方互相喜欢以后，提供安全、简单、可靠的进一步沟通渠道。

因此V1.0聊天设计必须坚持：

- 双向喜欢后才能聊天
- 不支持陌生人私信
- 不支持群聊
- 不支持红包
- 不支持转账
- 不支持直播
- 不支持语音房
- 不支持“超级消息”
- 不允许付费解锁聊天
- 拉黑后立即停止通信
- 风控状态变化立即影响聊天权限
- 工作人员默认无权查看私人聊天

---

# 第二章 V1聊天功能范围

支持：

```text
文字消息
图片消息
Emoji
系统消息
安全提醒
消息未读
已读同步
失败重试
历史记录分页
举报
拉黑
解除匹配
```

V1暂不支持：

```text
语音消息
实时语音通话
视频通话
位置共享
文件
名片
红包
转账
群聊
阅后即焚
朋友圈
```

---

# 第三章 聊天入口规则

用户A与用户B只有同时满足：

```text
存在有效Match
+
match.status = active / getting_to_know
+
双方账号可用
+
双方未拉黑
+
conversation.can_send = true
```

才允许聊天。

---

# 第四章 会话创建时机

推荐V1：

> 双向喜欢成功时立即创建Conversation。

流程：

```text
A喜欢B
↓
发现B已经喜欢A
↓
创建Match
↓
创建Conversation
↓
创建双方ConversationMember
↓
发送双向匹配通知
```

这样用户点击：

> 开始聊天

时不需要额外创建会话。

---

# 第五章 Conversation状态

V1只保留：

```text
active
closed
```

active：

> 可以聊天。

closed：

> 不能发送新消息。

---

# 第六章 Conversation关闭条件

以下任一情况发生：

```text
解除匹配
A拉黑B
B拉黑A
任一方账号封禁
任一方账号关闭
风控明确禁止聊天
```

Conversation立即：

```text
status = closed
```

双方成员：

```text
can_send = false
```

---

# 第七章 历史聊天是否删除

关闭Conversation以后：

> 不物理删除历史聊天。

原因：

- 用户自己仍可能需要查看历史
- 举报取证
- 风控调查
- 纠纷处理

但是否继续向用户展示历史，要根据场景决定。

---

# 第八章 解除匹配后的聊天

解除匹配后建议：

> 历史会话保留为只读。

页面顶部：

```text
你们已解除匹配，无法继续发送消息。
```

输入框：

> 禁用。

---

# 第九章 拉黑后的聊天

拉黑比解除匹配更强。

建议：

拉黑方：

> 不再看到对方正常会话入口，可在黑名单中管理。

被拉黑方：

> 不提示“你被谁拉黑了”。

只显示：

> 当前无法继续聊天。

防止引发冲突。

---

# 第十章 Conversation数据模型

建议：

```text
conversations
conversation_members
messages
```

核心字段沿用前面数据库设计。

---

# 第十一章 conversation_members

至少包含：

```text
conversation_id
user_id
last_read_message_id
unread_count
can_send
joined_at
```

未来即使一直是一对一聊天，也保留member结构。

---

# 第十二章 消息类型

V1：

```text
text
image
system
risk_notice
```

---

# 第十三章 Text消息结构

示例：

```json
{
  "id": "msg_xxx",
  "conversationId": "con_xxx",
  "senderId": "usr_xxx",
  "type": "text",
  "content": "你好，很高兴认识你",
  "createdAt": "2026-08-28T10:32:00+08:00",
  "status": "sent"
}
```

---

# 第十四章 Image消息结构

```json
{
  "id": "msg_xxx",
  "conversationId": "con_xxx",
  "senderId": "usr_xxx",
  "type": "image",
  "fileId": "file_xxx",
  "thumbnailUrl": "...",
  "imageUrl": "...",
  "createdAt": "..."
}
```

图片URL：

> 必须为临时签名URL。

---

# 第十五章 System消息

由系统生成。

例如：

```text
你们互相喜欢，可以开始聊天了。
```

```text
你们已解除匹配。
```

```text
当前会话已停止发送消息。
```

System消息：

> 用户不能伪造。

sender_id可以为空，由message_type区分。

---

# 第十六章 RiskNotice

用于安全提示。

例如：

```text
安全提醒：婚恋交友过程中请谨慎涉及转账、借款、投资等资金往来。
```

RiskNotice不作为普通聊天内容的一方发言。

---

# 第十七章 WebSocket总体架构

推荐：

```text
微信小程序
      │
      │ HTTPS
      ↓
REST API
      │
      │
      └────→ PostgreSQL
      │
      ↓
WebSocket Gateway
      │
      ↓
Redis
```

V1可以和主后端部署在同一个应用中。

不需要独立消息微服务。

---

# 第十八章 WebSocket连接地址

示例：

```text
wss://api.example.com/ws
```

必须：

> WSS。

生产不得使用：

```text
ws://
```

---

# 第十九章 WebSocket认证

建立连接时：

> 必须验证有效登录凭证。

禁止：

```text
userId=123
```

作为身份依据。

正确：

```text
Token
↓
服务端解析
↓
得到真正userId
↓
绑定connection
```

---

# 第二十章 Connection状态

前端统一：

```text
disconnected
connecting
connected
reconnecting
```

MessageStore统一管理。

---

# 第二十一章 WebSocket建立流程

```text
小程序进入前台
↓
检查Token
↓
建立WS
↓
Token认证
↓
Server绑定userId
↓
connected
↓
拉取遗漏消息
```

---

# 第二十二章 WebSocket断线重连

断线以后：

> 自动重连。

建议退避：

```text
1s
2s
5s
10s
20s
30s
```

最大：

> 30秒。

恢复后重置。

---

# 第二十三章 不要无限高频重连

如果：

- Token失效
- 账号封禁
- 网络完全离线

不能每秒持续重连。

对应：

```text
AUTH_EXPIRED
ACCOUNT_BANNED
OFFLINE
```

停止或降低重连。

---

# 第二十四章 微信小程序前后台切换

进入后台时：

WebSocket可能被系统暂停或断开。

重新回前台：

```text
检查连接
↓
必要时重连
↓
同步消息
↓
刷新未读数
```

---

# 第二十五章 心跳

WebSocket建议：

```text
客户端Ping
服务端Pong
```

间隔示例：

```text
30～60秒
```

具体根据实际微信小程序网络特性调整。

---

# 第二十六章 实时事件

建议：

```text
message.new
message.read
conversation.closed
match.created
notification.new
account.status_changed
```

---

# 第二十七章 message.new

示例：

```json
{
  "event": "message.new",
  "eventId": "evt_xxx",
  "data": {
    "conversationId": "con_xxx",
    "message": {}
  }
}
```

---

# 第二十八章 eventId

每个实时事件建议拥有：

```text
eventId
```

前端可用于：

> 去重。

避免断线恢复后重复消费。

---

# 第二十九章 消息发送方式

推荐V1：

> 消息发送走REST，实时接收走WebSocket。

即：

```text
POST /conversations/{id}/messages
```

成功后：

服务端推送WebSocket。

优点：

- 幂等更清晰
- API测试简单
- 弱网容易重试
- 权限处理统一

---

# 第三十章 为什么不建议V1全部走WebSocket发送

全WebSocket双向消息虽然可行，但会增加：

- ACK机制
- 重发协议
- 幂等实现
- 连接异常处理
- 测试复杂度

V1采用：

> REST发送 + WS接收

更简单可靠。

---

# 第三十一章 clientMessageId

每条客户端消息必须生成：

```text
clientMessageId
```

例如：

```text
cm_018...
```

服务端唯一：

```text
sender_id + client_message_id
```

---

# 第三十二章 消息发送流程

```text
用户输入
↓
本地生成clientMessageId
↓
UI显示sending
↓
POST消息
↓
服务端鉴权
↓
验证Conversation
↓
风险检测
↓
数据库保存
↓
返回正式messageId
↓
UI sent
↓
服务端WS推送给接收方
```

---

# 第三十三章 发送状态

前端：

```text
sending
sent
failed
```

---

# 第三十四章 Sending视觉

发送过程中：

> 不需要大Loading。

可使用：

> 小型旋转图标或灰色状态。

---

# 第三十五章 Failed视觉

失败：

```text
!
```

点击：

> 重新发送。

必须使用原：

```text
clientMessageId
```

保证不会重复。

---

# 第三十六章 服务端成功但客户端超时

典型弱网：

```text
Server保存成功
↓
Response在网络中丢失
↓
客户端显示failed
↓
用户重试
```

由于clientMessageId相同：

服务端返回：

> 原消息。

不会插入第二条。

---

# 第三十七章 消息排序

服务端以：

```text
created_at
+
message_id
```

稳定排序。

不要完全相信客户端时间。

---

# 第三十八章 客户端时间用途

客户端时间只用于：

> 本地临时展示。

最终：

> 服务端createdAt为准。

---

# 第三十九章 历史消息加载

进入聊天：

首先加载最近：

```text
20～30条
```

向上滚动：

> 加载更早。

Cursor分页。

---

# 第四十章 消息Cursor

推荐使用：

```text
createdAt + messageId
```

或数据库生成稳定cursor。

避免传统：

```text
page=100
```

在实时消息变化下错乱。

---

# 第四十一章 本地聊天缓存

可以缓存：

> 最近少量消息。

用于：

- 快速打开
- 弱网显示

但长期历史仍从服务端获取。

---

# 第四十二章 不在Storage长期保存全部聊天

原因：

- 用户隐私
- 设备共享风险
- 数据量大

建议只保存：

> 必要的近期缓存。

并设置清理策略。

---

# 第四十三章 聊天输入草稿

本地：

```text
chatDraft[conversationId]
```

用户退出聊天：

> 保留未发送文字。

---

# 第四十四章 草稿不得同步给对方

当然只存在本地。

服务端不需要保存“正在输入内容”。

---

# 第四十五章 V1不做正在输入

不需要：

```text
对方正在输入...
```

减少实时协议复杂度。

---

# 第四十六章 已读机制

用户真正打开Conversation并读取消息后：

```text
POST /conversations/{id}/read
```

发送：

```text
lastReadMessageId
```

---

# 第四十七章 已读位置只向前

若当前：

```text
lastRead = msg100
```

旧请求晚到：

```text
msg90
```

服务器必须忽略。

不能回退到msg90。

---

# 第四十八章 V1是否显示“已读”

建议：

> V1不向发送者显示精确“已读”。

原因：

- 降低社交压力
- 减少焦虑
- 简化产品

后台仍可维护阅读位置用于未读统计。

---

# 第四十九章 未读数计算

MessageStore：

```text
chatUnreadCount
systemUnreadCount
totalUnreadCount
```

统一来源。

---

# 第五十章 新消息未读

当B不在当前Conversation：

A发消息：

```text
B.unread_count + 1
```

如果B当前正在该Conversation并已加载：

可以实时标记阅读。

---

# 第五十一章 Tab Badge

消息Tab：

```text
totalUnreadCount
```

超过99：

```text
99+
```

---

# 第五十二章 消息列表排序

按：

```text
last_message_at DESC
```

最近聊天在最上。

---

# 第五十三章 消息列表项

展示：

- 头像
- 展示名
- 最近消息摘要
- 时间
- 未读数量

---

# 第五十四章 图片消息摘要

聊天列表：

```text
[图片]
```

不要尝试自动OCR图片内容作为摘要。

---

# 第五十五章 风险系统消息摘要

可显示：

```text
安全提醒
```

但不要让安全消息把真正用户消息列表全部顶掉。

---

# 第五十六章 System Notification与Chat分离

消息首页两个Tab：

```text
聊天
系统通知
```

业务通知不塞进普通聊天列表。

---

# 第五十七章 系统通知分类

```text
审核通知
匹配通知
红娘通知
活动通知
安全通知
账号通知
系统通知
```

---

# 第五十八章 系统通知数据结构

建议：

```json
{
  "id": "not_xxx",
  "type": "activity",
  "title": "活动报名已通过",
  "content": "你报名的丹阳青年公益相亲会已通过审核。",
  "businessType": "activity",
  "businessId": "act_xxx",
  "read": false,
  "createdAt": "..."
}
```

---

# 第五十九章 通知点击跳转

根据：

```text
businessType
businessId
```

跳：

```text
review → 审核页
match → 我的缘分/聊天
activity → 活动详情
matchmaker → 红娘服务
risk → 账号状态
```

---

# 第六十章 通知不能传完整路由URL

后端不应任意下发：

```text
https://...
```

由前端根据：

> businessType

映射内部页面。

避免开放重定向。

---

# 第六十一章 通知去重

例如双向匹配事务重试。

不能生成多个：

> 你们互相喜欢。

唯一键可以：

```text
user_id
+
notification_type
+
business_id
```

---

# 第六十二章 通知状态

```text
unread
read
```

V1足够。

不需要：

- archived
- starred
- deleted

---

# 第六十三章 全部已读

提供：

```text
POST /notifications/read-all
```

用户可以快速清除Badge。

---

# 第六十四章 微信订阅消息的定位

微信订阅消息只用于：

> 重要站外提醒。

例如：

- 审核结果
- 活动提醒
- 红娘服务重要更新

不能用于：

> 每来一条聊天都发微信订阅消息。

---

# 第六十五章 新聊天是否外部提醒

V1建议：

如果用户不在小程序：

> 不依赖每条聊天外部推送。

可以后续提供：

> 有新的婚恋消息

聚合提醒。

具体须遵循微信订阅消息实际规则。

---

# 第六十六章 反骚扰体系总体模型

反骚扰不是只靠“举报”。

体系包括：

```text
聊天准入限制
+
发送频率限制
+
内容风险提醒
+
拉黑
+
举报
+
风险评分
+
人工处置
```

---

# 第六十七章 第一层：陌生人不能直接发消息

这是最重要的反骚扰规则。

因为：

> 没有双向喜欢，就没有聊天。

直接消除大量陌生私信骚扰。

---

# 第六十八章 第二层：发送频率限制

需要防：

- 刷屏
- 机器人
- 骚扰

建议配置：

```text
单会话短时间消息上限
单用户总发送速率
连续相同消息限制
```

---

# 第六十九章 不建议把正常聊天限得过死

例如：

正常用户快速连续发5句：

> 不应该被处罚。

限频主要拦：

> 极端异常速率。

---

# 第七十章 高频行为分级

例如：

```text
Level 1：
稍微高频
→ 不处理

Level 2：
明显高频
→ 轻限速

Level 3：
机器式高频
→ 临时停止发送 + RiskEvent
```

阈值配置化。

---

# 第七十一章 重复文本检测

如果用户向多个对象发送：

> 完全相同的营销话术。

可以记录：

```text
DUPLICATE_MESSAGE_SPAM
```

风险事件。

---

# 第七十二章 跨会话群发

例如同一用户：

```text
1分钟内
向10个不同Match
发送完全相同内容
```

非常值得关注。

系统：

- 风险加分
- 限速
- 人工关注

---

# 第七十三章 联系方式识别

聊天中可以允许用户：

> 自主交换联系方式。

所以不能像Profile一样完全禁止手机号和微信号。

但大量、高频向不同用户发送联系方式：

> 可能是引流/营销。

需要结合频率判断。

---

# 第七十四章 Profile与Chat的区别

Profile：

> 不允许放联系方式。

Chat：

> 双向Match后允许用户自主交流。

这是重要规则差异。

---

# 第七十五章 资金风险词

重点词组：

```text
转账
借钱
投资
理财
虚拟币
博彩
贷款
刷单
银行卡
高收益
项目投资
资金周转
```

命中：

> 风险提醒。

---

# 第七十六章 普通关键词提示

第一次风险命中：

系统插入：

```text
安全提醒：
婚恋交友过程中请谨慎涉及资金往来，
不要轻信投资、借款或高收益项目。
```

---

# 第七十七章 同一会话不要反复提示

例如用户正常聊银行工作。

不能每次出现“投资”都插一条黄色提醒。

建议：

```text
同类风险提示
24小时/一段会话内
最多提示1次
```

具体可配置。

---

# 第七十八章 风险提示冷却

例如：

```text
money_warning cooldown = 24h
```

这样避免干扰。

---

# 第七十九章 严重风险组合

单关键词不处罚。

但是组合行为：

```text
多用户举报诈骗
+
高频发送投资话术
+
多人拉黑
```

风险显著提高。

---

# 第八十章 风险评分不在聊天UI显示

不能告诉用户：

```text
对方风险分82
```

除非账号已经进入明确处置状态。

---

# 第八十一章 被多人拉黑

被多人拉黑：

> 是风险信号。

但也可能是正常婚恋拒绝。

所以权重不能过高。

结合：

- 举报
- 高频消息
- 重复话术

综合判断。

---

# 第八十二章 单会话举报入口

聊天右上角：

```text
···
```

包含：

```text
查看资料
解除匹配
举报
拉黑
```

---

# 第八十三章 举报聊天时的证据方式

用户可以：

> 直接选择举报当前用户。

系统自动关联：

```text
conversationId
```

并允许用户选择：

> 相关聊天时间范围/截图。

---

# 第八十四章 不建议让用户手工截所有聊天

如果用户举报：

平台内部已有Conversation。

可以让系统后台在授权调查时：

> 查询相关上下文。

用户可额外上传截图作为补充。

---

# 第八十五章 举报关联信息

Report可以记录：

```text
conversation_id
related_message_ids
```

这样风控查看更准确。

---

# 第八十六章 风控人员聊天访问

默认：

> 无权限。

处理举报时：

只有拥有：

```text
message.content.review
```

才能访问。

同时写：

> Sensitive Access Log。

---

# 第八十七章 红娘不能查看用户聊天

即使红娘负责双方用户：

> 也不能查看两人的私人聊天。

红娘只能根据用户主动反馈：

> “不知道怎么聊”

给一般建议。

---

# 第八十八章 红娘聊天辅助

用户申请：

> 不知道怎么开始聊天。

红娘可以：

- 给聊天建议
- 给破冰话题
- 根据公开资料建议话题

不能：

> 登录用户账号替他聊天。

---

# 第八十九章 V1不做AI代聊

不提供：

> AI自动替用户回复。

避免：

- 身份真实性问题
- 情感欺骗
- 误发内容
- 责任不清

---

# 第九十章 可以后续提供的辅助

未来最多考虑：

> 用户主动点击“帮我润色一句”。

且必须：

- 用户确认
- AI不自动发送

V1不做。

---

# 第九十一章 图片消息安全

用户聊天图片上传：

必须：

- 图片格式校验
- 大小校验
- EXIF清理
- 风险扫描
- 私有存储

---

# 第九十二章 图片消息审核策略

V1可以：

> 机器基础安全检测 + 举报后人工处理。

是否每张聊天图片人工预审：

> 不建议。

会严重影响隐私与成本。

---

# 第九十三章 明显非法图片

如果自动内容安全服务识别到：

> 高置信度违法/色情内容。

可以：

- 阻止发送
- 记录风险事件
- 必要时人工复核

---

# 第九十四章 图片失败

图片上传成功但消息发送失败：

文件成为：

> 未绑定临时对象。

定时任务清理。

---

# 第九十五章 上传图片大小

建议：

```text
原图 ≤ 10MB
```

后端：

> 压缩。

聊天展示不需要保存巨大原图。

---

# 第九十六章 图片预览

点击图片：

> 全屏预览。

禁止自动保存到相册。

如用户主动保存：

> 使用系统正常授权流程。

---

# 第九十七章 消息撤回

V1建议：

> 暂不做消息撤回。

原因：

- 增加状态复杂度
- 举报取证更复杂
- 不是核心需求

---

# 第九十八章 删除聊天

V1可以不提供：

> 删除整个Conversation。

如果未来提供：

只做：

> 用户侧隐藏

而不是物理删除系统记录。

---

# 第九十九章 敏感词与内容过滤

区分：

```text
非法内容
风险内容
普通敏感场景
```

非法内容：

> 阻止。

风险内容：

> 提醒或进入风控。

普通敏感场景：

> 正常允许。

---

# 第一百章 不要建立超大关键词黑名单

维护成本高，误伤严重。

V1重点：

> 小而明确的反诈骗/违法规则集。

---

# 第一百零一章 安全规则配置

后台可维护：

```text
消息发送频率阈值
重复文本阈值
风险关键词
风险提示冷却
高风险分数阈值
```

但修改必须：

> Audit。

---

# 第一百零二章 规则配置不要让普通运营改

权限：

```text
risk.rule.manage
```

仅安全管理员。

---

# 第一百零三章 用户主动拉黑流程

```text
点击拉黑
↓
二次确认
↓
POST block
↓
建立blocked关系
↓
Match失效/聊天关闭
↓
更新缓存
↓
WS通知相关客户端状态变化
```

---

# 第一百零四章 拉黑确认文案

建议：

```text
拉黑后，对方将无法继续与你聊天，
你们也不会再互相出现在推荐中。

确认拉黑？
```

按钮：

```text
确认拉黑
取消
```

---

# 第一百零五章 被拉黑方通知

不要发送：

> “王女士拉黑了你。”

这样可能引发线下冲突。

只在其尝试访问Conversation时：

> 当前无法继续聊天。

---

# 第一百零六章 解除匹配流程

```text
用户选择解除匹配
↓
选择原因
↓
确认
↓
Match = unmatched
↓
Conversation关闭
↓
双方不再继续聊天
```

---

# 第一百零七章 解除匹配是否通知对方

建议：

> 系统通知对方“该匹配关系已结束”。

不要显示：

> 对方选择你的原因。

例如：

```text
当前匹配关系已结束，双方将无法继续发送消息。
```

---

# 第一百零八章 为什么不展示Unmatch原因

原因可能造成：

- 伤害
- 争执
- 报复

原因只用于：

> 内部产品分析。

---

# 第一百零九章 Match成功后的第一条系统消息

建议：

```text
你们互相喜欢，可以开始进一步了解了。
```

下面安全说明：

```text
请注意保护个人隐私，谨慎涉及转账、
借款、投资等资金往来。
```

---

# 第一百一十章 第一次聊天安全提醒

顶部NoticeBar显示一次。

用户关闭后：

> 当前Conversation不再重复顶部显示。

但风险命中仍可出现RiskNotice。

---

# 第一百一十一章 安全提醒本地状态

可存：

```text
conversationSafetyNoticeClosed[conversationId]
```

只是UI偏好。

不是安全业务真相。

---

# 第一百一十二章 账号封禁实时流程

后台封禁A：

```text
RiskService更新AccountStatus
↓
关闭A所有发送能力
↓
缓存失效
↓
WebSocket发送 account.status_changed
↓
客户端UserStore刷新
↓
聊天输入框全部禁用
```

---

# 第一百一十三章 封禁后已有消息

历史消息不删除。

对方看到：

> 当前用户暂时无法联系。

具体文案不要暴露内部风控细节。

---

# 第一百一十四章 临时限制与永久封禁区别

feature_limit：

> 可能只限制Like或消息。

temporary_suspend：

> 核心婚恋功能暂停。

ban：

> 严重限制账号。

MessageService每次发送都读取：

> 当前有效权限。

---

# 第一百一十五章 不只在登录时检查风控

用户登录后可能过几个小时才被限制。

因此：

> 每次发送消息必须重新检查账号聊天能力。

---

# 第一百一十六章 Redis可缓存聊天能力

可以缓存：

```text
chat_permission:{userId}
```

但User状态变化：

> 必须立即失效。

安全关键接口不能长期使用过期缓存。

---

# 第一百一十七章 消息接口限流

至少：

```text
按user
按conversation
按IP/Session
```

结合。

---

# 第一百一十八章 上传接口限流

防止：

> 用户疯狂上传图片占存储。

限制：

- 单用户单位时间上传数
- 单日总量
- 单文件大小

---

# 第一百一十九章 消息长度

文字建议：

```text
1～1000字符
```

具体可配置。

超过：

> 提示分段发送。

不需要支持一条几万字。

---

# 第一百二十章 空消息

纯空格：

> 拒绝。

Emoji：

> 正常允许。

---

# 第一百二十一章 URL链接

聊天中用户可能发送链接。

V1建议：

> 以纯文本展示。

不要自动：

> 生成富卡片预览。

原因：

- 安全
- 防钓鱼
- 开发简单

---

# 第一百二十二章 可疑链接提示

如果检测到：

> 外部网址

可以轻提示：

> 打开陌生链接请注意安全。

但不要每条网址都阻断。

---

# 第一百二十三章 V1不支持二维码扫描跳转

聊天图片里即使有二维码：

> 平台不主动识别并跳转。

减少诈骗跳转风险。

---

# 第一百二十四章 通知系统服务边界

所有业务模块：

不要自己写：

```text
INSERT notifications...
```

统一：

```text
NotificationService
```

---

# 第一百二十五章 Notification事件来源

例如：

```text
ProfileApproved
MutualMatchCreated
ActivityRegistrationApproved
MatchmakerRecommendationCreated
RiskActionCreated
```

由Notification模块消费。

---

# 第一百二十六章 通知失败补偿

建议建立：

```text
notification_delivery_tasks
```

或简单任务表/重试机制。

不强制MQ。

---

# 第一百二十七章 站内通知和微信通知分离

状态：

```text
in_app_created
wechat_pending
wechat_sent
wechat_failed
```

站内通知成功：

> 即认为核心通知存在。

微信订阅消息失败：

> 不影响业务。

---

# 第一百二十八章 通知发送优先级

高：

- 账号安全
- 活动取消
- 审核结果
- Match成功

中：

- 红娘推荐
- 活动报名结果

低：

- 普通运营提醒

---

# 第一百二十九章 不做营销推送

V1不推：

- “快来看看新用户”
- “今天桃花运爆棚”
- “已有3人偷偷喜欢你”

避免商业婚恋套路。

---

# 第一百三十章 喜欢我的通知

用户被Like：

V1可以：

> 系统通知有新的喜欢。

但不要过度刺激。

建议：

```text
有人表达了想进一步了解你的意愿。
```

也可以只在：

> 我的缘分 → 喜欢我的

展示。

具体通知频率可配置。

---

# 第一百三十一章 批量聚合通知

如果短时间收到多个Like：

不要发5条通知。

可以：

> 你收到了新的喜欢。

聚合处理。

---

# 第一百三十二章 聊天数据访问权限矩阵

| 角色 | 会话列表 | 聊天正文 |
|---|---:|---:|
| 用户本人 | 自己的 | 自己的 |
| 公益红娘 | 否 | 否 |
| 活动管理员 | 否 | 否 |
| 审核员 | 否 | 否 |
| 普通管理员 | 否 | 否 |
| 风控员 | 关联案件必要范围 | 特殊权限 |
| 超级管理员 | 默认否 | 特殊授权 |

---

# 第一百三十三章 聊天数据库查询接口

普通后台不要提供：

```text
GET /admin/users/{id}/messages
```

这种入口。

风控使用专门接口：

```text
GET /admin/risk/reports/{reportId}/conversation-context
```

只能围绕案件访问。

---

# 第一百三十四章 风控聊天查询范围

参数可以：

```text
beforeMessageId
afterMessageId
limit
```

限制上下文数量。

避免一次加载全部历史。

---

# 第一百三十五章 所有风控查询必须Audit

记录：

```text
operatorId
reportId
conversationId
range
reason
time
```

---

# 第一百三十六章 消息保留策略

V1不在本章拍死具体年限。

必须由：

> 数据生命周期政策 + 法律合规审查

确定。

系统需要支持：

- 按用户/时间删除或匿名化
- 注销处理
- 纠纷保留
- 安全调查保留

---

# 第一百三十七章 用户注销对聊天影响

注销后：

```text
can_send = false
```

历史Conversation中：

展示名可变为：

> 用户已注销

头像：

> 中性占位图。

---

# 第一百三十八章 注销用户消息内容

历史消息是否保留：

按平台数据保留政策处理。

不能简单因为注销：

> 让另一方历史聊天全部报错。

---

# 第一百三十九章 消息搜索

V1不做：

> 全局聊天内容搜索。

用户端也暂不需要聊天记录搜索。

降低开发与隐私复杂度。

---

# 第一百四十章 后台不做聊天大数据分析

V1不建设：

- 聊天情感分析
- AI全量监听
- 聊天画像
- 关系亲密度预测

风险检测只做：

> 最小必要的安全规则。

---

# 第一百四十一章 监控指标

技术监控：

```text
WebSocket在线连接数
连接成功率
重连率
消息发送成功率
消息发送P95
消息失败率
上传失败率
```

---

# 第一百四十二章 业务安全指标

```text
每千次会话举报数
被拉黑率
高频发送账号数
重复文本风险账号
资金类风险提醒数量
诈骗举报数
```

---

# 第一百四十三章 不把“聊天多”作为成功核心指标

聊天消息数量大：

> 不代表婚恋效果好。

真正关注：

```text
Match后聊天启动率
持续沟通率
正在了解率
成功牵手率
```

---

# 第一百四十四章 Conversation长期沉默

例如Match后：

> 30天双方都未发消息。

可以标记：

> inactive。

但V1不需要自动关闭。

---

# 第一百四十五章 是否做破冰提示

可以轻量提供：

```text
不知道怎么开始？
可以从兴趣、工作和周末生活聊起。
```

不需要AI。

---

# 第一百四十六章 破冰提示不要自动发送

只作为：

> 用户自己看的提示。

绝不能自动替用户发：

> “你好，你也喜欢旅行吗？”

---

# 第一百四十七章 聊天首屏示例

```text
← 王女士                           ···

安全提醒
请保护个人隐私，谨慎涉及转账、
借款、投资等资金往来。         ×

          你们互相喜欢
      可以开始进一步了解了

[头像] 你好，很高兴认识你

             你好，我也是

────────────────────────

😊  输入消息...                  ＋
```

---

# 第一百四十八章 Conversation关闭示例

```text
← 王女士

历史聊天内容……

────────────────────────

当前匹配关系已结束，
无法继续发送消息。
```

不显示Input。

---

# 第一百四十九章 被风控限制示例

```text
当前账号部分功能暂时受限，
暂时无法发送消息。

[查看账号状态]
```

---

# 第一百五十章 消息服务内部模块建议

```text
ConversationService
MessageService
MessagePermissionService
MessageRiskService
UnreadService
RealtimePushService
NotificationService
```

仍属于模块化单体。

---

# 第一百五十一章 MessagePermissionService

负责：

```text
用户是否属于Conversation
Match是否有效
Block关系
AccountStatus
Conversation状态
can_send
```

所有发送请求统一调用。

---

# 第一百五十二章 MessageRiskService

负责：

- 消息频率
- 重复文本
- 风险关键词
- 可疑外链
- 风险事件

不负责：

> 永久封禁决定。

严重事件交Risk模块。

---

# 第一百五十三章 UnreadService

统一维护：

```text
conversation unread
chat total
notification unread
total unread
```

防止多个模块各算一套。

---

# 第一百五十四章 RealtimePushService

只负责：

> 把已经发生的业务事件推给在线客户端。

不能把WebSocket当业务数据库。

---

# 第一百五十五章 Redis在实时消息中的用途

可以：

- userId → connection/node映射
- 在线状态
- 未读缓存
- Pub/Sub跨实例推送

如果V1只有单实例：

> Redis Pub/Sub甚至可以暂时不使用。

但接口设计应方便未来扩展。

---

# 第一百五十六章 多实例未来扩展

未来后端2台：

```text
Backend A
Backend B
```

用户A连接A。

用户B连接B。

消息保存后：

> Redis Pub/Sub通知B实例。

V1先预留。

---

# 第一百五十七章 不建议V1引入Kafka

实时聊天量在丹阳本地初期无需Kafka。

优先：

> PostgreSQL + Redis + WebSocket。

---

# 第一百五十八章 消息数据库写入优先

原则：

```text
先落库
↓
再推送
```

不要：

```text
先推给对方
↓
数据库写入失败
```

否则双方消息状态会错乱。

---

# 第一百五十九章 推送失败

消息已经落库：

> 仍是成功。

接收方下一次：

- 打开消息页
- WS重连
- 拉取增量

都能看到。

---

# 第一百六十章 消息同步Cursor

客户端保存：

```text
lastMessageSyncCursor
```

重连：

```text
GET /messages/sync?cursor=...
```

可作为未来接口。

---

# 第一百六十一章 V1是否必须做全局sync接口

不是绝对必须。

可以先：

> 重连后刷新Conversation列表 + 当前Conversation。

但建议预留：

```text
/messages/sync
```

以后更稳。

---

# 第一百六十二章 服务端事件顺序

事件至少包含：

```text
eventId
occurredAt
```

客户端遇到顺序异常：

最终以REST拉取的服务端状态为准。

---

# 第一百六十三章 网络恢复策略

断网时：

用户输入：

> 草稿保留。

发送失败：

> failed。

恢复网络：

不自动把所有失败消息无限发送。

建议：

> 用户点击重试

或仅对明确未提交成功的消息做有限重试。

---

# 第一百六十四章 图片消息弱网

图片上传过程中断：

> 显示失败。

重新上传。

不要产生：

> 空白Image消息。

---

# 第一百六十五章 安全降级

Risk关键词服务异常：

普通消息：

> 可以在满足基础安全条件下继续发送。

但：

- AccountStatus
- Block
- Conversation权限

这些核心安全检查不可绕过。

---

# 第一百六十六章 权限服务异常

如果无法判断：

> 当前用户是否属于Conversation。

必须：

> Fail Closed。

拒绝发送。

---

# 第一百六十七章 用户隐私设置和聊天

用户关闭：

> visibleInSearch

不会自动关闭已有Match聊天。

隐私曝光和已有关系：

> 分开。

---

# 第一百六十八章 paused状态和聊天

用户暂停寻找：

> 仍可继续已有聊天。

暂停的含义是：

> 不寻找新人。

不是：

> 强制断掉已有沟通。

---

# 第一百六十九章 getting_to_know和聊天

正常保留。

甚至这是聊天最主要阶段。

---

# 第一百七十章 successful状态和聊天

成功牵手后：

> 已有双方Conversation继续保留。

平台不强制关闭。

---

# 第一百七十一章 多Match聊天

用户可能同时有多个Mutual Match。

每个Conversation独立。

V1不人为限制：

> 只能聊一个人。

---

# 第一百七十二章 红娘是否知道用户有多少会话

红娘可以看到：

> 用户匹配/服务摘要

但不需要看到：

- 聊天对象详情列表
- 聊天内容

只提供服务必要的有限状态。

---

# 第一百七十三章 防骚扰优先级

```text
Block
>
Account Restriction
>
Conversation Status
>
Message Rate Limit
>
Risk Warning
```

---

# 第一百七十四章 用户主动权

任何时候用户都能：

- 不回复
- 解除匹配
- 拉黑
- 举报

不需要经过红娘批准。

---

# 第一百七十五章 Chat API验收

必须测试：

```text
无Match发消息
单向Like发消息
有效Match发消息
已Unmatch发消息
被Block发消息
账号被封禁发消息
重复clientMessageId
消息超长
空消息
图片失败
```

---

# 第一百七十六章 实时通信验收

必须测试：

- 双方在线
- 一方离线
- WS断线重连
- 微信切后台再回来
- Token过期
- 账号实时封禁
- 消息重复推送
- 消息乱序
- 推送失败后REST恢复

---

# 第一百七十七章 未读验收

确保：

```text
聊天列表未读
消息Tab Badge
Conversation已读
系统通知未读
```

数据一致。

---

# 第一百七十八章 反骚扰验收

模拟：

- 1秒发100条
- 多会话复制广告
- 连续发送联系方式
- 多人举报
- 资金关键词
- 多次拉黑
- 正常用户快速聊天

必须：

> 拦异常，但不能严重误伤正常沟通。

---

# 第一百七十九章 隐私验收

必须测试：

- 红娘查看聊天 → 拒绝
- 活动管理员查看聊天 → 拒绝
- 普通管理员获取聊天 → 拒绝
- 风控员无案件访问 → 拒绝
- 有权限风控员关联举报访问 → 允许并审计

---

# 第一百八十章 V1明确不开发

```text
语音通话
视频通话
语音房
群聊
直播
红包
支付
礼物
阅后即焚
消息撤回
聊天记录全局搜索
AI自动回复
AI代聊
自动情感分析
恋爱亲密度评分
“正在输入”状态
已读回执展示
```

---

# 第一百八十一章 开发优先级

## P0

```text
Conversation
Text Message
Message Permission
REST发送
WebSocket接收
未读
历史分页
失败重试
Unmatch关闭
Block关闭
AccountStatus实时限制
```

---

## P1

```text
Image Message
RiskNotice
发送限频
重复文本检测
系统通知
微信订阅消息封装
```

---

## P2

```text
更完善的增量Sync
聚合通知
反Spam规则优化
消息性能统计
```

---

# 第一百八十二章 最终架构

```text
                ┌─────────────────┐
                │ 微信小程序客户端 │
                └───────┬─────────┘
                        │
             HTTPS      │      WSS
              ↓         │       ↓
        ┌──────────┐    │  ┌──────────────┐
        │ REST API │    │  │ WebSocket    │
        └────┬─────┘    │  │ Gateway      │
             │          │  └──────┬───────┘
             ↓          │         │
        MessageService  │         │
             │          │         │
       ┌─────┼─────┐    │         │
       ↓     ↓     ↓    │         │
 Permission Risk  Unread│         │
       │     │     │    │         │
       └─────┼─────┘    │         │
             ↓          │         │
         PostgreSQL     │       Redis
             │          │
             ↓          │
      RealtimePush ─────┘
```

---

# 第一百八十三章 最终设计原则

V1.0实时聊天与消息体系必须坚持：

> **没有双向喜欢，就没有聊天。**

> **消息先落库，再实时推送。**

> **每条消息都有客户端幂等ID。**

> **WebSocket断线不能造成消息丢失。**

> **拉黑、解除匹配和封禁必须立即停止发送。**

> **暂停寻找不影响已有正常聊天。**

> **工作人员默认没有查看私人聊天的权限。**

> **风险关键词用于提醒和发现风险，不用于简单粗暴定罪。**

> **用户可以自主拉黑、举报、结束匹配。**

> **V1只做可靠沟通，不把聊天模块做成复杂社交平台。**

最终要达到的体验不是：

> “功能很多。”

而是：

> **双方愿意聊的时候，消息稳定、简单、安全；不愿意继续的时候，可以立即、明确、没有负担地结束沟通。**