96 lines
4.4 KiB
Markdown
96 lines
4.4 KiB
Markdown
# 双商城查价流程技术可行性报告
|
||
|
||
## 1. 报告目的
|
||
评估当前已实现的双商城自动查价流程（1号药城、药帮忙）在技术上的可行性、稳定性与可维护性，并给出上线建议。
|
||
|
||
## 2. 结论摘要
|
||
- 结论：技术可行，已具备稳定运行条件，可投入日常使用。
|
||
- 现状：已完成双平台登录、接口抓取、字段映射、价格解密、异常兜底、结果导出与运行统计。
|
||
- 风险等级：中低（主要风险来自第三方页面结构和接口字段变更）。
|
||
|
||
## 3. 当前实现范围
|
||
- 输入：桌面采购模板 `【单独】采购单比价模板.xlsx`（按“批准文号”查询）。
|
||
- 平台顺序：固定为 `1号药城 -> 药帮忙`。
|
||
- 输出：桌面目录 `比价结果` 下 `查价结果_时间戳.xlsx`。
|
||
- 输出表头（固定顺序）：
|
||
- 通用名, 规格, 生产厂家, 批准文号, 采购数量, 采购价格, 商城, 平台名称, 平台规格, 平台价格, 效期, 商家, 库存, 库存说明
|
||
|
||
## 4. 技术方案与可行性分析
|
||
|
||
### 4.1 技术栈
|
||
- Python 3.12（`uv` 管理）
|
||
- `isa-rpa`：浏览器会话与密码箱读取
|
||
- `requests`：接口请求
|
||
- `pycryptodome`：1号药城价格 AES 解密
|
||
- `openpyxl`：Excel 读写
|
||
|
||
可行性判断：
|
||
- 均为成熟组件，生态稳定，维护成本低。
|
||
- 方案是“浏览器登录 + 接口抓取”的混合模式，较纯 UI 点击方案更稳定、速度更快。
|
||
|
||
### 4.2 登录与认证方案
|
||
- 1号药城：自动填账号密码，点击“开始验证”，登录后从 Cookie 提取 `token/userId/buyerCode`。
|
||
- 药帮忙：自动填账号密码，勾选“阅读并同意”，登录后复用 Cookie 进行接口查询。
|
||
- 凭据管理：使用 `SecretClient` 从密码箱读取，不在代码中硬编码明文凭据。
|
||
|
||
可行性判断：
|
||
- 认证链路已跑通，多次回归可复现。
|
||
- 密码箱方案满足凭据安全与后续轮换需求。
|
||
|
||
### 4.3 接口与字段映射方案
|
||
- 1号药城接口：`homeSearchList`
|
||
- 新增映射：`平台名称 <- shortName`，`平台规格 <- spec`
|
||
- 价格字段：`price` 支持解密后写入
|
||
- 药帮忙接口：`list-products`
|
||
- 新增映射：`平台名称 <- showName`，`平台规格 <- spec`
|
||
- 价格字段：优先 `price`，为空兜底 `fob`
|
||
- 无货规则：`availableQty=0` 时 `平台价格=0`，`采购价格`保留原始值，`库存说明=无货`
|
||
|
||
可行性判断：
|
||
- 字段来源明确、映射稳定，且包含业务兜底规则，能覆盖常见脏数据场景。
|
||
|
||
### 4.4 数据处理与输出方案
|
||
- 读取采购模板后按“批准文号”查询，空批准文号自动跳过。
|
||
- 对同一批准文号做查询缓存，减少重复请求。
|
||
- 输出时强制按目标表头重排，避免模板历史列顺序导致错位。
|
||
- 运行结束输出统计指标：
|
||
- 查询品种个数（批准文号去重）
|
||
- 获取价格行数
|
||
- 流程运行用时
|
||
|
||
可行性判断：
|
||
- 具备业务可用性与可审计性（统计输出可用于日常巡检）。
|
||
|
||
## 5. 已验证结果（最新回归）
|
||
- 运行命令：`uv run main.py`
|
||
- 实测结果（最新一次）：
|
||
- 采购模板有效条目：7
|
||
- 抓取总行数：216（1号药城 133，药帮忙 83）
|
||
- 查询品种个数：7
|
||
- 获取价格行数：216
|
||
- 流程运行用时：约 33 秒
|
||
- 最新结果文件：`查价结果_20260904_115656.xlsx`
|
||
|
||
可行性判断：
|
||
- 说明在当前网络和账号状态下可稳定产出完整结果。
|
||
|
||
## 6. 风险与应对
|
||
- 风险1：第三方站点登录页元素变更
|
||
- 应对：保留统一定位函数，定期做元素回归检查。
|
||
- 风险2：接口字段或鉴权参数调整
|
||
- 应对：对关键字段增加空值兜底，异常报错保留原始响应摘要。
|
||
- 风险3：价格密文规则变更（1号药城）
|
||
- 应对：将解密逻辑独立函数化，变更时可局部更新。
|
||
- 风险4：网络波动导致请求失败
|
||
- 应对：可追加重试机制（建议后续迭代增加）。
|
||
|
||
## 7. 上线建议
|
||
- 建议上线：是。
|
||
- 上线前建议完成：
|
||
- 增加接口请求失败的有限重试（如 2~3 次指数退避）。
|
||
- 固化一份“字段变更检查清单”（登录元素、接口字段、返回码）。
|
||
- 建立日常监控阈值（如抓取行数异常、无价格占比异常告警）。
|
||
|
||
## 8. 最终结论
|
||
基于当前实现与回归结果，该双商城查价流程在技术上可行、稳定性可接受、维护成本可控，满足当前业务使用条件。
|