@
feat(trading): 详情页派送到真实样本，补结构化配送状态并修 stepper 回归 用真账号实测爬取订单详情页（scripts/probe_order_detail.py，样本落盘 .probe/order_detail/），首次拿到 pageType="ph-detail" 的真实 __INITIAL_STATE__， 此前「详情页结构从未有样本、只原样透传」的缺口由此闭合： - _parse_order_detail_status：新增，优先从 orderData.shippingList[].deliveryInfo .deliveryStatus 结构化枚举判配送阶段；映射遵循「只映射实测值」，目前仅 CHECKING_ORDER，未识别枚举交回 stepper 兜底（防掐掉 SHIPPED/DELIVERED 上报）。 - _ORDER_STEPPER_ITEM_PATTERN：修回归——不锚定 <li class="item--3gWCU"> 时面包屑 li 会抢走进度条第0项、导致 -active-- 永远判不出当前阶段（真实样本复现）。 - OrderStatusSnapshot 增 delivery_status 字段；query_runner order_detail 透传。 - docs/order-gateway.md §11 更新实测边界；新增详情页样本回溯测试。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> @
This commit is contained in:
+19
-6
@@ -435,18 +435,31 @@ queued ──lease──> leased ──result──> succeeded
|
||||
"kind": "order_detail",
|
||||
"order_number": "306087-20260813-0863947697",
|
||||
"found": true, // false 不是错误：站点自己说下单后要 ~10 分钟才反映
|
||||
"stage_label": "出荷", // 站点原文（已实测的配送阶段进度条）
|
||||
"stage_label": "出荷", // 站点原文（配送阶段）
|
||||
"order_state": "shipped", // 映射到 OrderState；映射不到为 null
|
||||
"delivery_status": "CHECKING_ORDER", // 站点结构化配送状态码；列表页/stepper 路径为 null
|
||||
"raw": { /* 页面 __INITIAL_STATE__ 原文 */ },
|
||||
"raw_available": true
|
||||
}
|
||||
```
|
||||
|
||||
> **实测边界（重要）**：`stage_label` / `order_state` 走的是 2026-08-13 用真实订单号
|
||||
> 验证过的进度条解析；但**详情页的 `__INITIAL_STATE__` 结构从未拿到真实样本**。
|
||||
> 因此本服务对它只做「解析得动就原样透传」，不抽任何字段——想要金额、收货地址、
|
||||
> 付款方式的调用方自己从 `raw` 里取并自担结构变动风险。等拿到真实样本后再在
|
||||
> `site_interact.py` 里补规范化解析，**不要在没有样本的情况下先猜着写**。
|
||||
> **实测边界（2026-08-16 更新）**：上次评估时「详情页 `__INITIAL_STATE__` 结构从未
|
||||
> 拿到真实样本」——**已用真账号真实爬过一次**（`scripts/probe_order_detail.py`，
|
||||
> 样本落盘 `.probe/order_detail/`，订单号 306087-20260813-0863947697）。确认：
|
||||
> - 详情页 `pageType="ph-detail"`，配送阶段有两处可解析信号：CSS 进度条
|
||||
> （`_parse_order_status`）**以及** `orderData.shippingList[].deliveryInfo.
|
||||
> deliveryStatus` 结构化枚举（`_parse_order_detail_status`，2026-08-16 新增）。
|
||||
> `stage_label` 优先取 `deliveryStatusTitle` 站点原文（如「ご注文確認中」）。
|
||||
> - 进度条解析修了一个此前未暴露的回归：不锚定 `<li class="item--3gWCU...">` 时，
|
||||
> 详情页的面包屑 `<li>` 会先于进度条第 0 项被 `findall` 抓走，导致带 `-active--`
|
||||
> 的当前阶段被错位跳过、永远判不出阶段（见 `_ORDER_STEPPER_ITEM_PATTERN` 注释）。
|
||||
> - `deliveryStatus` 的枚举→`OrderState` 映射**仍只实测过 `CHECKING_ORDER` 一个值**，
|
||||
> 未识别的枚举值一律不接管、交回 stepper 兜底（避免掐掉 monitor 的
|
||||
> SHIPPED/DELIVERED 上报）。`delivery_status` 字段把这个原始码原样带给上游对账。
|
||||
> - `raw` 仍原样透传，想要金额/收货地址/付款方式的调用方从 `raw.orderData` 自取
|
||||
> （2026-08-16 样本确认其结构：`orderSummary` / `itemObject.itemList[]` /
|
||||
> `shippingList[].deliveryInfo.deliveryAddress` / `paymentInfoModel` 等），
|
||||
> 本服务仍不自担字段抽取的去重/解释责任。
|
||||
|
||||
结果体积上限 `RAKUTEN_QUERY_RESULT_MAX_BYTES`：超限先丢 `raw_pages`/`raw` 并置
|
||||
`raw_omitted`；丢完仍超限则整单判失败，让上游缩小窗口重来——不把几 MB 页面状态
|
||||
|
||||
Reference in New Issue
Block a user