yanhui
cb7d06c20c
## 业务问题 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 本提交即可，无数据迁移、无新表、无新依赖
拼多多自动化运营平台
公开的拼多多业务精简版。欢迎所有人克隆、修改、分发代码并提交 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、密码、令牌、数据库备份或真实业务数据。