vibe 项目私信系统实战：三种会话形态、投递链路与反骚扰四件套

一、私信不是"发个消息"：先分清三种会话形态

很多 vibe 项目给私信功能的第一版需求只有一句话："用户之间能发消息。"然后直接开干。三个月后返工的原因几乎都一样：把三种完全不同的会话形态塞进了一套逻辑。

私信在产品层面其实是三种东西：

• 1v1 熟人会话：双方已经建立联系（互关、好友、交易对手），消息默认直达，有已读、有推送、有输入状态。
• 陌生人搭话：一方主动发起，对方还没确认。这不是"会话"，而是一个请求。对方有权不看、拒绝、拉黑，且发起方不应该知道对方"已读不回"。
• 小群（3 人以上）：看起来只是"多两个人"，实际上是另一个产品——群成员管理、入群审批、群已读（已读 N 人）、群通知聚合、管理员权限，每一项都是新系统。

我的判断很直接：v1 只做前两种，小群只做数据模型上的预留。理由不是"做不出来"，而是小群的每一项能力都会反噬 1v1 的简洁性：已读从"水位线"变成"每人一条回执"，推送从"点对点"变成"聚合免打扰"，权限从"拉黑"变成"踢人/禁言"。先做小群的团队，最后都是把 1v1 逻辑重写一遍。

还有一个产品层面的判断，决定你值不值得投入：如果你的 vibe 项目是一个作品展示站、社区或交易撮合站，私信的最大价值是"促成连接"，而不是"成为聊天工具"。用户要的是"联系上这个作者/买家"，不是"再装一个微信"。所以 v1 的完成标准应该是：能发起、能送达、能防骚扰，而不是消息气泡有多好看。

陌生人搭话的产品形态值得单独想一分钟，因为它直接决定状态机的复杂度。微信的"加好友验证"和领英的 InMail 是两种极端：前者是强关系前置（先成为好友才能说话），后者是付费搭话（花钱买触达）。vibe 项目大多处在中间地带：消息请求制——允许陌生人先说一句话，对方看完再决定接不接。这个选择的好处是 friction 最低，代价是你必须在技术上兑现"请求"的语义：pending 状态的消息不能进已读、不能进未读数、不能触发强推送。如果你的第一版把陌生人消息和熟人消息混在同一个会话列表里用同一种样式展示，请求制就只剩了个名字。

二、数据模型：三张表，加一个状态机

私信的数据模型我推荐三张表，这是经过最多项目验证的最小完备结构：

• conversations：会话本身。id、type（direct / stranger，预留 group）、created_at。注意这里不放状态。
• conversation_participants：谁在会话里，以及他眼中的会话状态。conversation_id、user_id、status（陌生人会话用：pending / accepted / declined / blocked）、last_read_message_id、last_read_at、muted、deleted_at（单方删除）。
• messages：消息。id、conversation_id、sender_id、client_message_id（客户端生成的 UUID，唯一索引，做幂等）、body、attachments（JSON）、status（sent / recalled）、created_at。

这里有一个关键的设计判断，很多人第一次会做错：为什么"接受/拒绝/拉黑"放在 participant 表而不是 conversation 表？因为这些动作是单方视角的。A 拉黑 B 之后，A 眼中的会话是 blocked，B 眼中的会话可能还停留在 accepted——只不过 B 再发消息会被拦截。状态放在 participant 侧，两端各持一份，互不污染，这才是"拉黑对方无感知"在技术上成立的前提。

陌生人会话的状态机如下。注意 pending 状态的产品约束：只展示首条消息（或摘要），不产生已读、不触发输入状态，发起方看不到任何回执——这是反骚扰的第一道墙，不是 UI 细节。

索引别省，三处是刚需：messages(conversation_id, id) 支撑会话内分页拉取；messages(client_message_id) 唯一索引支撑幂等去重；conversation_participants(user_id, updated_at) 支撑"我的会话列表"按最近消息排序。会话列表的"最后一条消息摘要"可以冗余在 conversation 表（last_message_preview、last_message_at），用写消息时同步更新，代价是一次额外写入，收益是列表页永远不用 JOIN。

未读数的计算是水位线的免费附赠：未读数 = 该会话消息总数 - 水位线之后的消息数，实际用一条按 id > last_read_message_id 的计数查询就能拿到，不需要未读标记表。但注意 pending 状态的会话不计入未读总数——请求不是消息，这是产品语义，不是 SQL 技巧。另外 type 字段现在就把 group 预留好，哪怕 v1 没有任何群逻辑。将来加群时，participant 表天然支持"每人一份状态"（群里的 mute、免打扰、入群时间都是单方视角），你会感谢今天这个决定。

三、投递实时性：WebSocket 只是通知通道，真相在数据库

私信实时性最常见的架构误区是把 WebSocket 当成"消息总线"：消息走 socket 发，落库"顺手"做一下。断线、扩容、重启，丢的消息全都找不回来。正确的顺序永远是：先落库，再通知。WebSocket 只是告诉对方"有新消息了，快来拉"，消息的真相来源永远是数据库。

房间命名建议用 dm:{conversationId}。握手鉴权是必须的，而且要用你已有的鉴权体系：连接建立时校验 token，并校验该用户是该会话的 participant。只验 token 不验 membership，等于把房间号当密码——房间号是可枚举的，这不是理论风险。

离线补拉是另一半：客户端本地存 lastSyncMessageId（或时间戳游标），每次建连/回到前台后，用游标拉取增量。这个游标和第四节的已读水位线是两个东西，别混用：同步游标管"拉没拉到"，已读水位线管"看没看到"。

幂等去重是断网场景的保命项。移动端弱网下，发送超时→客户端重试→服务端收到两条，是必然发生的日常，不是边界 case。做法：客户端生成 UUID 作为 clientMessageId 随消息发出，服务端对它建唯一索引，冲突直接返回已存在的那条消息。重连补拉时客户端按 clientMessageId 本地去重，双保险。

心跳和重连退避顺手一起定：客户端心跳 25-30 秒一次（数值按你的网关超时调），断线重连用指数退避（1s、2s、4s……封顶 30s），避免服务端重启时所有客户端同时砸回来形成重连风暴。压测时专门要测这一项，见第九节。

多网关是迟早要面对的问题，方案现在就要想好：单网关实例时房间订阅是内存里的事；扩到多实例后，dm:{conversationId} 的订阅关系要有一个中心化的发布订阅层（Redis Pub/Sub 或消息队列的 topic 都行，选你栈里已有的）。消息落库后发布到对应房间 topic，各网关实例只把消息推给自己持有的连接。这个设计越早定越好，因为"先落库再通知"的顺序在多网关下依然成立——落库是单点真相，扇出可以水平扩展，两者不冲突。移动端还有个现实问题：App 进后台后 WebSocket 会被系统杀掉，这时"实时"要降级为推送兜底。做法是服务端记录每个用户的在线状态（网关心跳维持），用户离线时跳过 WS 推送、直接走第七节的聚合推送。别指望移动端保活，那是和操作系统作对。

四、已读回执：用水位线，别用逐条回执

已读回执的新手做法是每条消息一条回执记录：B 读了 100 条消息，写 100 条 message_reads。这在小群里是灾难，在 1v1 里是浪费。正确做法是 read watermark（已读水位线）：participant 表里的 last_read_message_id 加 last_read_at，一条记录就表达了"我读到哪儿了"。

双蓝勾/已读标签的真相其实很简单，就两条规则：

• 送达（server-acked）：消息写进数据库，服务端确认。客户端显示单勾/发送成功。
• 已读：对方的水位线 last_read_message_id ≥ 该消息 id。显示双勾/已读。

水位线更新时机也有讲究：不是"消息渲染了"就更新，而是"会话窗口处于前台且用户真实滚动到了底部"才推进。否则用户切回来扫一眼列表，所有会话全变已读——这不是 bug，这是对注意力的不尊重。更新时只推进不回退（单调递增），并发写入用 UPDATE ... WHERE last_read_message_id < 新值 兜底。

"正在输入"（typing indicator）同样别落库：客户端节流心跳（比如 3 秒一次），停止输入 5 秒后自动清除；服务端只做房间内透传，不持久化。这是纯粹的 ephemeral 状态，落库就是给自己找麻烦。

最后是一个产品判断：给用户关掉已读回执的开关。但规则要对等——关了已读回执的人，自己也看不到对方的已读状态。这是微信们早就验证过的约定，抄就行，不用重新发明。

多端同步是水位线方案的另一个红利：水位线存在服务端 participant 记录里，手机上读到第 100 条，电脑端打开会话时直接从水位线开始渲染，"已读"天然同步。不需要端到端的状态同步协议，这是把状态放在服务端而非客户端换来的。当然代价是隐私：服务端知道你读到了哪一条。如果你做的产品对"已读"这件事本身敏感（比如职场社交），要在隐私政策里写清楚水位线的存在——技术上它就是一条"我读到哪了"的记录，藏不住，不如写明白。

五、反骚扰四件套：上线第一天就要有，别等被投诉

私信功能和评论区最大的区别：骚扰是定向的、隐蔽的，被骚扰的用户不会发帖骂你，他只会默默流失。所以反骚扰不是"治理模块"，而是私信 v1 的核心需求。以下四件套按发送链路的先后顺序排列：

1. 陌生人消息请求制：非联系人发起的会话进入 pending，对方只看到"有一条消息请求"和首条摘要，接受前不产生已读、不弹内容推送。发起方在对方接受前只能发有限条数（比如 1-3 条，数量按业务定），防止用请求制刷屏。
2. 拉黑与举报：拉黑是单方静默操作，对方无感知、不可再发起；举报则进入治理漏斗（人工/自动审核、留痕备查），这部分与《内容审核实战》里讲的治理流程互链，私信侧只负责把"被举报的消息元数据"完整移交。
3. 频率限制：以 (sender, recipient) 二元组为 key 的滑动窗口限流。实现上用 Redis 有序集合（时间戳做 score，窗口内计数）或固定窗口计数器都可以，选你团队熟悉的。阈值按业务调，不存在标准数字：新注册账号更严、互关用户放宽、被举报过的账号收紧。超限返回 429，客户端做指数退避，别让用户狂点重试把自己锁死。
4. 敏感词前置过滤：发送链路的第一道门，在落库前拦截。词库要可配置、可灰度更新；误伤不可避免，所以被拦截的消息要给用户明确提示（"包含敏感内容，请修改后重发"），并留人工复核/申诉通道。别做成静默吞掉——静默吞消息是对用户最不尊重的设计。

顺序也有讲究：拉黑检查最先（被拉黑的人连计数器都不值得消耗），然后是频率限制（便宜），然后是敏感词（稍贵），最后才是落库和请求制判断。把贵的检查往后放，是基本的成本意识。

风控分层是频率限制的进阶形态，值得在 v1 就留好扩展点：同一套 (sender, recipient) 限流框架下，给不同用户分层。新注册账号、异地登录、被举报过的账号走严格档；互关、老用户走宽松档。分层的依据存在用户画像或风控标签里，限流中间件只读标签、不做判断——判断逻辑收敛在一处，以后加"设备维度限流""IP 维度限流"都是加标签的事，不用改发送链路。但提醒一句：风控做到设备指纹、行为画像就是另一个系统了，v1 别碰，标签+分档足够。

六、附件与图片：复用上传链路，别另造一套

私信里的图片、文件，最省事的方案是复用项目已有的 file-upload 链路（上传接口、存储桶、CDN），不要为私信单独建一套上传服务。两套上传链路意味着两套鉴权、两套清理策略、两套账单，v1 阶段纯属负资产。

但有一个关键区别：私信附件不能走公开 CDN 永久 URL。公开 URL 一旦发出就收不回，任何拿到链接的人都能访问，这和"私信"的语义直接冲突。做法是私密桶 + 短 TTL 签名 URL：附件存在私有存储，每次展示时由服务端签发带过期时间的临时 URL（比如 15 分钟量级，具体按业务调整——图片消息列表滚动时按需续签）。

服务端校验同样不能省：MIME 白名单、单文件大小上限、图片生成缩略图（列表页只加载缩略图，原图点开再签 URL）。客户端先压缩再上传，省流量也省存储费。

还有一个陌生人场景的细节：pending 状态的会话，附件默认不渲染原图，只显示"对方发送了一张图片/文件"的占位，等对方接受后再加载。这是防恶意图片轰炸的低成本手段——骚扰者最爱用的就是连发几十张图。

附件的内容安全要单独提一句，因为它和文字敏感词不在一个量级：图片、视频里的违规内容，关键词库拦不住。根据你的目标法域，可能需要接入内容安全审核（云厂商基本都提供图片/视频审核 API，按量计费）。我的建议是：先做"可疑先审"——陌生人发送的附件先进审核队列（异步，不阻塞发送链路，pending 本来就不展示原图），熟人会话的附件抽样审核。等业务量起来了再全量。不要一上来就全量同步审核，那延迟和账单都会教你做人。

七、通知联动：私信触发推送，最忌每条都推

私信和推送联动时最大的坑，就是把"消息到达"和"推送发送"画等号。对方连发 10 条消息，用户手机震 10 次——下场是用户关掉通知权限，然后你的消息到达率归零。这是自己把路走死的典型。

正确姿势是静默聚合：服务端维护一个短窗口（比如几十秒，按业务调），窗口内的多条消息合并成一条摘要推送（"张三：…等 3 条消息"）。窗口的精确时长不重要，重要的是"聚合"这个机制存在。

另外两条产品规则：

• 陌生人请求不推内容：pending 会话只推"有人想和你聊聊"，不推消息正文。既防骚扰预览，也避免锁屏界面泄露隐私。
• 会话级免打扰 + 时段降级：用户可对单个会话 mute；深夜时段（按用户时区）自动降级为静默推送，第二天早上以摘要形式呈现。时段边界按业务定，不硬编码"22 点到 8 点"这种一刀切。

注意和《通知系统实战》的分工：那边讲的是系统→用户的单向广播（公告、营销、状态变更），这里是用户→用户的点对点触发。推送通道可以复用同一套，但聚合策略和免打扰语义是私信独有的，别混到一张表里。

推送 token 的失效处理是联动链路里最容易被忽略的一环：用户卸载重装、换手机，旧 token 失效，推送网关会返回明确的错误码（按你用的推送服务商文档处理）。收到"token 失效"后，服务端要把该设备的 token 标记清除，而不是一直往黑洞里发。否则你的推送到达率报表会越来越难看，而你还以为是用户不活跃。另外，聚合窗口内的消息如果被撤回（第八节），推送文案要跟着修正——"张三撤回了一条消息"这种推送本身也是打扰，撤回不触发新推送，只在用户点进会话时看到状态即可。

八、删除语义：单方删、双方撤、举报留痕是三件事

"删除消息"在私信里是三个完全不同的动作，混在一起是客服灾难：

• 单方删除：只删自己这边的视图。实现是在 participant 表打 deleted_at（或按消息粒度的 deleted_message_ids），对方完全不受影响。这是最常用的"删除"，语义清晰，没有歧义。
• 双方撤回：产品约定，不是技术删除。服务端把消息标记为 recalled 并清空正文，对方看到"对方撤回了一条消息"。但必须诚实地告诉用户它的边界：对方可能已经截图，推送可能已经送达，撤回召回不了这些。撤回时限（比如 2 分钟）按业务定，写进产品文案，别让用户以为是"无痕销毁"。
• 举报留痕：被举报的消息，其元数据（发送方、时间、会话、原文快照）要保留备查，走治理漏斗。留痕时长按所在法域的合规要求定，不要编造法条和具体数字——这不是技术能决定的，是法务的事。

数据库层面一律软删除。硬删除（物理删行）只发生在账号注销、合规要求等明确流程里，并且要有审计日志。私信是用户纠纷的高发区，"数据没了"是最贵的回答。

撤回还有一个推送侧的边界要诚实面对：消息发出后，推送可能已经通过系统通道送达对方手机。主流推送服务都不支持"召回已送达的推送"，所以"对方撤回了一条消息"这条系统提示，只能在对方点进 App 之后才看得到，锁屏上那条原文推送是收不回的。把这个写进你的产品文案和帮助文档，比让用户在客服工单里发现要体面得多。技术做不到的事，产品文案要先认。

九、上线 checklist：12 条必测用例

私信上线前，除了常规的功能测试，下面这些是专门容易翻车的地方。压测三项先讲：

• 单房间消息扇出：大量连接订阅同一房间时的推送延迟（v1 主要是 1v1，但压测要覆盖你预留的上限）。
• 重连风暴：模拟网关重启后所有客户端同时重连，观察退避策略是否生效、服务端是否被打满。
• 长连接数：单机能扛多少 WebSocket 长连接，内存和文件句柄先摸到天花板，扩容方案（多网关 + 房间路由/发布订阅）提前想好。

消息审计也要在上线前就位：谁在何时往哪个会话发了消息、谁执行了拉黑/举报/撤回，这些操作日志不是"有了再说"，而是第一起用户纠纷来的时候你唯一能拿出来的东西。

12 条必测用例，一条都别跳过：

1. 断网重连：发送中途断网，重连后消息不丢、不重复（clientMessageId 幂等）。
2. 重复提交：同一 clientMessageId 发两次，服务端只存一条。
3. 陌生人 pending：对方接受前，发起方看不到已读，收不到输入状态。
4. 拉黑：拉黑后对方发送直接被拒，且对方无感知（不提示"你被拉黑了"）。
5. 撤回：撤回后对方会话显示"已撤回"，正文不可再拉取。
6. 附件签名 URL：过期后访问被拒，续签后可访问；pending 会话附件只显示占位。
7. 频率限制：超限返回 429，客户端退避后恢复。
8. 敏感词：命中拦截给明确提示，不静默吞消息。
9. 已读水位线：只推进不回退；多端登录时已读状态同步。
10. 免打扰：mute 的会话只静默聚合，不震铃。
11. 单方删除：删了自己这边，对方消息不受影响。
12. 注销合规：账号注销流程触发私信数据的硬删除，审计日志可查。

最后说一句大实话：私信系统的技术难度不在 WebSocket，在状态机和边界语义。会话有几种形态、删除有几种含义、已读到底是什么——这些产品判断先想清楚，代码只是翻译。v1 把"能发起、能送达、能防骚扰"做扎实，小群、端到端加密、已读精确到人这些，等用户真的需要了再加。先让两个人能好好说话，再考虑一群人怎么说话。

上线节奏上，别一次全量。先灰度：内部账号 → 5% 用户 → 50% → 全量，每个阶段盯三天核心指标（消息发送成功率、推送到达率、举报量、429 触发量）。私信是社交链路，出问题用户感知极强，灰度期间把"一键关闭陌生人搭话"的总开关准备好——真出舆情时，能立刻把请求制入口关掉，比连夜修 bug 管用。开关先行，功能随后，这是所有用户触达型功能的上线铁律。