|
|
cb7d06c20c
|
feat(wst): 数据源停更熔断——订单表停更时醒目标注，别把「没同步」当「没发货」
## 业务问题
10-28 18:00 轮页面核验出 546 单超时未发，业务核对「基本都发了，怎么会核验出未发」。
## 根因（不是判定写错，是数据源停更）
`jst_Orders` 当时**从 14:40 就停止同步了**（停了 4 小时），停更之后发出的单
`send_date` 一直是空，因此全被判成「未发货」：
| 来源表 | 超时单数 | 该表状态 |
|---|---|---|
| `jst_Orders` | 540 | 最后更新 14:40（停 4 小时） |
| `jst_qmcust_orderlist` | 6 | 17:30 正常 |
两个订单表**各自独立同步**，同一天完全可能一个正常一个停更。原来只拿候选行的
`MAX(updated_at)` 判快照滞后，会被「碰巧新」的行掩盖 —— 必须直接问源表。
## 改动
后端 `warehouseShipTimelinessService.js`：
- 新增 `loadSourceFreshness()`：分别直接查 `jst_Orders.MAX(updateTime)` 与
`jst_qmcust_orderlist.MAX(local_updated)`（限轮次窗口起 30 天，避免全表扫描），
两源并行；按 `CANGKU_WST_SOURCE_STALE_MINUTES`（默认 60 分钟）判停更
- 查询失败或取不到更新时间 → **不判停更**（宁可漏报，不谎报为停更）
- 明细行新增 `src` / `srcLabel` / `sourceStale`；`summary` 新增 `sourceStaleUnshipped`
- `freshness.stale` 改为「候选行滞后 **OR** 任一源停更」；`hint` 说清停更源、
停更时刻、以及各源各贡献多少单（不能只写「这张表」）
- 导出数据带 `dataSources`，Excel 脱离页面也有上下文
- 响应新增 `dataSources` 数组（每源 label / lastUpdate / lagMinutes / stale）
前端 `WarehouseShipTimeliness/index.jsx`：
- 红条 Alert：「N 单所在订单表已停止同步，这些单很可能已经发货」（error 级），
描述里逐源列出「最后同步 14:40:05（已 3.9 小时）」
- 超时统计卡下方小字：「其中 N 单数据未同步」（悬停有说明）
- 明细「内部单号」旁「未同步」红标签 + tooltip，一眼看出哪几行不可信
- 导出新增「数据源 / 数据源是否停更」两列（`是（该单可能已发）`）
## 验证
- 后端 `npm run check`：**494/496**，2 个失败是既有环境问题（负缓存 TTL 计时、
Windows 文件权限 0o600），改动前同样失败
- `warehouseShipTimeliness.test.js` **23/23** 通过（含新增「停更表超时单必须打标
并计入 sourceStaleUnshipped」用例）
- 本地真渲染（Playwright + 手签 token，localhost:5173）：
- 真数据：13:00 前 `notStarted` 正常展示「—」，无 pageerror
- mock 停更数据：红条 / 逐源行 / 统计小字 / 3 行「未同步」标签全部渲染，无 pageerror
- 真实接口 10-28 13:00 轮：`dataSources` 正确识别 `jst_Orders` 停更（滞后 96 分钟）
而 qmcust 正常；`sourceStaleUnshipped=1146` 与明细逐行打标同源同口径
## 风险与回退
- 只新增字段与展示，**不改动分轮、起算点、候选池口径** —— 超时单量本身不变
- 阈值可用 `CANGKU_WST_SOURCE_STALE_MINUTES` 调；不配默认 60 分钟
- 低峰期（凌晨）可能出现「1 小时无新单」被判停更，但页面只在 13:00 / 18:00
核验时刻展示超时数据，这两个时点 1 小时不同步即属异常
- 回退：revert 本提交即可，无数据迁移、无新表、无新依赖
|
2026-10-29 08:25:41 +08:00 |
|
|
|
983fee0d8a
|
fix(wst): 起算点改为「审核时间 / 订单 modified 取较晚者」，修 13:00 轮 65 单假超时
## 业务问题
业务举证：13:00 轮不该有那么多单 —— 「9 点前的单 13:00 前已经发完了」。
线上实测 65 单，逐单核对全部不该在 13:00 轮。
## 根因（两个，都指向「起算点取错」）
### ① 状态表的审核时间会严重滞后
业务给的举证单 9978643：
| 字段 | 值 |
|---|---|
| `qmcust.modified` | **2026-10-28 14:52:29** |
| 聚水潭页面真实审核时间 | **2026-10-28 14:52:28**（秒级吻合） |
| 状态表 `last_oa_confirm_time` | 2026-10-27 17:08:43（旧了一天） |
| 状态表 `query_time` | 2026-10-28 10:29:11（10:29 后没再抓） |
只信状态表 → 这单被当成「10-27 就审核了」，混进 13:00 轮超时，冤枉仓库。
### ② 审核时间为空的单回退 created，把今天的单按历史单算
65 单里 57 单状态表审核时间为 NULL。回退 `created` 后：
| o_id | created | modified | 回退后算成 | 真实 |
|---|---|---|---|---|
| 9964841 | 10-26 17:22 | **10-28 13:40** | 10-26 审核 → 进 13:00 轮 | 今天下午才审核 |
| 9949424 | 10-25 17:03 | **10-28 13:50** | 同上 | 同上 |
| 9983773 | 10-27 23:23 | **10-28 13:59** | 同上 | 同上 |
57 单的 `modified` 全部落在今天 13:40~15:03 —— 都是今天下午批量审核的。
## 改动
- **起算点** = `max(状态表 last_oa_confirm_time, 订单表 modified, 订单表 created)`
- 取较晚者：修状态表滞后
- 纳入 created：个别单 `modified` 早于 `created`（脏数据），起算点不该早于下单时刻
- `benchmarkSource` 透出 `oa_confirm` / `modified` / `created`，页面 tooltip 说明来源
- **新增 `laterOf()`**：同格式 `YYYY-MM-DD HH:mm:ss` 直接字典序比较，不转 Date（避开时区坑）
- **主查询 SQL 增加 `x.modified`** 列（订单两表都有，无需额外查询）
## 性能修复（同批，线上 /list 曾 300s 超时）
上版状态表查询**串行 9 批实测 135s**，叠加主查询 63~105s 直接把接口顶过 300s，
页面打不开（实测 curl `--max-time 300` 超时）。改为**并发 6**：
| 方式 | 耗时 |
|---|---|
| 串行 9 批 | 135s |
| 并发 3 | 28.8s |
| **并发 6（本版）** | **10~15s** |
并发 6 是生产实测的安全值（单批约 15s，不至于把 402 万行视图的连接池打爆）。
## 改后效果（10-28 17:00 真实库）
| 轮次 | 改前 | 改后 |
|---|---|---|
| 13:00 轮 | 65 单 | **0 单** |
| 18:00 轮 | — | 927 单（全部今天 07:59~16:00 审核，无历史单） |
- `fallbackToCreated` 从 57 → **0**（不再有回退单）
- 9978643 ✅ 已剔除
- 两个轮次都验证「今天窗口上界之后起算的 = 0」
## 验证
- 后端 `npm run check`：**493/495**（2 个失败是既有环境问题：TTL 计时、Windows 权限，改动前同样失败）
- 新增 2 个测试锁定该口径：
- `modified` 晚于窗口 → 必须剔除（9978643 那类单）
- 状态表审核时间晚于 `modified` → 以状态表为准
- `modified` 早于 `created` → 取 `created`，不倒退
- 前端 lint + build 通过（35.2s）
- 真实库双轮验证通过
## 风险与回退
- **`modified` 被客服改单/改备注刷新**时起算点会推后 → 少报超时（放行方向，不冤枉仓库）。
业务已知悉并接受；这是当前唯一能拿到「今天真实审核时间」的可靠字段。
- 回退方式：`git revert <merge commit>` 即回到只认状态表审核时间的版本。
|
2026-10-28 17:02:54 +08:00 |
|
|
|
e7e0b96b46
|
fix(wst): 起算点改回「最后审核时间」，并剔除订单表漏回写的已发单
业务 2026-10-28 下午拿 9837824 指出：页面「创建时间」显示 10-19 23:44，
而该单实际是 10-28 09:58:42 才审核。逐字段核对确认起算点口径错了 ——
上午那版按 jst_Orders.created 算，等于把客服审核积压算到仓库头上。
- 起算点 = 状态表 last_oa_confirm_time（业务选「最后审核时间」）；
取不到审核时间的单回退 created，页面 / 导出 / 钉钉该列打 *
- 已发判定补一条兜底：订单表 send_date 空、但状态表 send_time 有值的按已发剔除
（实测 144 单里 6 单属此类，且有揽收轨迹）
- 明细与导出列改为「审核时间 / 下单时间 / 发货时间」并列，去掉旧「创建时间」列
- 钉钉明细第五段由「创建」改回「审核」；抬头「核验 XX 前创建」改「前审核」
- 回归测试同步改断言；stub 增加审核时间查询分支（默认空 = 全量回退 created）
实测（10-28 13:00 轮）：599 → 144（按审核时间分轮）→ 138（剔除漏回写已发单）。
599 单里 376 单是当天 08:10~10:30 才批量审核的积压单，491 单其实已有运单号。
验收：后端 check 491/493（2 个失败为既有 Windows 权限 / TTL 用例，改动前同样失败）；
前端 eslint 通过、build 23.92s 通过；本地真渲染 138 单、表头含「审核时间 / 下单时间」、
回退单带 *、无 pageerror。
|
2026-10-28 15:34:29 +08:00 |
|
|
|
776a2cbde2
|
feat(wst): 发货时效改用订单两表 + 起算点改为订单创建时间
业务 2026-10-28 定版：「核验抓取的销售订单表是错误的，应该在数据库抓
jst_Orders（订单）+ jst_OrderItem（明细），审核时间就是 jst_Orders 里的创建时间」。
## 为什么换数据源（状态镜像表的硬伤，均有实测）
1. `send_time` 漏回写：近 7 天「状态表说发货中+未发」的 4157 单里，
订单表已有 `send_date` 的 563 单、status 已是 Sent 的 492 单 —— 发了还算超时。
2. 被合并 / 拆单父单不回写：89 + 755 单被冤枉。
3. 会整批停更：2026-10-27 11:54:59 之后 6.8 小时零写入，18:00 轮推出的
34 单里混着已发货的。
4. 两张表发货时间其实同源：27387 单逐条比对**零偏差** ⟹ 订单表才是权威。
## 改了什么
后端
- 主查询改打 `rpt.jst_Orders` + `rpt.jst_qmcust_orderlist`（店铺互斥，UNION ALL，
按 o_id 去重），SQL 侧过滤 `send_date IS NULL` + `status IN (Delivering/WaitConfirm/Question)`。
- 起算点由状态表 `last_oa_confirm_time` 改为订单表 `created`；
实测 created 100% 早于审核时间，正常单差 7~40 分钟，夜间下单次日审的单差 6~9 小时
—— 换口径后单量与「已等时长」都会变大，业务已知悉。
- 仓库归属：主查询只回 `wms_co_id`，Node 侧用仓表缓存换仓名再走 `resolveCenter()`
（实测 SQL 里 LEFT JOIN 仓表会把查询从 28s 拖到 61~105s）。
- `OPTION (RECOMPILE)` + 时间字面量：qmcust 不加 RECOMPILE 实测 33~50s，加上 0.4s。
- 删除 `backfillOrderFacts()` 与 `mapLimit()`（起算点/状态/仓名已由主查询一次取全）。
- 不再按 `is_split / is_merge` 过滤 —— 实测 `is_split=1` 恰是拆单**子单**
（同一 so_id 多行、各自要发货，近 30 天 1096 行），老逻辑 `is_split=0` 会把它们全排掉。
- 钉钉明细第 5 段「审核 HH:mm」→「创建 HH:mm」，无值文案「未审核」→「无创建时间」。
前端
- 明细/挂起清单/导出列「审核时间」→「创建时间」，Tooltip 与说明文案同步改写；
- 顶部说明补「数据源 = 订单两表」「已发未发取 send_date」；
- 「已支付待审核」统一为「待审核」（新数据源里就是 WaitConfirm）。
测试
- 两个测试文件的桩改成「订单两表 UNION」的返回形状，断言改为
created 起算、候选状态白名单、SQL 必须带 RECOMPILE / 不含状态镜像表 / 不 JOIN 仓表。
## 验证
- `npm --prefix backend run check`：491/493 通过。2 项失败是既有环境问题：
`resilientSecretStore`（Windows 文件权限 0o666≠0o600）、
`cloudDatabaseConfigCache` 负缓存 TTL（依赖隧道状态），均与本改动无关，单独跑同样失败。
- 前端 eslint + build 通过。
- 真实库：NOON 1553 单 / AFTERNOON 1866 单（本地 2026-10-28），
数据质量：无仓名 0 / 时间异常 0 / 含 undefined|null|NaN 0；
单次查询耗时 35~38s（30 天护栏，冷缓存）。
- 浏览器真渲染（playwright，强制 round=NOON）：
表头 `…发货时间 / 创建时间 / 付款时间…`、轮次提示「核验今天 07:00 前创建的订单」、
「导出明细」导出 CSV 表头含「创建时间」共 1551 行数据 + 1 行表头，无 pageerror。
## 风险与回退
- 口径变化是可感知的：单量上升，夜间下单/次日审核的单「已等时长」增加 6~9 小时，
属业务确认后的预期结果。
- 状态表「售后已作废」判据随换源放弃（实测在「发货中+未发」里只命中 4 单），
这类单现在按正常单算超时；如业务反馈，可单独补查。
- 回退：单文件回滚本提交即可，无数据迁移、无配置变更。
|
2026-10-28 11:34:45 +08:00 |
|
|
|
f749bcc03c
|
feat(wst): 超时未发加「导出明细」+ 武进安能不考核 + 钉钉明细带快递；修复推送时区
① 导出明细（业务要求：超时未发要能导出核对）
· 新增 GET /api/warehouse-ship-timeliness/export：不分页、不截断，返回本轮全部行
· 页面「超时未发货订单」卡片右上角加「导出明细」下拉（Excel / CSV）
· 选中某个仓时只导该仓（前端按 centerKey 过滤，与后端主仓归属同一套）
· 导出列比页面多「快递公司 / 运单号」（追单要看有没有打单），单号一律转字符串
避免 Excel 显示成科学计数法
② 缓存改成「存全量、出口截断」
· 缓存键去掉 limit（原为企业级教训：WLE 核验缓存早就这么改了）
· 页面 limit=1000、导出要全量，旧实现两边永不命中 → 每点一次导出重查一遍视图
· 实测：首次查询 86.3s，导出命中缓存 5ms
· 顺带修 detailTotal / heldTotal：明细被截断时页面仍显示真实总数，
不再把「只显示前 1000 条」写成「一共就这么点」
③ 不考核快递追加「武进安能」（业务 2026-10-27）
· 包含匹配，同时覆盖「武进安能大件」
· ⚠️ 严格不泛化成「安能」：实测库里带「安能」的有 8 个写法，
常州安能新 4207 单 / 安能物流 110 单等仍照旧考核（与
warehouseLogisticsExceptionRegistry 同一口径，那里也写着这句）
④ 钉钉推送明细行在「线上单号」后加「快递」
· 一行 = 仓｜内部单号｜线上单号｜快递｜审核 时间｜已等 X 小时
· 群里直接能判断是哪家快递、要不要走站点，不用回页面逐单点开
· 「已剔除 N 单不考核快递」的快递清单改成读服务层，别再各写一份
⑤ 修复推送任务时区（生产容器 /etc/timezone = Etc/UTC）
· 症状：pushShipTimelinessNotify 把裸 new Date() 传给 getShipTimeliness，
而 service / registry 内部用 getDate()/getHours() 直读 →
北京 13:05 = UTC 05:05，被判「未到 13:00 核验时间」→ 两轮推送永不触发
· 改法：rawNow（真实时刻，给 Intl / toISOString）+ bjNow（平移后，
给本地 getter 与 service 调用）双轨，与 2026-10-21 那次同源问题的修法一致
|
2026-10-27 16:29:08 +08:00 |
|
|
|
4e4f8890c1
|
fix(wst): 发货时效剔除「已作废」单 —— 问题单 / 发货前售后 / 售后已作废三条兜底
业务反馈 3 单（so_id 3655421011854634 / 3658479011191285 / 110215007857459363）
在聚水潭后台都已作废，却仍出现在「仓储中心 24 小时发货时效」的超时明细里。
根因：
- 页面只认状态表 jst_order_express_details，这三单 order_status_name 仍是「发货中」
+ send_time 为空；售后状态是「暂无售后」—— 上游没把作废同步过来；
- 现有的作废兜底只认订单表 status ∈ Merged/Split/Cancelled 以及 is_merge/is_split，
覆盖不到 status=Question（聚水潭后台显示「已作废/问题单」）和 labels 含「发货前售后」。
改动：
- registry 新增 VOID_QUESTION_STATUS='Question'、VOID_ORDER_LABEL_KEYWORDS=['发货前售后']、
AFTERSALE_VOID_STATUS='已作废'；
- 回订单表补事实时增投一个 `CASE WHEN labels LIKE N'%发货前售后%' THEN 1 ELSE 0 END`
布尔列（不传 labels 原文，避免宽列回表；实测冷查 42.6s，与改前同量级）；
- 状态表主查询增投一列 aftersale_status_name；
- 主循环在「发货中」分支之后判这三种作废证据，命中则并入 voidCount、不进考核。
⚠️ Question 不能直接塞进 VOID_ORDER_STATUS：那个数组在状态分类之前判定，
订单表 Question 的单有一大批在状态表是「异常」，会被从「异常待处理」清单里一起吞掉
（实测 heldCount 472 → 10，少掉 462 单）。故单独放在 SHIPPING_STATUS 之后判。
验证：
- 单测 19/19 通过（新增 38/39/40 三条作废形态用例，锁定 heldCount 不被影响）；
- 真实库 13:00 轮：超时 3 单 → 1 单（9823980 / 9880810 已剔除），
heldCount 保持 472，voidCount 4442 → 4444（恰好 +2）；
- 剩余 9889575 未剔除：订单表 Delivering、无出库单、无任何作废标记（见 PR 正文说明）。
风险与回退：
- 仅收紧「发货中」分支的作废判定，不回退任何既有判据；
- 若业务认为 Question 单仍需考核，改 VOID_QUESTION_STATUS 一处即可恢复。
|
2026-10-22 17:54:34 +08:00 |
|
|
|
f42f461430
|
fix: 仓储发货时效按北京时间取「今天」（生产容器是 UTC，每天 00:00~08:00 轮次错位）
问题（2026-10-21 生产实测，PR #69 上线后发现）：
- 生产容器 `/etc/timezone = Etc/UTC`、`date` = UTC；而 MSSQL `GETDATE()` 返回北京时间，
mssql 驱动 `useUTC:false` 把 DB 值构造成「墙钟当 UTC」的 Date ⇒ 比真实 now 快 8 小时。
- 于是**北京时间每天 00:00~08:00，服务端 `new Date()` 取到的「今天」是昨天**：
round.date / deadline / windowEnd 整体错位。
实测 08:04 跑 13:00 轮得 `overdueUnshipped=3895`（历史未发池被整段纳入），
而本地（东八区）同一轮只有 6 单。
修法（只动这一个模块，不动容器时区）：
- registry 新增 `beijingNow()`：把真实时刻平移成「本地 getter 读出来正好是北京时间」的 Date，
本机已是东八区时平移量为 0，行为不变。
- `resolveActiveRound` / `describeRounds` 的 now 默认值改为 `beijingNow()`；
service 的 `getShipTimeliness` 同样改用 `registry.beijingNow()`。
- ⚠️ 没改容器 TZ：`/opt/cangku/shared/backend.env` 里没有 TZ，改了会波及全部既有定时任务
（dailyRefresh / dailyInventorySnapshot 等都各自显式写了 Asia/Shanghai）。
测试：
- 新增 2 个用例（跨日 00:00~08:00 不取成前一天；默认按北京时间判定 13:00 前 notStarted）。
- `node --test backend/test/warehouseShipTimeliness.test.js` → 19 / 19 pass。
|
2026-10-21 08:17:52 +08:00 |
|
|
|
530d1ad27a
|
feat: 仓储中心发货时效独立页面 + 口径定版（审核时间分轮/快递剔除/停更告警）
一、前端：从 MkhBomData 侧栏抽成独立页面
- 新增 frontend/src/pages/WarehouseShipTimeliness/{index.jsx,style.css}，
路由 /planning/operation/warehouse-ship-timeliness，侧栏导航与 BasicLayout 各加 1 行入口。
- 删除 frontend/src/pages/MkhBomData/WarehouseShipTimelinessSidebar.jsx，
并把 MkhBomData/index.jsx、style.css 里相关代码与样式一并摘除（-131 / -277 行）。
二、业务口径（2026-10-20 业务多次纠偏后的定版）
- 轮次归属改用「审核时间」= jst_order_express_details.last_oa_confirm_time
（聚水潭订单列表「审核时间」列，最后一次审核，重审会刷新）：
13:00 轮 = 今天 07:00 前审核 + 历史未发；18:00 轮 = 截止 16:00 前审核 + 历史未发。
不再按「创建时间」切自然日窗口，也不再有「满 24 小时」门槛。
- 仓级例外（仅 18:00 轮）：山东青岗集仓 / 山东品牌仓 15:00 前审核、河南洛宁仓 13:00 前审核，
核验时刻仍为 18:00（registry 新增 windowEndHourByRound）。
- 明细去掉「创建时间」，改显示「发货时间」（send_time）；未发但有运单号的标「已打单 · 未揽收」。
三、已发判定与不考核快递
- 已发 = 状态表 send_time 非空 OR 订单表 status='Sent'（对齐聚水潭销售订单口径）。
不再用运单号反推（已发货与未揽收单都会出现运单号，判不出来）。
- 自提 / 中铁 / 壹米滴答 三家快递不做未发考核，剔除量计入 summary.carrierSkipped。
四、数据源停更必须让用户看见
- freshness 由写死 stale:false 改为实算：快照距今 >90 分钟 → 黄告警；
快照早于本轮核验时刻 → 红告警「数据未覆盖核验时刻，超时单量偏大」。
五、测试
- backend/test/warehouseShipTimeliness.test.js 扩到 17 用例（仓级例外、重审取 last_oa、
快递剔除、Sent 判已发、coversDeadline 告警）。
|
2026-10-21 07:52:02 +08:00 |
|
|
|
893f4d6aca
|
feat: 新增「仓储中心24小时发货时效」侧栏（11 个主仓 · 12:00/16:00 双轮核验）
需求（yanhui 2026-10-20）：在 MKH-BOM 列表左侧加一栏「仓储中心24小时发货时效」，
下列 11 个主仓（横林二仓、横林三仓、横林二仓品牌仓、崔桥工厂仓、崔桥工厂品牌仓、
崔桥工厂半成品仓、新苏北仓、睢宁仓、山东青岗集仓、山东品牌仓、河南洛宁仓），
从系统库存抓取已发货/未发货订单，按订单创建时间判定发货是否及时：
· 每天 12:00 核验「当天创建时间 7:00 之前」的订单是否已完成发货
· 每天 16:00 核验「当天创建时间 16:00 之前」的订单是否已完成发货
已确认的三条设计决策：
1. 子仓归属 → 连子仓一起算（京东云仓/自营仓/运营C专用仓/唯品仓等并入主仓）
2. 崔桥工厂半成品仓 → 系统无同名仓，先留空占位（不映射到配件仓 15718196）
3. 展示结构 → 只显示超时未发
实现要点
- 仓库归属用「关键词最长匹配」（不写死 wms_co_id），新增子仓只要名字含主仓关键词
就自动归入，缓存 1h。实测 28 个子仓全部正确归入 11 个主仓，132 个代发仓零误并。
- 12:00 之前**不做核验**：resolveActiveRound 返回 null，服务层直接返回 notStarted，
既不查订单表（接口 165ms）也不回填昨天的数据。前端显示「未到核验时间」+
「12:00 开始首轮核验（核验当日 07:00 前创建的订单）」，11 个仓结构保留、数字显示「—」。
- 订单取数：两张表店铺互斥（jst_Orders = 京东/拼多多/抖音/得物/唯品会，
jst_qmcust_orderlist = 天猫/淘宝/1688），并行分开查 + Node 侧按 o_id 去重合并，
用 Promise.allSettled 保证单表失败时另一表数据仍可用（detailDegraded 标记）。
- 三态判定 pending / shippedLate / onTime：send_date 与出库表 io_date 取先到的发货痕迹，
避免上游 send_date 回写滞后导致「已发的被判成没发」。
- 状态过滤：排除 Cancelled / Merged / **Split**（拆单父单永不发货，不排除会捞出一年前
1.3 万条历史单），Question 仍计入待发。
- freshness 字段如实报告出库表最新 io_date，前端「发货数据可能滞后」告警，
不拿一份可能滞后的数据去考核仓库。
排除的两次错误优化（均在代码注释里留了实测数据与复测脚本路径）
1. 用 created 替代 order_date 做窗口过滤（快 10 倍）—— 已证伪：2581 行里完全相等的只有 4 行，
差 >1h 的 412 行，198 行跨日；典型形态 order_date=10-18 23:58 而 created=10-19 04:00:08
（上游凌晨 4 点批量补录，created 是灌库时间不是下单时间）。业务口径是「订单创建时间」，
只有 order_date 正确。
2. 「UNION ALL 一条 SQL 慢 5~8 倍」—— 被后续实测推翻（46.3s vs 并行 48.2s，基本持平）。
验证
- 新增 backend/test/warehouseShipTimeliness.test.js，10 条用例全绿，覆盖：
最长匹配不误并、子仓命名、山东/河南高频前缀不误并、占位仓、12:00 前返回 null、
12:00 轮窗口 00:00~07:00、16:00 轮窗口 00:00~16:00、状态排除表、三态分桶互斥、
跨表重复 o_id 去重、round.windowEnd 必须带出（否则前端渲染成「核验 前」）。
- check-syntax 185 文件通过；全量 node --test 415 项 / 413 过 / 2 fail，
两条失败均为已知环境因素（负缓存带 TTL 因 .env 有 CLOUD_DB_* 短路；
resilientSecretStore 的 Windows 权限断言，基线恒失败）。
- 真渲染验收（组件级沙盒 + 真实接口数据）：两态均 0 控制台错误；
已核验态 358 单超时未发、8 个仓有数字、点仓切换选中/再点取消均正常；
多分辨率验证 1920/1600 侧栏 208px、1440/1366 收窄 176px、列表始终竖向。
|
2026-10-20 11:23:08 +08:00 |
|
