yanhui
983fee0d8a
## 业务问题
业务举证：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>` 即回到只认状态表审核时间的版本。
拼多多自动化运营平台
公开的拼多多业务精简版。欢迎所有人克隆、修改、分发代码并提交 Pull Request，代码按 MIT 许可证开放。
保留商品监控、仪表盘、激励看板、营销活动、推广、商品分析、工单以及在线客户端与执行任务等现有模块。部分菜单仍沿用原项目的占位页面。
已删除市场数据、店铺管理和运营工具整组页面、Claw 对话、skills 管理、平台切换与其他平台演示页，以及对应路由、页面资源、专属配置接口和权限项。首页为仪表盘。保留业务仍使用的模型配置、商品数据查询、桌面会话和自动上架公共服务继续可用；Claw 补全与图搜备用通道已经移除，缺失资料需使用业务接口或手工补充。
本地启动
需要 Node.js 22。团队开发机器无需安装或初始化 MySQL、Redis 及第三方数据库；使用管理员发放的部署 Key，一次注册后自动连接中央系统数据库、公网 TLS Redis 和第三方数据库。完整步骤及安全边界见 远程系统数据库部署。
npm --prefix backend ci
npm --prefix frontend ci
npm run remote:dev
首次启动时填写配置请求地址和部署 Key，系统自动写入被 Git 忽略的本机配置并重启后端。保存一次性显示的管理员账号和密码后直接登录，不需要在本地创建数据库或继续执行设置向导。前端默认访问 http://localhost:5173，API 默认代理到本地后端。
拉取主仓库更新后必须停止旧的 npm run remote:dev 进程并重新启动，保证前后端使用同一版本。MKH 页的强制刷新带有版本协议校验；如果新前端仍代理到未重启的旧后端，页面会停止展示可能过期的库存并明确提示重启，不再将旧值冒充为“最新数据”。
验证与构建
npm --prefix backend run check
npm --prefix frontend run check
前端构建输出位于 frontend/dist。部署时需为单页应用配置路由回退，并代理 /api 与 /cubejs-api 到后端。
启动时会迁移旧侧栏配置，并删除已退役页面的权限、专属设置和专用数据表。上架测算旧偏好表中的商品分析阈值会先迁移到商品分析专用表；其他保留模块的数据不受影响。迁移仅作用于实际配置给此实例的系统数据库。
参与修改
开始开发前请阅读 仓库提交与合并规范（多用户与 AI 开发必读）。准备更新生产服务器时必须继续阅读 服务器部署规范（开发者与 AI 必读）。AI 工具的规则入口为 AGENTS.md。每个任务使用独立目录和分支，通过 PR、同步验证和独立审核合并，禁止强推或覆盖其他开发者的工作。
所有用户均可 Fork 仓库、创建分支并提交 Pull Request。直接推送本仓库需要仓库所有者授予协作者写权限。提交时请说明修改和验证结果，勿提交 .env、密码、令牌、数据库备份或真实业务数据。