# khhao 新数据来源接入设计

## 1. 背景

当前系统的订单来源只有 `agiso`，核心模式是：

- 上游通过 webhook 推送订单事件；
- 后端按 `provider + platform + shopId + platformOrderId` 幂等落库；
- 命中履约绑定后生成任务、领取链接、自动发货等后续流程。

现在需要新增一个来源：`admin.khhao.com` 这一套已开发好的平台后台。

和 `agiso` 的差异是：

- **不是 webhook 推送**，而是**账号密码登录 + 验证码识别 + Cookie 会话查询**；
- 订单数据来自平台接口查询；
- 初期目标是先完成**登录能力**与**订单查询能力**，再决定是否做定时拉取/增量同步。

## 2. 已确认事实（来自 `2026-05-02` 的 HAR）

HAR 文件：`/Users/yml/Desktop/抓包/登陆.har`

已确认接口链路：

1. 打开登录页  
   `GET https://admin.khhao.com/c/login/index.php`

2. 获取验证码图片  
   `GET https://admin.khhao.com/verify_img.php`

3. 提交登录表单  
   `POST https://admin.khhao.com/c/login/index.php`  
   表单字段：
   - `username`
   - `password`
   - `img_code`

4. 登录成功响应  
   ```json
   {"errcode":0,"msg":"登陆成功","url":"/c/payOrder/index.php"}
   ```

5. 查询订单列表  
   `GET https://admin.khhao.com/c/payOrder/get.php?page=1&limit=50`

6. 当前 HAR 中，登录依赖 `PHPSESSID` Cookie 维持会话。

订单列表响应里已看到这些关键字段：

- `ordersn`：外部订单号
- `pingtai` / `pingtaiName`：平台标识/平台名
- `shopid` / `shopName`：店铺
- `goodid` / `goodName`：商品
- `sku`：SKU
- `fee`：成交金额
- `chengben` / `lirun`：成本/利润
- `num`：数量
- `status` / `statusName`：订单状态
- `addtime`：下单/录入时间

## 3. 设计目标

### 3.1 MVP 目标

先做最小可用能力：

1. 后端可通过账号密码自动登录 khhao；
2. 自动拉取验证码图片，并用现有 `ddddocr` 识别；
3. 登录成功后带 Cookie 调用订单查询接口；
4. 能按统一结构把 khhao 订单转换为内部订单模型；
5. 提供一个**手动查询 / 手动同步**入口，先不直接接入自动履约主流程。

### 3.2 第二阶段目标

1. 支持按时间窗口或页码批量拉取订单；
2. 增加定时轮询同步；
3. 将 khhao 订单正式纳入现有订单履约流程；
4. 视需要增加远端订单详情接口接入。

## 4. 关键设计决策

## 4.1 新来源标识

建议：

- `provider = 'khhao'`
- `platform = 由返回字段映射`

原因：

- 现有系统已经以 `provider/platform` 作为来源分层；
- khhao 本身更像“聚合后台/运营后台”，其下可能有多个平台；
- 后续如果 `pingtai=3` 代表快手、还有其它平台，也可以继续扩展。

建议先做一个映射表，例如：

- `3 -> kuaishou`
- 未识别值 -> `unknown`

同时把原始 `pingtai`、`pingtaiName` 放进 `raw_payload_json` 保留证据。

## 4.2 接入模式

`agiso` 是 **push**；`khhao` 应设计成 **pull**。

因此不要强行塞进 `webhook-service`，而是单独建立：

- 登录会话服务
- 验证码识别服务
- 订单查询服务
- 订单转换/同步服务

## 4.3 会话管理

建议优先采用 **纯 HTTP + Cookie Jar**，不引入浏览器自动化。

原因：

- HAR 显示登录流程很简单，没有前端加密、签名或复杂跳转；
- 验证码是普通图片；
- 登录后查询接口是标准 XHR；
- 用 HTTP 实现更稳定，也更适合服务端定时任务。

只有在后续发现以下情况时，再退回浏览器方案：

- 服务端校验动态前端字段；
- 有 JS 生成签名；
- Cookie/会话依赖浏览器行为；
- 验证码识别成功但仍反复登录失败。

## 4.4 OCR 复用

现有 OCR 子服务已经使用：

- `apps/backend/subservices/ocr-worker`
- `ddddocr>=1.6.1`

因此不需要新增 OCR 技术栈，只需要把 khhao 验证码图片作为图片字节传给现有 OCR 能力即可。

建议新增一个更通用的方法，而不是继续绑定在 “Tencent” 语义上：

- 现状：`recognizeTencentCaptcha`
- 建议新增：`recognizeImageCaptcha`

然后：

- 腾讯验证码继续走原接口或复用通用接口；
- khhao 登录验证码直接走通用接口。

## 5. 推荐模块拆分

建议新增目录：

`apps/backend/src/services/platforms/khhao/`

建议模块：

### 5.1 `captcha-service.js`

职责：

- 请求 `/verify_img.php`
- 读取图片字节
- 调 OCR
- 返回识别结果与调试信息

建议返回：

- `captchaText`
- `imageBase64`（仅调试阶段可选）
- `cookieHeaders`

### 5.2 `session-service.js`

职责：

- 初始化 Cookie 容器；
- 访问登录页，拿到初始 `PHPSESSID`；
- 获取验证码并识别；
- 提交登录表单；
- 校验登录响应；
- 返回已登录会话对象。

建议会话对象：

- `baseUrl`
- `cookieHeader`
- `cookieMap`
- `loggedInAt`

### 5.3 `order-query-service.js`

职责：

- 调用 `/c/payOrder/get.php`
- 支持分页参数：`page`、`limit`
- 后续支持筛选参数（如果继续抓到更多接口）
- 返回原始平台订单列表

### 5.4 `order-mapper-service.js`

职责：

- 将 khhao 原始订单映射成内部统一订单结构；
- 归一化金额、数量、状态、平台、店铺、SKU；
- 产出可供 `order-service` 或新同步服务消费的对象。

建议映射：

- `platformOrderId <- ordersn`
- `shopId <- shopid`
- `shopName <- shopName`
- `totalAmount <- fee`（转分）
- `items[0].skuCode <- sku`
- `items[0].skuName <- goodName`
- `items[0].quantity <- num`
- `rawPayload <- 原始整条记录`

注意：

- 当前列表接口一条记录看起来像“一单一商品”，但不能假设永远如此；
- 第一版可以先按单商品映射；
- 如果后续发现有多商品订单，再调整内部映射。

### 5.5 `order-sync-service.js`

职责：

- 批量查询 khhao 订单；
- 调 `order-mapper-service` 转换；
- 调内部订单 upsert；
- 记录同步结果、失败原因、游标信息。

这里建议不要直接复用 `upsertOrderFromWebhook(event)`，因为它的命名和语义绑定 webhook。

更合理的演进方向：

- 抽一个来源无关的方法，例如 `upsertOrderFromSource(event)`；
- `webhook-service` 继续只负责 webhook 解析；
- `khhao` 同步服务直接调用来源无关的 upsert。

## 6. 配置设计

## 6.1 运行时配置

建议在：

- `apps/backend/config/default.cjs`
- `apps/backend/src/types/runtime-config.js`
- `apps/backend/src/config/runtime.js`

增加：

```js
platforms: {
  khhao: {
    baseUrl: 'https://admin.khhao.com',
    timeoutMs: 5000,
    loginPath: '/c/login/index.php',
    captchaPath: '/verify_img.php',
    orderListPath: '/c/payOrder/get.php',
  },
}
```

## 6.2 凭据配置

不建议把账号密码直接写进仓库文档或默认配置。

建议通过以下方式之一管理：

1. 环境变量；
2. `apps/backend/data/khhao-sources.json`；
3. 后台平台配置页维护。

建议结构：

```json
{
  "sources": [
    {
      "sourceKey": "khhao-main",
      "enabled": true,
      "baseUrl": "https://admin.khhao.com",
      "username": "******",
      "password": "******",
      "defaultPlatform": "kuaishou"
    }
  ]
}
```

第一阶段最省成本的方案：**本地文件 + 环境变量覆盖**。

## 7. 与现有系统的衔接方式

## 7.1 第一阶段：只做手动查询/同步

建议新增后台接口，例如：

- `POST /api/v1/admin/platform-config/khhao/test-login`
- `POST /api/v1/admin/platform-config/khhao/query-orders`
- `POST /api/v1/admin/platform-config/khhao/sync-orders`

这样好处是：

- 不会影响现有 `agiso` 主链路；
- 可以先验证 OCR、登录、Cookie、字段映射；
- 便于比对真实订单数据。

## 7.2 第二阶段：纳入统一订单流程

当字段映射稳定后，再把 khhao 同步数据接到统一订单主链路：

- 来源查询 -> 订单映射 -> 通用 upsert -> 履约绑定 -> 任务生成

这一步需要补充：

- khhao 订单状态到内部 `orderStatus/payStatus` 的映射；
- 去重与增量同步策略；
- 同一来源重复登录的频率控制；
- 同步审计日志。

## 8. 状态映射建议

当前 HAR 仅看到：

- `status = 2` => `已发货`
- `status = 0` => `未打款`

第一阶段不要写死太多业务含义，建议：

### 内部订单状态

- `status=0` -> `created`
- `status=2` -> `delivered`
- 未知值 -> `unknown`

### 内部支付状态

- `status=0` -> `unpaid`
- `status=2` -> `paid`
- 未知值 -> `unknown`

但这只是 **初版推断**，最终要以更多样本验证。

## 9. 风险点

1. **验证码识别率**
   - `ddddocr` 大概率可用，但识别失败需要自动重试；
   - 建议单次登录允许 `2~3` 次验证码重试。

2. **登录态过期**
   - 需要判断何时复用 Cookie，何时重新登录；
   - 第一阶段可以每次查询都重新登录，先求稳定。

3. **订单列表不是详情接口**
   - 当前拿到的是列表接口，不排除存在订单详情页/详情接口；
   - 第一版先以列表字段落库；
   - 如果后续履约需要更多字段，再补抓详情接口。

4. **平台字段含义未完全确认**
   - `pingtai=3` 目前只从样本推断是快手；
   - 需要再抓几个平台样本确认映射表。

5. **同步边界**
   - khhao 是拉取式来源，必须明确增量条件；
   - 第一版建议按 `page/limit` 手动同步，先不做自动游标。

## 10. 推荐实施顺序

### 阶段 A：打通基础能力

1. 增加 khhao 配置结构；
2. 增加通用图片 OCR 能力；
3. 实现登录 + Cookie 会话；
4. 实现订单列表查询；
5. 增加后台“测试登录 / 查询订单”接口。

### 阶段 B：打通内部模型

1. 实现 khhao -> 内部订单映射；
2. 提炼 webhook 无关的通用 order upsert；
3. 增加手动同步接口；
4. 在后台展示同步结果。

### 阶段 C：进入自动履约

1. 增量同步；
2. 定时任务；
3. 状态回补；
4. 接入履约绑定、任务生成、消息通知。

## 11. 本次设计结论

结论很明确：

- khhao 不应该按 `agiso webhook` 思路接；
- 应该作为一个新的 **pull 型来源** 单独建接入层；
- OCR 直接复用现有 `ddddocr` 子服务；
- 第一阶段先做**手动查询/同步**最稳；
- 等字段、状态、平台映射稳定后，再接入统一履约主流程。