移除了 khhao 平台相关

This commit is contained in:
yml2213
2026-05-14 13:08:24 +08:00
parent d335b430e6
commit 83cb2ff1fa
56 changed files with 108 additions and 3893 deletions
+14 -14
View File
@@ -6,7 +6,7 @@
- **订单来源层**
- `agiso`Webhook 推送型;
- `khhao`:账号密码登录 + 验证码识别 + Cookie 会话拉取型。
- `91卡券`:开放接口下单型。
- **履约执行层**
- 当前以内置人工发货、腾讯领取兑换等执行器为主。
@@ -17,19 +17,19 @@
- 前端代码里根实例名显示为 `cloudtentacles`
这个平台**不是订单数据源**,而是**订单创建后用于执行发货/兑换的外部履约平台**。
它和 `khhao` 的相同点只是“都需要后台登录”,但系统角色完全不同:
它和订单来源平台的系统角色完全不同:
- `khhao`:订单来源 / 上游平台;
- `91卡券`:订单来源 / 上游平台;
- `cloudtentacles`:履约执行 / 下游发货平台。
它的登录链路`khhao` 明显不同
它的登录链路独立于订单来源
- 不是图片验证码识别;
- 是“账号 + 密码 + 手机号 + 短信验证码”登录;
- 登录参数不是明文提交,而是前端先做 `MD5 + RSA-OAEP(SHA-256)` 加密;
- 登录成功后不是 Cookie 会话,而是返回 `token`,后续通过 `Authorization` 请求头访问接口。
因此它应当作为**履约执行器能力**接入,复用 `khhao` 的“HTTP 登录平台”经验,但不要按“来源平台”建模。
因此它应当作为**履约执行器能力**接入,不要按“来源平台”建模。
---
@@ -178,7 +178,7 @@ MD5(password).toString(Hex)
更合理的定位是:
- 订单来源 `provider/platform/shopId` 仍然来自 `agiso` / `khhao`
- 订单来源 `provider/platform/shopId` 仍然来自 `agiso` / `91卡券`
- `cloudtentacles` 属于**履约执行器 / 外部发货平台**
因此它更适合进入这条链路:
@@ -207,9 +207,9 @@ MD5(password).toString(Hex)
- 发货业务服务
- 履约执行适配层
## 4.3 不建议直接照抄 khhao 的原因
## 4.3 不建议照搬来源平台的原因
`khhao` 当前链路核心是:
历史拉单平台链路核心是:
- 打开登录页
- 拉验证码图片
@@ -441,7 +441,7 @@ platforms: {
## 6.2 持久化来源配置
建议`khhao` 一样,先用数据文件落地,不急着进数据库。
建议先用数据文件落地,不急着进数据库。
建议文件:
@@ -563,7 +563,7 @@ POST /api/v1/admin/platforms/cloudtentacles/validate-session
## 8. 后台 UI 设计建议
第一版 UI 不需要太复杂,但应与 `khhao` 分开,避免把“订单来源配置”和“履约平台配置”混在一起。
第一版 UI 不需要太复杂,避免把“订单来源配置”和“履约平台配置”混在一起。
建议在“平台配置”页新增独立区块,归类到“履约平台”分组:
@@ -606,7 +606,7 @@ POST /api/v1/admin/platforms/cloudtentacles/validate-session
注意:
- 不要把这个平台和 `khhao` 放在同一张混合表单里;
- 不要把这个平台和订单来源放在同一张混合表单里;
- 页面上要明确区分:
- 订单来源平台
- 履约执行平台
@@ -656,7 +656,7 @@ POST /api/v1/admin/platforms/cloudtentacles/validate-session
也就是说:
- `agiso/khhao` 决定“订单从哪里来”
- `agiso/91卡券` 决定“订单从哪里来”
- `cloudtentacles` 决定“订单怎么发出去”
---
@@ -717,12 +717,12 @@ POST /api/v1/admin/platforms/cloudtentacles/validate-session
最重要的不是把接口先堆进去,而是先把结构定对:
- `khhao` 型平台:验证码图片 + Cookie
- 历史拉单型平台:验证码图片 + Cookie
- `cloudtentacles` 型平台:短信码 + RSA 加密 + token
二者都属于“后台登录型平台”,但在系统分层上不同:
- `khhao`:来源层
- `91卡券`:来源层
- `cloudtentacles`:履约层
因此第一版推荐结论是: