quickstart.md 2.5 KB

Quickstart: 骑手与用户 IM 即时沟通账号接入

Phase: 1 | Date: 2026-06-23

端到端验证指南。本文件仅描述"如何验证功能可用",具体实现代码见 tasks.md 与实现阶段。

前置条件

  1. 数据库已执行 updatesql/sql.mdinfo_user 加两列的 ALTER(由开发者统一手动执行)。
  2. application.yml 已配置 im 段(base-url / ext-token / create-path / timeout-ms),且 im.ext-token 与 IM 平台一致。
  3. 后端服务已重启加载新配置与新代码。
  4. 已有一个可登录的测试用户(任意类型),拿到其登录 token

验证场景

场景 1:首次开通 IM 账号(核心)

步骤

  1. 用测试用户 token 调用:

    POST http://localhost:8082/infouser/user/im/open
    Header: token: <测试用户token>
    
  2. 检查响应 code==200data.apiKeydata.imUserId 非空。

  3. 查库确认:

    SELECT im_api_key, im_user_id FROM info_user WHERE user_id = <该用户id>;
    

    两列均已写入非空值,且 im_user_id 与响应 data.imUserId 一致。

预期:成功返回凭证;库中两列成对写入。

场景 2:幂等返回

步骤:对同一用户再次调用 POST /infouser/user/im/open

预期

  • 响应 apiKey/imUserId 与场景 1 完全一致。
  • IM 平台 extCreate 未被再次调用(可通过日志/IM 侧确认账号创建次数仍为 1)。
  • 库中凭证不变。

场景 3:未登录拒绝

步骤:不带 token(或带失效 token)调用 POST /infouser/user/im/open

预期:返回未登录错误,不产生 IM 账号,库无写入。

场景 4:IM 平台失败降级

步骤:临时把 im.ext-token 改成错误值(或断网模拟 IM 不可达),重启后用新用户调用开通接口。

预期

  • 接口返回失败(IM 开通失败,可重试)。
  • 库中该用户 im_api_key/im_user_id 仍为 NULL(不写无效凭证)。
  • 恢复正确 token 后重试 → 成功(回到场景 1)。

场景 5:全用户类型覆盖

步骤:分别用普通用户(0)、商家(1)、骑手(2)、夜市(3) 的 token 调用开通接口。

预期:四类用户均能成功开通(验证 FR-007 不按类型限制)。

通过标准

  • 场景 1~5 全部符合预期。
  • 新老用户(im_api_key 原为空)都能通过同一接口开通(场景 1 即覆盖老用户补建)。
  • 注册流程未被改动(回归验证:注册接口行为与返回结构保持原样)。