技能介绍

要解决的问题

用户在产品内遇到问题时，最直接的求助方式是在应用里直接开口问。但从零搭建一套客服对话系统并不轻松：消息要实时送达、未读数要准确、对话历史要持久化、客服回复后还要考虑是否用邮件补位。任何一个环节处理不当，都会出现消息重复、状态错乱或通知轰炸之类的麻烦。

核心能力与实现步骤

数据层：建立 support_chats 与 support_messages 两张表，并在 user_id、last_message_at、archived_at 以及 (chat_id, created_at) 组合索引上做优化，保证列表排序与过滤的效率。

接口层：分别提供面向用户的 GET /support_chat 与面向客服的 GET /admin/chats 等端点。

实时通道：通过 ChatChannel 处理单会话消息广播，AdminNotificationChannel 做全局通知，前端同时订阅。

用户端组件：右下角浮动按钮，未读角标统计 sender_type='admin' 且未读的消息；Enter 发送、Shift+Enter 换行；打开面板时自动标记已读。

客服后台：会话列表支持活跃/归档筛选与未读提示；会话详情按日期分组消息，支持归档与恢复。

邮件补位：客服回复后延迟 5 分钟执行后台任务，发送前再次检查消息是否仍未读，避免邮件与站内提醒重复打扰。

关键设计取舍

每个用户固定一个会话，历史不中断；
归档即软删除，用户再次发消息时自动恢复；
前端记录已见过的消息 ID，防止广播回显造成重复；
读状态更新使用数据库事务，规避竞态。

适用边界与注意点

技能附带 Rails、React、Next.js、Laravel、Vue 的示例代码，以及 PostgreSQL、MySQL、SQLite、MongoDB 的建表建议。实时层可按部署环境选择 ActionCable、Socket.IO、Pusher、Ably 等，WebSocket 不可用时可退化为轮询。实施后应逐项验证：实时收发、角标计数、归档恢复、邮件延迟触发等行为是否符合预期。它不是环境验证的替代品，涉及权限与安全时仍需自行确认。