foodie-server/specs/012-im-user-integration/quickstart.md

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

Phase: 1 | Date: 2026-06-23

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

前置条件

1. 数据库已执行 updatesql/sql.md 中 info_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==200，data.apiKey 与 data.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 即覆盖老用户补建）。
• 注册流程未被改动（回归验证：注册接口行为与返回结构保持原样）。