架构与核心流程

系统组成与边界

源码根目录：EinoTalk。路径均相对该目录。

层	作用	入口
React	登录、消息、联系人、群组和管理界面	frontend/src/
HTTP / 权限	REST 接入、JWT 与管理员权限	internal/https_server/、internal/middleware/
聊天服务	连接、消息分发、回显、群发	internal/service/chat/
持久化与缓存	MySQL 数据、Redis 消息与业务缓存	internal/model/、internal/dao/、internal/service/redis/
可选消息通道	Kafka 接入和集群转发	internal/service/kafka/、internal/service/cluster/
AI 助手	工具、上下文、流式回复	internal/agent/

核心请求流程

1. 用户登录获取 token，前端保存登录态，HTTP 请求通过 Axios 附加 Bearer token；服务端负责最终鉴权。
2. 建立聊天 WebSocket，消息进入 channel 或 Kafka 通道。
3. 公共分发逻辑构造消息、尝试落库、向接收方推送 / 向发送方回显、追加缓存，并按条件触发 Agent。
4. 多实例下，集群桥接查询在线路由，将事件转发到持有用户连接的节点。
5. Agent 使用会话上下文和工具生成流式结果，前端消费对应事件更新消息。

数据模型与接口

• 核心实体：用户、群组、联系人、申请、会话、消息；字段见 internal/model/ 与 README。
• HTTP 请求与响应类型位于 internal/dto/，前端 API 位于 frontend/src/api/。
• 前端统一处理 HTTP 401 / 403 与部分业务响应码，消息传输身份仍需服务端确认，不能信任客户端 sendId。
• dispatch.go 的落库失败当前记录日志，调用方仍可能继续推送；不能据此承诺“持久化成功后才推送”或事务一致性。
• Redis Pub/Sub 的节点转发不是持久队列，断订阅可能影响实时推送；Kafka 本身也不代表端到端 exactly-once。

验证与证据

• 单实例：两账号私聊、发送方回显、历史拉取、群聊、未认证与无权限操作。
• 多实例：收发双方连接不同节点，检查实际收包与消息记录；再执行重连、节点退出和 Redis 中断。
• AI：区分 Mock 与真实模型，测试首个增量、完整回复、超时和授权边界。
• 入口：internal/service/chat/dispatch_test.go、internal/service/chat/cluster_bridge_integration_test.go、bench/README.md；均未在本次运行。