dachui/order_site
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
1,047 Commits 3 Branches 0 Tags
06d888fb6f1319c1a96413bc4e894c019d451aa2
Commit Graph
650 Commits
Author SHA1 Message Date
yml2213 f3f2550b19 feat(admin): 彻底优化任务列表与详情界面，集成到账存证凭单与联盟直充面板 
- 优化任务列表角色列：支持从 affiliateDash 及 claimIdentity 中自动提取并展示角色名与 UID（含一键复制）
- 列表操作栏支持一键查看到账存证凭单，支持直接复制图片发给买家或下载保存
- 任务详情页全面现代化重构：
  - 新增「兑换成功 · 官方直充到账存证凭据」大卡片，实时生成 640x960 Retina 高清卡片，支持一键写入系统剪贴板（微信/QQ/客服窗口直接 Ctrl+V 发送）、下载 PNG 大图与全屏预览
  - 新增「联盟直充履约 (affiliate_dash)」专属面板，结构化展示上游订单号、直充状态、点数积分、核销状态及供应商回执
  - 优化凭据生成器 (voucher.ts)：强制优先读取本地高清商品图，彻底消除上游图片文字水印与圆环破图问题
- 验证方式：npm run build & npm test (133 项单测全量通过)
 2026-10-10 21:04:01 +08:00
yml2213 215f3351ba fix(claim): 优化H5领取与绑定界面商品图展示并集成发货存证凭据生成 
- 修复后端 affiliate_dash 领取详情接口漏传 imageUrl 字段的问题
- 优化前端 ClaimProductImage 占位逻辑，消除无图或失败时的空灰色方块
- 移植并集成 affiliate_dash 前端 Canvas 高清发货到账存证凭据（Retina 640x960）
- 在兑换成功页面提供结果图预览、一键复制到剪贴板与下载凭据图片功能
 2026-10-10 20:55:02 +08:00
yml2213 c54dbda344 feat(douyin-mashida): 全面统一为 /h5/<订单号> 直充路径，更新面板提示与直发链接生成 
- 抖音码速达买家直充链接与兜底配置基址统一改为 https://<域名>/h5（直充路径为 /h5/<订单号>）
- 前端配置面板示例与提示升级为真实 16 位平台订单号形态（如 /h5/2628301923197355）
- 一键填入域名同步适配 /h5 基址，并在后端发券与发货私信推送中直接生成 /h5/<订单号>
- 数据库本地配置同步更新为 http://localhost/h5

验证方式：前端类型检查与打包构建通过，全量 132 项前端单测与 674 项后端单测全部通过
 2026-10-10 20:10:09 +08:00
yml2213 d8ce40e346 feat(douyin-mashida): 彻底重构优化配置面板，支持一键填域名/订阅推送/网关自检并剔除冗余字段 
- 剔除历史旧卡券时代废弃的 afterVerifyLink（去使用链接）与 afterVerifyMessage（通知正文）
- 面板新增一键填入当前域名、向开放平台一键订阅推送、停用推送以及网关连通与签名自检功能
- 业务配置重构为「基础接入与商户凭据」、「买家 H5 直充与发货私信」、「高级网关设置」三层清晰结构
- 后端与前端服务新增 /douyin-mashida/subscribe 与 /douyin-mashida/test-gateway 统一接口

验证方式：前端类型检查与打包构建通过，全量 132 项前端单测与 674 项后端单测全部通过
 2026-10-10 20:05:46 +08:00
yml2213 748c18bc7d feat(order): 精准区分自动直发与接单平台打手履约，智能门控H5直充按钮 
- 后端增加按订单批量关联接单工单查询，精准识别履约类型（自动直发 / 打手履约 / 电子凭证 / 拼多多发货）
- 订单列表与详情页中，仅当订单为自动直发（affiliate_dash / 码速达直充）时展示【H5】一键复制直充链接与兑换状态控制
- 接单平台工单单与纯核销单隐藏直充 H5 按钮与兑换暂停/关闭标签，防止客服向打手单买家误发直充链接
- 交付模式标签升级为「⚡ 自动直发」、「👥 打手履约」、「🎫 电子凭证」、「📦 拼多多发货」

验证方式：前端类型检查与打包构建通过，全量 132 项前端单测与 674 项后端单测全部通过
 2026-10-10 19:44:20 +08:00
yml2213 122144a2b7 feat(task): 任务详情与列表页增加H5订单号领取链接及兑换有效性控制 
- 后端 AdminTaskDetail 视图补充关联订单的 claimStatus、claimStatusReason 等状态字段
- 任务详情页升级“领取链接”卡片：支持固定 H5 链接展示、状态标签（有效/暂停/关闭），并支持一键复制及【暂停/关闭/恢复启用】弹窗操作
- 任务详情页保留历史 Token 链接作为辅助对比展示
- 任务列表页在平台订单号旁增加一键复制 H5 领取链接的快捷按钮
- 验证方式：前后端类型检查、全量单元测试（后端 674、前端 132）及前后端全量构建均通过
 2026-10-10 18:38:49 +08:00
yml2213 412d219cca feat(claim): 支持固定H5订单号领取与订单兑换有效性后台控制 
- 数据库新增 099_order_claim_status.sql 迁移，扩展 claim_status、claim_status_reason 等字段
- 后端新增 /claims/h5/:orderNo、UID提交、分销提交接口，保留原有 token 接口双轨兼容
- 增加兑换有效性强拦截：暂停/关闭/退款/取消订单精准阻断并返回友好提示
- 后台新增 POST /admin/orders/:orderId/claim-status 接口与审计日志记录
- 前端管理后台（订单列表、详情页）支持 H5 兑换状态展示、一键复制链接及暂停/关闭/启用弹窗
- 前端领取页面适配 /h5/:orderNo 路由及暂停/关闭等状态的异常展示
- 验证方式：运行前后端类型检查、全量单元测试（后端 674、前端 132）及全量构建编译均通过
 2026-10-10 18:05:46 +08:00
yml2213 2d727a6797 fix(worker-platform): 修复对已冻结打手调级时误报冻结原因必填的问题 
- 做了什么：
  1. 后端 reviewAdminWorkerUser 中优化 freezeReason 校验条件：区分是否为新变为 rejected 状态，若账号原本已处于冻结态且本次仅调整等级未变动状态，直接沿用已有冻结原因，不再强制要求传 freezeReason；
  2. 前端 submitLevel 在提交调级时补充传递打手既有的 freezeReason；
  3. 后端新增对应测试用例确保后续回归。
- 为什么：
  当打手处于冻结状态（rejected）时，管理员对其执行调级操作因未携带 freezeReason 触发了冻结原因校验错误，导致调级失败。
- 验证方式：
  运行 npm run check（671 项测试全绿，类型与构建检查通过）。
 2026-10-10 13:51:58 +08:00
yml2213 85fc2eaa7c feat(worker-platform): 支持后台人工调级锁定等级与解除自动升级限制 
- 做了什么：
  1. 新增数据库迁移 098_worker_level_lock.sql，在 worker_users 表增加 is_level_locked、level_locked_at、level_locked_reason、level_locked_by 字段；
  2. 后端自动升级函数 maybeUpgradeWorkerLevelWithClient 和判定函数 shouldApplyAutomaticWorkerLevel 增加 is_level_locked 守卫，被锁定的打手跳过自动升级；
  3. 后台打手审核调级服务 reviewAdminWorkerUser 支持等级锁定参数与变更记录，人工调级时自动写入 worker_level_logs 流水，并提供 updateAdminWorkerLevelLock 专用接口；
  4. 前端打手列表等级列展示「已锁定」状态及 Tooltip 原因，调级弹窗支持「锁定自动升级」开关与原因输入，操作列提供「解除限制」快捷操作；
  5. 打手详情抽屉补充展示等级锁定说明。
- 为什么：
  解决打手被人工调整等级（如 VIP5 调至 VIP4）后，因历史累计完成单数满足门槛导致后续结算再次自动升级回高等级的问题，并支持后续随时解除限制恢复自动升级。
- 验证方式：
  1. 后端新增 shouldApplyAutomaticWorkerLevel 与 mapWorkerUser 单元测试，运行 npm run check（670 测试全过，类型与 SQL guard 验证通过）；
  2. 前端新增 worker-level-lock.test.ts 单元测试，运行 npm run check（130 测试全过，typecheck 与 build 验证通过）。
 2026-10-10 13:44:57 +08:00
yml2213 4fce07a621 refactor(douyin-mashida)!: 纠偏——删掉自建的皮肤通道，改回复用 affiliate_dash 
上一轮我把皮肤交付做成了「另建一套执行器 + 独立领取接口 + 只提交账号就结束」，
跟买家实际要走的过程不一致（真正的完成信号是「扫码绑定后的 UID == 买家填的 UID」），
而且核销还触发了老通知逻辑，给买家**又发了一条 /redeem** —— 买家收到两条链接。
本次按用户要求改回**完全复用仓库现成的 affiliate_dash 通道**（= 旧的快手皮肤自动发货）。

**删掉**
- 执行器 `douyin_mashida_skin`（含 registry/types/planner/bootstrap/路由白名单注册）
- `services/claim/claim-skin-service.ts`、`routes/claim-skin.ts`、`/api/v1/claim-skin` 挂载
- 迁移 096 的 `claim_submission_json` 全链路（task-repo / rows / inputs / task-detail /
  admin-read-service 的 claimSubmission），并新增 **097 兜底迁移**把该列 DROP 掉
- 顺带清掉上一轮专为已删接口加的死代码（utils/http.ts 的 buildMessageSuccessPayload 等）

**改回复用**
- `resolveOrderItemClaimLink`：通用解析（只看订单项、不看执行器）→
  `buildConfiguredClaimUrl(claimLinkBase, token)`；多履约单元取 task id 最小并告警；
  **绝不回退** hash 形态的 `buildClaimUrl`
- `cert_link` 与付款后那条**唯一**消息共用同一个解析结果
- **核销后不再给抖音买家发第二条消息**（`shouldNotifyBuyerAfterVerify` 只放行非抖音 provider）
- 买家侧走既有流程：输 UID → 二维码 → 扫码绑定 → 比对 UID → delivered/REDEEMED；
  在 delivered 分支 best-effort 核销平台券（幂等、失败只 warn，不拖慢买家响应）
- 后台回显链接改按 **order.provider** 判断（抖音用 `claimLinkBase`）

**SQL 守卫**：允许「删除历史迁移」，但强制要求「同时新增兜底迁移」配对
（修改历史迁移仍禁止），并把改动来源换成 `git status --porcelain`（否则未跟踪的新迁移看不见）

`npm run check`：tests 671 / pass 668 / fail 0 / skipped 3（含新增的物品图回退用例）
 2026-10-09 16:13:39 +08:00
yml2213 56ad06239b fix(fulfillment): 抖音未命中皮肤映射时显式回落人工，避免静默漏单 
原本未命中的抖音订单项只靠全局 `unmatchedExecutorKey` 兜底，而线上/联调环境该值
可能是空串（dev 库实测就是 `unmatchedExecutorKey=''`）——那种配置下未命中的抖音订单
既不建履约任务、也不进人工，等于**静默漏单**（需求要求的是「接单平台走人工」）。

改为在抖音分支里显式指定回落：命中权威映射 → `douyin_mashida_skin`；
未命中 → 直接以 `preferredExecutorKey=manual_dispatch` 选中人工通道，不依赖全局配置。

实测（dev 真实配置，`unmatchedExecutorKey` 为空串）：
  幸运币2个 / 套装-浪漫天命   → douyin_mashida_skin（isConfigured=true）
  代练上分-星耀到王者（未命中）→ manual_dispatch（isConfigured=true）
  空 SKU                      → manual_dispatch
  对照 91卡券/快手             → 行为不变（未配映射仍 isConfigured=false）
 2026-10-09 15:09:58 +08:00
yml2213 b70741daec feat(admin): 后台可配领取链接/发消息模板 + 可见买家账号 + 修正皮肤领取链接 
**面板新增三项（抖音码速达接入配置）**
- 领取链接基址 (claimLinkBase)：带实时预览「皮肤订单最终链接」，并拦截两类误配 ——
  带 `#`（`#/claim` 是打手领取页，会把买家带进绑定 UID 流程）、缺 http(s) 协议
- 发消息模板 (messageTemplate)：提示可用占位符；模板里没有 `{link}` 直接报错提示
- 付款后发领取消息开关 (claimMessageEnabled)
- 顺带把默认出网超时的展示值对齐后端（10s → 20s）

**后台可见买家提交的账号（运营发货依据）**
- `getAdminTaskDetail` 新增 `claimSubmission`，按 `canViewSensitiveTaskData` 门禁下发
  （与 claimToken 明文同一门禁）；任务详情新增「买家提交信息」卡片（可一键复制账号）

**修正：皮肤任务的领取链接**
- 详情接口原来用全局 `buildClaimUrl`（默认 hash 形式 `…/#/claim/…`），那是**打手**领取页；
  皮肤任务改用 `claimLinkBase + '/' + token`，运营复制给买家的链接才是买家页
- 顺带把「履约渠道」筛选项加上「皮肤自动发货」、任务详情执行器标签加上它、
  「来源渠道」加上「抖音码速达」（此前筛不出来抖音订单）
 2026-10-09 15:06:49 +08:00
yml2213 56a8184576 feat(douyin-mashida): 皮肤自动发货（按内部 SKU 分流 + 领取链接 + 买家领取接口） 
抖音码速达的皮肤类商品改为「自动发货 + 领取链接」：买家不用输订单号，点链接直接领。

**分流（按内部 SKU）**
- 平台闸门放行 `provider='douyin_mashida' && platform='doudian'`，走**独立分支**
  （原有 91/快手路径一行未动，避免外溢）
- 判据：内部 SKU（`sku_order_list[].code`，即 order_items.sku_code）命中权威表
  `AFFILIATE_DASH_SKU_MAPPING` → 新执行器 `douyin_mashida_skin`；未命中 → `manual_dispatch`
- 皮肤判定与商品图同源（都用那张权威表），保证「能路由 ⇒ 有图」
- 履约路由新增 `internal_sku` 匹配维度（`rules[].internalSku`，NFKC+去空白+小写，exact/contains）；
  旧规则缺 `matchField` 时默认 `product_name`，**归一化/优先级/回退顺序完全不变**

**执行器与领取 token**
- 新增 `douyin-mashida-skin-executor`：建 claim token、置 `link_generated/pending_claim`，
  `resolveDeliveryLink` 返回本站路径式领取链接；注册进 registry、planner 分支、
  bootstrap 种子 profile（`抖音皮肤自动发货`）；进 `ROUTABLE_EXECUTOR_KEYS`
- token 粒度 = 一个履约单元一个（`claim_tokens.task_id` 唯一）；一单多项时
  cert_link/买家消息取 task id 最小的那个并告警

**cert_link 与发消息**
- 皮肤订单且该订单项已有 token 且配了 `claimLinkBase` → `cert_link = claimLinkBase/token`；
  其它情况一律用 `certLink`（老行为不变）
- 领取链接**只认** `claimLinkBase`，绝不回退 `buildClaimUrl`/`orders.claimBaseUrl`
  （那是 hash 形式的打手领取页，语义不同）
- 付款建单+发券成功后按 `messageTemplate`（`{link}/{sku}/{orderNo}/{productTitle}`）
  经 `order.message` 发给买家；best-effort，失败只记 warn

**买家领取接口**
- `GET/POST /api/v1/claim-skin/:token`（限流、公开）；详情含内部SKU/引流标题/商品图/
  数量/金额/支付时间/动态表单字段；token 失效给明确 errorCode（404/410/409），不打 500
- 提交账号：先核销平台券再落记录（避免「记账了但券没核销」的资损），已提交幂等

**隐私**
- 买家游戏账号落 `fulfillment_tasks.claim_submission_json`（迁移 096），
  **不进** `work_orders.material_json`（那是发给打手的素材）；详情接口不返回券码明文/手机号/地址/open_id
 2026-10-09 15:06:43 +08:00
yml2213 ecc8ffaee4 fix(douyin-mashida): 出网响应按大整数安全解析（product_id 被压精度） 
真实联调发现：抖店大量 id 是 19 位数字，超过 Number.MAX_SAFE_INTEGER，
入站推送我们用 express.text() 收原文保住了精度，但**出网响应是 JSON.parse 出来的**，
19 位数字在解析瞬间就被压成相邻 double：

  平台真值 product_id = 3847255376114352567
  我们存到的          = 3847255376114352600

后果：拿这个 product_id 去调 product.detail 报「商品不存在」（实测），
任何按商品ID做的映射/查询都会错。

修复：抖音出网响应改用共享的 parseJsonObject(..., { preserveLargeIntegers: true })。
utils/json.ts 里其实早有 wrapLargeIntegerLiterals（≥16 位/超 MAX_SAFE_INTEGER 才包裹，
只处理值位置的整数字面量，不误伤字符串内数字与短数字），但全仓没有调用方 —— 现在接上。

实测：同一笔订单 product_id 已精确为 …567，product.detail 返回 code=10000 并拿到商品图。
补了 json 解析的大整数单测（含「字符串里的数字、短数字不受影响」的反例）。
 2026-10-09 14:47:55 +08:00
yml2213 0b619b2915 feat(asset): 商品图资源 + 内部 SKU → 图片解析 
买家领取页要展示「待领取物品图片」，图片按 affiliate_dash 的英文 sku 命名
（如 lucky_coin_x2.webp = 内部 SKU「幸运币2个」），从 affiliate_dash 项目
复制 38 个 slug（40 个文件，其中 2 个 slug 同时有 png/webp）到前端 publicDir
`apps/frontend/public/images/products/`，由 Vite 原样对外（不进 bundle）。

新增 `services/platforms/affiliate-dash/product-image.ts`：
内部 SKU →（复用权威映射表 AFFILIATE_DASH_SKU_MAPPING）→ 英文 sku → 图片 URL。
映射不到返回空串，由前端展示占位图（不猜、不拼不存在的文件）；
以后图片挪 CDN 只改这一处。

测试含「映射表每个 sku 都必须有对应图片文件」的守卫，防止新增商品漏图。
 2026-10-09 14:47:50 +08:00
yml2213 de2fb3e008 fix(douyin-mashida): 平台会改写券码 —— 核销改用平台侧券码 + 失败自愈 
真实联调踩到的坑（已用真单复现并定位）：
`coupons.syncV2` 返回 `10000 成功` **并不代表平台沿用了我们提交的 cert_no**。
实测 3 笔订单里有 2 笔，平台把我们的 DYC 券码换成了它自己生成的券码。
我们却一直拿**自己的**券码去 `coupons.verifyV3`，平台回
`10017 卡券核销失败[isv.business-failed:010021|核销码与订单不匹配]`；
更坑的是这个错误平台要 **~10.5 秒**才返回，正好越过当时的 10 秒超时，
前端只看到 `douyin_mashida_gateway_timeout`，完全看不出真实原因。

修复：
- 新增 `coupons.list` 出网封装；同步成功后按 order_id 回查平台侧 `cert_no`/`cert_id`
  并落库（迁移 095 新增 platform_cert_no / platform_cert_id / platform_status / platform_synced_at）
- 核销时用 `resolveRedeemVerifyCertNo()`：**平台侧券码优先**，取不到才退回我方券码
- 核销失败后自愈 `tryRecoverVerify()`：
  ① 回查平台，若平台侧已核销 → 按对账结果标记本地已核销（修复"平台已核销、我们报失败"的漂移）
  ② 若是券码被平台改过 → 用平台券码**重试一次**
- 回查不到该订单的券 → 标记 sync 失败并告警（暴露"syncV2 成功但平台无券"的幽灵券）
- 默认出网超时 10s → 20s（平台业务错误要 ~10.5s 才返回，10s 会把业务错误伪装成超时）

实测验证：对一笔「平台侧已核销、本地仍是 synced」的订单调确认兑换，
10.7s 后返回 `status=verified`，platform_cert_no 成功回填为平台券码、
platform_status=3，并打出「对账发现平台侧已核销，按平台状态标记本地已核销」告警。
 2026-10-09 14:08:55 +08:00
yml2213 7834ee7bef feat(douyin-mashida): 商品展示统一改为内部 SKU（引流标题降级） 
平台 sku_order_list[].code 是商家维护的**内部 SKU**（如「幸运币2个」），
product_name 只是店铺用来**引流**的长标题（如「【测试专用】和平精英皮肤小店入口…」）。
商家按内部 SKU 认货（后续履约匹配也用它），原来的展示把引流标题当商品名，
列表/详情/兑换页三处都会让人认错货。

改为以内部 SKU 为主、引流标题降级为副信息：
- 后台订单列表「商品 / 任务」：itemTitle = 内部 SKU，skuNick = 引流标题
- 后台订单详情「商品明细」：商品 = 内部 SKU；SKU/规格 不再重复展示同一串
- 兑换中心 /redeem：商品 = 内部 SKU（粗体）+ 引流标题（灰色小字，新增 productTitle 字段）

实现只在 `source === 'douyin_mashida'` 时生效（resolveOrderItemTitle /
resolveOrderItemSkuNick 加 douyin 分支），其它平台展示逻辑不变；
用真实订单形态补了单测。
 2026-10-09 13:31:45 +08:00
yml2213 064267ad86 fix(douyin-mashida): pay_time 兼容平台实际返回的字符串格式 
真实联调发现：`order.orderDetail` 返回的 `pay_time` 是格式化字符串
`"2026-10-09 12:28:02"`（北京时间），而文档写的是秒级 Integer，
消息推送里的 `pay_time` 又确实是 Integer —— 两种形态并存。

原实现只走 `parseEpochSecondsIso`，对字符串 `Number("2026-10-09 12:28:02")` = NaN，
会把真实支付时间丢掉、退化成"收到时间"。

改为 `parseDouyinMashidaTimeIso`：纯数字按秒级时间戳，`YYYY-MM-DD HH:mm:ss`（含 T）
按 +08:00 解析；平台用 `1970-01-01 08:00:00`（epoch 0）表示"无"，返回空串。
用真实 orderDetail 响应反例补了单测（含 19 位订单号 + 子单号等于父单号）。
 2026-10-09 12:43:24 +08:00
yml2213 72606796b3 feat(douyin-mashida): 抖音码速达最小接入后端（消息建单/券码同步/兑换核销/退款作废） 
- 签名：出网 md5(secret+Σ(名+值)+secret) 与推送 md5(secret+data+pub_time+topic+secret)
  两套独立实现，含文档 golden 向量单测（与 91 大写 / affiliate_dash HMAC 都不通用）
- 进单：trade_TradePaid 推送 → 验签 → webhook_events 幂等 → order.orderDetail
  → upsertOrderFromSource（provider=douyin_mashida / platform=doudian）
- 精度：19 位订单号超出 JS 安全整数，JSON.parse 会把 p_id 抹成 ...000；
  故解析后从原始 JSON 文本用正则抓回精确数字（单测同时证明"不修会错"）
- 券码：迁移 094 redeem_certificates（(provider,order_id) 唯一做发券幂等）
  + DYC 券码生成 + coupons.syncV2 同步（子单号优先、父单兜底）
- 兑换：POST /api/v1/redeem/lookup|confirm，按 orderNo+IP 限流；
  核销成功后 order.message 通知买家（best-effort，失败只记错误日志）
- 退款/取消：作废未核销券；券已核销时打 WARN 资损告警（已消费不可回滚）
- 后台：GET/POST /api/v1/admin/platform-config/douyin-mashida，
  secret 出参置空 + 掩码，掩码回写不覆盖原值
- 消息路由挂在全局 body parser 之前（app.ts），验签必须用 body 原始字符串
 2026-10-09 12:00:50 +08:00
yml2213 893388b37f feat(consignment): 寄售仓库在库列表增加通过审核入库时间并在手动匹配中补全时间展示 
- 寄售仓库 (ConsignmentInventoryPanel)：表格中增加「通过审核入库时间」列并格式化展示，详情弹窗规范化展示入库时间、出库时间与提报时间
- 手动匹配弹窗 (ConsignmentManualMatchModal)：候选订单列表展示工单创建时间，顶部横幅与已选概要展示现货入库时间及订单创建时间；从订单匹配现货时展示现货入库时间
- 内部匹配接口与工单拦截：后端 listInventoryMatchableOrders 返回工单创建时间及平台单号；发布拦截弹窗中增加展示现货入库时间
- 验证方式：运行前后端单元测试全部通过，前端 build 校验通过
 2026-10-08 15:41:23 +08:00
yml2213 98dc675b88 Revert "feat(claim): Rock 同一提货号过期后自动换新二维码" 
This reverts commit 9d981c253f.
 2026-10-06 18:08:20 +08:00
yml2213andCursor 9d981c253f feat(claim): Rock 同一提货号过期后自动换新二维码 
腾讯活动链接会过期，领取页不能一直用第一次的签名。过期后向 0666 重取同一提取码的新链接，不另发提货号。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-10-06 18:02:17 +08:00
yml2213andCursor f6e6d110a8 style(claim): 格式化领取页绑定状态刷新 
Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-10-06 17:47:31 +08:00
yml2213andCursor f6343e58c1 fix(claim): 后台改对扫码 UID 后领取页跟上，绑定失败仍记住扫到的号 
Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-10-06 17:47:01 +08:00
yml2213 2a0eea40e9 feat(claim): 配合方案B支持买家纠错扫码UID自愈绑定，自建页面增加确认更换提示与快捷填入 2026-10-06 11:12:18 +08:00
yml2213 af6dc27017 feat(sku): 新增 Rock 平台「黑色ROCK长袖T恤」与「蓝色运动服上衣」SKU 映射 
1. 在 AFFILIATE_DASH_SKU_MAPPING 中新增黑色ROCK长袖T恤 (rock_black_tshirt) 与蓝色运动服上衣 (rock_blue_sportswear) 权威映射；
2. 兼容常见别名「黑色ROCK长袖」与「蓝色运动服」，确保电商出单时自动准确路由至 affiliate-dash 进行 0666.pro 全自动发货履约。
 2026-10-05 19:25:24 +08:00
yml2213andCursor 250c456a46 fix(consignment): 内部库存履约后不再把买家资料暴露给上一手打手 
退回大厅留下的 last_assigned 在状态离开待接单后会重新可见。履约时摘掉上一手，并清掉已经漏出的内部现货工单。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-10-05 19:18:43 +08:00
yml2213andCursor eae78aae34 fix(consignment): 退库后不再带出上一单买家资料，撤单清掉上一手验收痕迹 
现货退回仓库后只留卖家提报，不再挂买家角色、赠送凭证和店铺；工单撤单、退回、抢单时清掉验收与备注，买家下单资料仍保留。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-10-05 14:55:42 +08:00
yml2213andCursor dbdafd3dc4 fix(consignment): 撤销寄售履约按选择回库，不再因加好友强制作废扣押金 
买家退款时应能把现货退回仓库继续匹配；卖家押金只在客服显式选择扣除时才没收。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-10-05 14:28:38 +08:00
yml2213 30ae35d3a5 fix(consignment): 撤销寄售履约回库分支必 500 —— SQL 参数比占位符多一个 
线上客服 kf_13 撤销 WO26092609475746 时返回 500 internal_error，
真实库报：bind message supplies 5 parameters, but prepared statement "" requires 4。

根因：解绑现货的两条分支共用一个 5 元参数数组，但回库/取消分支的 SQL 只用到
$1..$4（第 5 个「备注前缀」只有作废分支才用）。于是运营只要选
「退单回库并恢复工单为未指派」或「退单回库并取消工单」就必定 500，
而假 client 的单测与类型检查都看不到这类错。

修复：
- 解绑 SQL 与参数抽到 consignment-revoke-inventory-sql.ts 一起构造，
  回库/取消分支只传 4 个参数，作废分支才多带备注前缀（$5）；
- 单测锁定「占位符个数 == 参数个数」，覆盖 reopen / archive_inventory /
  已确认加好友自动作废三条分支；
- db 层加参数个数自检（db/sql-arity.ts + db/client.ts）：参数比占位符多时
  提前抛出带 SQL 片段的错误，不再让 pg 的 bind 报错裸奔，
  并跳过字符串/注释/dollar-quote 里的 $n，避免误杀。

验证：本地影子库端到端跑通三条分支（工单 100140 + 现货 INV26091917439822），
并复现修复前的 bind 报错；全量单测 588 通过，typecheck/lint/build 均通过。
 2026-10-03 16:03:14 +08:00
yml2213 69e3d9a396 perf(worker): 「我的订单」缓存改为事件驱动失效，TTL 2s/5s → 30s 
这是当前最大瓶颈的根治：打手端三件套（列表/计数/概览）占全库约 75% 缓冲读，
单查询成本是 O(打手单量) 的固有成本（重打手 8,586 单逐行探测），
索引层面已无可抠，只能把"计算次数"和"访问次数"解耦。

原先 TTL 只有 2s/5s，是因为文档担心"再长会让分页总数滞后"。
但该数据只在该打手自己的工单流转时才变，而项目已有 realtime 快照广播
精确感知每次流转——把同一事件流接到缓存失效上，长 TTL 与新鲜度可以兼得，
正确性反而优于固定 5s（那同样存在滞后窗口）。

- WorkerListCache 新增 evictByPrefix：按键前缀整体逐出；
- 缓存实例抽到中立模块 worker-my-order-cache.ts：realtime 需要引用失效入口，
  而 my-order-service 已 import realtime，实例放任何一方都会循环依赖；
- 缓存键统一为 ["w",workerId,scope,detail]，前缀失效不会误伤其它打手；
- 失效挂在 publishWorkOrderSnapshots：那里恰好已有工单 + 全部拼单人，
  受影响集合取 当前指派 + 历史保留 + 全部拼单人 + 调用方指定，
  21 处工单写入路径（含取消申请/反馈处理）都会经过；
  工单已删除的分支同样失效，避免打手继续看到已删的单。

最坏情况（漏失效）是打手最多 30s 看到旧状态，与原 5s TTL 的滞后窗口同性质。
守卫测试锁定：失效入口存在、键前缀格式、受影响集合三要素齐全。
 2026-10-03 15:23:11 +08:00
yml2213 253dc2061e perf(hall): 接单排行榜加 30s 短缓存，消除每次刷新的全表聚合 
排行榜每次都要对全量 work_orders + work_order_shares 做跨源去重聚合
（生产实测 742ms / 35,483 块 ≈ 277MB），而结果只在工单验收完成时才变化。
大厅每次刷新/窗口聚焦都会触发前端重新拉取，不缓存时该查询独占全库约 8% 的缓冲读。

- TTL 取 30s：名次变化以分钟计，30s 足够新鲜；按观测到的调用量，命中率接近 100%。
- 缓存键必须带 workerId：SQL 是 WHERE rank <= 10 OR worker_id = $2，
  结果包含"当前打手自己的名次"，键漏了 workerId 会把 A 的名次错发给 B
  （正确性问题），守卫测试专门锁定这一点。
 2026-10-03 15:22:46 +08:00
yml2213 c8a4b7e945 fix(worker): 删除依赖残留字段 task_id 的死 JOIN，店铺名兜底改读 material_json 
核查结论：work_orders.task_id 是残留字段，不是"数据没同步上来"。
  1. 唯一写入点 createWorkOrder 写的是 input.taskId || null，而两个调用方
     一个硬编码 taskId: null、一个根本不传；updateWorkOrder 的白名单里也没有它；
     git 全历史检索 `taskId:` 只出现过 null 一种取值。
  2. 即便强写也无从关联：工单关联 100,231 个订单、履约任务关联 87,603 个订单，
     交集为 0；按 order_item_id 比对 100,229 条同样 0 命中。而两者时间范围
     （2026-07~10）与 orders.id 区间（1~280k）都重叠 —— 说明是按规则表分流的
     两条并行履约通道，一单只走一条。
  3. 依赖它的 idx_work_orders_task_unique 为空（8KB）。

改动：
  - 三处 `LEFT JOIN fulfillment_tasks ft ON ft.id = wo.task_id`
    （取消申请 / 售后案 / 工单反馈）恒为空，删除；
  - 店铺名兜底 `ft.shop_name/shop_id` 改为读工单自己的
    material_json->'source'->>'shopName'/'shopId'；
  - 取消申请里的 `ft.platform_order_id` 一并删除（实测 needs_ft_pid_fallback = 0，纯 no-op）；
  - 迁移 091 给列与索引打上注释，避免后续再被当成数据问题重复排查。

生产逐行回归（旧逻辑 vs 新逻辑取差集）：
  取消申请 715/715 行、103 条店铺名从空变有值、回归 0；
  售后案 21/21 行、1 条、回归 0；工单反馈 348/348 行、15 条、回归 0；
  合计 119 条修复、0 条回归、行数与 platform_order_id 零变化。

验证：新增源码级守卫（禁止再 JOIN fulfillment_tasks、兜底必须读 material_json）。
 2026-10-03 14:27:46 +08:00
yml2213 0173efb277 feat(pdd): 店铺连续同步失败 3 次后熔断，停止自动重试 
背景：生产上「木塔网游专营店」Cookie 已过期，每约 24 秒重试一次、每轮刷一条 ERROR 日志，
持续数天。Cookie 失效不会自愈，继续重试只刷日志、白白占用同步周期。

行为：
  - 失败 1~2 次：累计计数，继续重试；
  - 第 3 次：熔断，打一条显式 ERROR（含"更新 Cookie 会自动恢复"提示）；
  - 熔断后：自动同步直接跳过，不再刷错误日志；
  - 恢复：更新 Cookie（后台编辑或浏览器插件）自动解除；手动同步成功一次亦可。
  熔断状态持久化在店铺配置里，容器重启后依然生效。

改动：
  - pdd-source-config-service：阈值常量 + consecutiveFailures/syncSuspendedAt/
    syncSuspendedReason 持久化字段 + 纯函数 resolvePddStoreFailureState /
    applyPddStoreBreakerState / isPddStoreSyncSuspended / shouldResetPddSyncBreaker。
  - pdd-sync-service：syncAllPddStores 跳过熔断店铺并上报 suspendedCount；
    syncStoreOrders 失败记录、成功清零（健康店铺不产生额外配置写）。
  - pdd-order-sync-job：上报熔断数，且存在熔断店铺时强制留在 INFO 级
    （否则"全部店铺已停同步"会因新单为 0 被降级成 debug 而不可见）。
  - 前端加「已熔断 · 停止重试」标签与类型字段。

顺带修掉一个隐患：saveAdminPddStore 收的是 Partial 载荷，normalizePddStoreItem
会为缺失字段产出 undefined，导致一次「只改店铺名」的保存就把熔断洗掉。
由 applyPddStoreBreakerState 回填既有状态解决。

验证：9 项熔断单测（含局部保存不洗状态、Cookie 变更解除熔断）。
 2026-10-03 14:27:38 +08:00
yml2213 78c676d2b9 feat(worker-risk): 风控后台页面（可调阈值/实时状态/事件留痕/人工封禁解封），并修复解封后仍被 403 的 bug 
## 修复的 bug（生产已发生）

风控三级封号把 tracker.banned 置为 true 后，banned 检查发生在鉴权之前，
而它只存在于进程内存。后台把账号改回 active 时数据库变了、内存没变，
于是账号在库里已经正常、请求却永远 403，只能等容器重启才恢复。

修法两道：
- **数据库是唯一事实来源**：banned 改为带 30 秒 TTL 的缓存，到点回查
  worker_users.status；已解封（或账号已删）则清除标记并放行。
  对被判 banned 的 key 最多每 30 秒查一次，即便对方仍以 65 QPS 刷也只是
  每 30 秒一次查询。查询失败时**保守维持封禁**，不因数据库抖动放行刷子。
- **后台改状态时主动释放**：review 只允许设 active/rejected/disabled/pending_review
  （没有 frozen），所以走到那里就意味着不再由风控冻结，直接释放内存状态。

顺带修掉一个连带缺陷：解封时只清了 violationCount，没清滑动窗口计数，
账号刚恢复就会被上一轮残留的 windowCount 立刻限流、并在 60 秒内二次封禁。
现在整轮窗口状态一并清零。

## 新增后台页面

接单平台 → 风控（/admin/worker-platform?tab=risk-control），三块：
- 阈值配置：6 个阈值可视化编辑，落 app_config_entries，保存即热生效，无需重启
- 当前实时风控：进程内存状态（已封禁/惩罚中/仅记录），支持人工解封、封禁、仅释放内存状态
- 风控事件留痕：worker_risk_events 分页查询，可按类型/IP 筛选

## 关键取舍

只记**显著事件**（二级惩罚、三级封号、人工处置），不记每一次被拒请求。
被刷时实测 45~65 QPS，按请求写库正是最初要解决的问题。实时计数仍走进程内存。
事件写入为 fire-and-forget 并吞异常，留痕失败绝不影响大厅请求。

## 验证

- 新增 6 个用例覆盖解封立即生效、对账自愈、TTL 不重复查库、对账失败保守维持、阈值可配置
- 迁移 089 已在临时库实测：表结构/4 索引/CHECK 约束/外键均正确，非法 event_type 被拒
- 后端 557 测试 554 通过 0 失败；前后端 typecheck/lint/format/build 全绿
 2026-10-02 17:05:25 +08:00
yml2213 adaf4ed240 feat(worker-risk): 新增大厅阶梯式风控中间件与鉴权短缓存，惩罚外挂死循环狂刷并支持恶意封号 
1. 新增 worker-risk-control 阶梯式风控：单打手/IP 限流 3次/秒（超限返 429）；1 分钟累计违规 10 次升级为二级惩罚（锁定 5 分钟秒拒并带 Retry-After）；惩罚期内持续暴力刷接口累计 30 次自动判定恶意不改，直接封禁打手账号（status='frozen'）并作废所有 session；
2. 风控限流前置挂载在 requireWorkerSession 之前：命中限流或处于风控期时，微秒级在内存中基于 JWT payload 与 IP 拦截，彻底杜绝外挂流量穿透到 PostgreSQL 数据库；
3. verifyWorkerSessionToken 增加 3 秒内存校验缓存：并发请求直接复用内存鉴权对象，同一页面并发发出的多个接口请求仅查 1 次数据库，极大减轻连接池争抢压力；
4. 全套新增风控阶梯机制与自动封号自动化测试，后端 549 项测试全绿通过。
 2026-10-02 16:30:53 +08:00
yml2213 5c13599dff perf(file-storage): 限制 libvips 并发、收紧操作缓存，源图只解码一次 
后端 RSS 在 23 小时内从 194MB 涨到 832MB（限额 1GiB，已两次 OOM kill），
而同期 heapUsed 稳定在 71~101MB，增长全在 V8 堆外：libvips 用 glibc malloc，
每个开发出来的 worker 线程都会催生一个只涨不缩的 arena。

sharp 自带保护——检测到 "glibc 且未设置 MALLOC_ARENA_MAX" 时自动把并发降到 1；
但 .env 已显式设置 MALLOC_ARENA_MAX=2 给 arena 封顶，该保护不再触发（实测
concurrency 由 1 变 4、libvips worker 达 8 个）。故此处必须显式限制并发：
- sharp.concurrency(2)：把可能催生 arena 的线程数压到最低
- sharp.cache({memory:16, files:0, items:20})：默认 50MB 收紧到 16MB
  （注意 sharp.cache() 不做部分合并，三项必须全给）
- 源图用 clone() 复用，原实现把 sharp(data) 写在循环内导致整图解两遍

输出经比对与改动前完全等价（尺寸/格式/内容类型/字节数一致）。
 2026-10-02 15:57:13 +08:00
yml2213 142c4ee141 perf(realtime): 一次广播只序列化一次，不再按订阅者重复 stringify 
抓包发现单个后台客户端 5 秒收到 981,776 字节 / 336 条事件（约 196KB/s、67 条/秒、
每条平均 2680 字节，最大 6418 字节）。事件构成：work_order.changed 34 条/秒、
order.changed 23 条/秒、admin_notification.changed 7.6 条/秒。

原广播实现在订阅者循环里逐个 `JSON.stringify(payload)` 并重建 SSE 模板串：
客户端越多，同一份载荷就被序列化越多次（后台/打手端都在线时更明显）。
改成先 `buildEventFrame()` 构造一次，循环里只写同一帧：

- broadcast() 只调用一次 buildEventFrame
- writeEvent()（ready 事件与断线补发）复用同一构造函数
- 行为不变，仅去掉重复序列化

受众过滤经核对本来就是正确的（admin 事件只发后台、worker 事件按 workerIds 过滤），
realtime_events 也有自我清理（每 100 条保留最近 500 条，实测 555 行/2MB），
故本次只动序列化这一处。

验证：后端 548 项单测全绿（新增 1 项守卫，禁止 broadcast 内再出现 JSON.stringify）。
 2026-10-01 15:46:43 +08:00
yml2213 5092e88618 perf(admin): 打手等级筛选用 UNION 形式、概览加短缓存、静态配置接口加缓存头 
三处都出自审计清单，改动互不重叠。

1) 打手等级筛选（生产实测 1119ms）
   原写法是对 worker_users 的两个相关 EXISTS（接单人 / 拼单参与人），规划器无法用它
   驱动索引，只能顺序扫完整张 work_orders。改成先把等级解析成打手 id
   （worker_users(level_id) 有索引，等级只有 6 个、解析出几百个 id），再走索引。
   注意：**不能**写成 `assigned_worker_id = ANY(...) OR id IN (...)` —— 实测 1852ms，
   比原写法还慢（OR 右支要逐行回表取 id）。用 UNION 形式：
     wo.id IN (SELECT id FROM work_orders WHERE assigned_worker_id = ANY(...) UNION
               SELECT work_order_id FROM work_order_shares WHERE worker_id = ANY(...) AND status != 'cancelled')
   实测 61ms（count），语义与原来完全一致（含"空数组=过滤掉全部"）。
   三个入口 listWorkOrders / countWorkOrders / getWorkOrderStatistics 都先解析；
   未解析时保留原相关 EXISTS 兜底。

2) 平台概览短缓存（5 秒）
   一次并发 5 条 count（4 条打 work_orders，一条是运营态 CASE），而池只有 8 条连接，
   后台刷新时与其他请求互相争抢（抓包显示整批 9 个请求同时发出、它自身 167ms）。
   看板计数滞后几秒无感，用 WorkerListCache 缓存并合并并发。

3) 三个静态配置接口加 HTTP 缓存头（private, max-age=300）
   接单分类、快手行业店铺、自定义店铺此前没有任何 Cache-Control，每次刷新都真发一次
   请求（抓包里 4 个这类请求）。带 private 是因为这些是带鉴权的后台接口。
   **dev-mock/status 故意不加**：它是可切换状态，缓存会让"切了开关界面没变"。

验证：后端 547 项单测全绿（新增 4 项守卫，分别锁住 UNION 形式、三个入口都解析、
概览缓存、以及 dev-mock 不得加缓存）。
 2026-10-01 15:36:46 +08:00
yml2213 21cd9135a2 perf(worker): 「我的订单」列表改成先取 id 再取详情，排序阶段不再物化宽列 
打手端我的订单的排序是表达式：
  COALESCE(CASE WHEN wo.assigned_worker_id = $1 THEN wo.assigned_at END,
           CASE WHEN worker_share.status != 'cancelled' THEN worker_share.created_at END)
  DESC NULLS LAST, wo.id DESC
它依赖打手参数与拼单表，**没有任何索引能支撑**，规划器只能把该打手全部可见单
连同宽列（每行约 1.2KB material_json）物化后排序。生产实测（真实 service 路径）：
名下 6609 单的打手首访 1112ms、5198 单的 808ms、3140 单的 772ms，每次读约 60MB
（列表缓存 2 秒一失效，所以这个代价每天要重复付很多次）。

改法：该排序走"延迟分页"——第一阶段只 SELECT wo.id（窄投影 + 同一 ORDER BY +
同一 LIMIT/OFFSET），第二阶段用 `WHERE wo.id = ANY($1::bigint[])` 取这一页的详情，
再按 id 顺序还原（ANY 不保证顺序）。行集、顺序、总数语义完全不变。

验证：后端 542 项单测全绿（新增 1 项守卫）；生产上先用部署前的 id 顺序留底，
部署后用同一批打手比对首 20 条 id 与总数，并对比首访耗时。
 2026-10-01 15:29:49 +08:00
yml2213 987553909d perf(db): 统计的「状态+日期范围」组合补 created_at 键覆盖索引 
087 以 id 为键覆盖了统计要读的窄列，但日期条件无法用它驱动扫描
（created_at 不是前导列），规划器因此对 work_orders 做整表 Hash Join：
生产实测该变体每次读 400~700MB —— 缓存热时 283~694ms，缓存有压力时 926ms+
并触发慢查询告警。而"状态 + 近 7/30 天"正是运营最常用的筛选组合。

迁移 088 补一条 created_at 键、覆盖同一批窄列的索引，让规划器改为
Bitmap Index Scan 只取日期范围内的行。生产实测（真实 service 路径）：
  取 13,974 行 / 执行 75.7ms / 端到端 283ms（含列表查询），慢查询告警消失。
用"单次调用前后块差值"验证：51,521 块，与我 EXPLAIN 的 shared hit 完全一致。

与 087 的分工：无日期筛选走 id 键（index-only），有日期范围走本索引（bitmap）。
Bitmap Index Scan 无法 index-only，INCLUDE 的作用是让 heap 访问只落在日期范围内。
刻意不含 acceptance_json（勾 VIP 待补图时本就有意回表）。

验证：后端 541 项单测全绿（新增 1 项守卫）。
 2026-10-01 15:23:57 +08:00
yml2213andCursor b6c0e06f45 style: 补齐筛选统计守卫测试的格式 
Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-10-01 15:05:56 +08:00
yml2213andCursor 1239393fc2 perf: 筛选统计去掉 JSON 兜底，并补上 orders 覆盖索引 
去掉 work_orders 堆访问后，JOIN 会把 orders 整表扫进 Hash Right Join。
领取页在快照新鲜时不再打上游；快手出网统一 10 秒超时。倒计时改为自适应间隔。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-10-01 15:05:38 +08:00
yml2213 2d75be702d perf(db): 补齐三处"只差索引"的热查询缺口 
审计方式：pg_stat_statements 按"每次调用读取块数"排序 + EXPLAIN (ANALYZE, BUFFERS) 复现，
每条都先在线上并发建索引验证有效再固化（生产上索引已存在，IF NOT EXISTS 跳过）。

① 后台订单列表：COALESCE(paid_at, created_at) 同时出现在 WHERE 与 ORDER BY，
   函数包裹列非 sargable —— 默认"近 7 天"视角本身就会全表扫 orders 再排序。
   实测 26 万行/443MB：Parallel Seq Scan 读 256MB、577ms
   → Index Scan 读 0.3MB、2.05ms（约 280 倍）。
② 重跑快手补单：NOT EXISTS 打在 work_orders.order_id 上，而该列此前**没有索引**，
   反连接只能 Hash Anti Join —— 为几十个候选 id 顺序扫完 500MB 宽表，LIMIT 100 拦不住。
   实测 188MB、120ms → Index Only Scan 1.2ms（约 100 倍）。同时补 orders(order_status)。
③ 快手凭证"同步源"列表的 (oid, updated_at DESC, id DESC)：29.6 万行/678MB，实测 568MB、5.5 秒。
   仅建索引不足以改变计划（查询写法要求先物化全部 oid，见审计报告），但它是后续
   改写查询的前提，先建好避免再等一次大表建索引。

验证：后端 534 项单测全绿（新增 1 项守卫）。
 2026-10-01 13:48:05 +08:00
yml2213 92d7887108 perf(db): 运营态计数/统计加覆盖索引，消除 248MB/次的全表扫 
pg_stat_statements 重置后 25 分钟窗口显示，work_orders 相关查询里每次调用读取量最大的
全是"按运营态筛选"的形状：
  SELECT COUNT(*) FROM work_orders wo LEFT JOIN (<拼单汇总>) WHERE <运营态 CASE>
    87 次调用、每次约 248MB、均 347ms
  筛选统计的同形查询多次，248~545MB/次
根因：运营态不是存储列而是算出来的 CASE（依赖 status/sharing_enabled/sharing_total_quantity
+ 拼单汇总），规划器只能逐行求值，EXPLAIN 显示 "Rows Removed by Filter: 95923" ——
把 9.6 万行、约 533MB 的宽表整张读出来再丢掉。

迁移 085 给 CASE 用到的三列建覆盖索引（约 4MB，堆表的 1/130）：
同一查询实测 248MB → 22MB、184ms → 75ms（IO 降 11 倍）。
status 本来就有索引、状态流转本来也走不了 HOT 更新，故不额外增加写放大。

验证：后端 533 项单测全绿（新增 1 项守卫）；生产真机 EXPLAIN (ANALYZE, BUFFERS) 前后对比。
 2026-10-01 13:30:06 +08:00
yml2213 3ab897963d perf(db): 打手端「我的订单」概览加覆盖索引与短缓存 
这是数据库累计耗时第一的热路径：32 天 130 万次调用（0.5 次/秒），平均 99.8ms，
但名下订单多的打手会退化到 4.5~9 秒。EXPLAIN (ANALYZE) 定位到根因：
查询只用到 8126 个工单 id，规划器却选了「work_orders 全表顺序扫 + Hash Join」——
为几千个 id 扫 9.6 万行宽表（500MB），单这一步 4.1 秒。

1. 迁移 084：给查询真正需要的列建覆盖索引（id + INCLUDE status/assigned_worker_id/
   reward_amount/acceptance_json）。把那次全表扫变成 index-only scan，代价从 31015 降到约 5k，
   规划器自然改选索引；索引 34MB，是堆表的十五分之一。生产实测同一查询 14.5 秒 → 1.5 秒（冷缓存）。
   试过用 LATERAL 强制回表，规划器会把它拉平成同样的 Hash Join，所以只能从索引侧解决。
   迁移在事务内执行，故用普通 CREATE INDEX（不用 CONCURRENTLY）。
2. 概览读取加 5 秒短缓存：把"计算次数"与"页面轮询次数"解耦。
   只缓存读取——会话校验与 settleOverdueWorkOrders（写副作用）每次照常执行，否则会漏结算。

验证：后端 532 项单测全绿（新增 1 项守卫，覆盖索引列与缓存位置都纳入断言）。
 2026-10-01 13:12:42 +08:00
yml2213 2f2d44f601 perf(admin-worker): 筛选统计加 10 秒短缓存，把成本增长与访问量解耦 
金额落到派生列后，统计查询从生产实测 3.5~4.4 秒降到 ~400ms（约 9 倍），
但仍要扫全部命中工单（9.6 万行宽表 + 关联 orders + 拼单汇总），成本随工单量线性增长，
数据再翻几倍会重新撞上 500ms 慢查询线。

因此按"筛选指纹"缓存 10 秒并合并并发请求（WorkerListCache.getOrSet）：
单位时间内的计算次数被封顶在 TTL 上，不再跟着刷新次数走；多人同时刷列表只会算一次。
代价是统计与分页总数最多滞后 10 秒，期间前端已由实时事件快照就地修正 statistics，
刷新后自动对齐。

指纹覆盖 statuses/status/workOrderId/keyword/workerSharingId/workerId/workerLevelIds/
categoryId/acceptanceMode/giftPhase/vipEvidencePending/useOperationalStatus/创建日期，
并加静态守卫防止后续漏字段导致不同筛选互相污染。

验证：后端 531 项单测全绿（新增 1 项守卫）。
 2026-10-01 13:02:09 +08:00
yml2213 1ca15e9025 perf(db): 统计金额落到列上、会话刷新节流、补齐保留与内存治理 
背景：生产 32 天内 >500ms 慢查询从 2.4k/天涨到 1.3 万/天（09-26 尖峰 14.3 万），
pg_stat_statements 显示后台工单列表族占 57%、打手端 visible_orders 占 27%；
同时 backend 容器十天从 194MB 涨到 754MB(768MB 限额的 98%)，贴顶后整体变慢。

1. 新增迁移 083：work_orders 增加派生列 source_order_amount_fen，并从
   material_json.source.orderAmountFen 回填（只认 15 位以内整数，与 JS/SQL 口径一致）。
   统计查询原来每行要解析 1.2KB JSON（全表约 132MB）且同一表达式求值两次，
   生产实测 3.5~4.4 秒；改走派生列后 COALESCE 短路，未命中列的行才回退 JSON/orders.total_amount，
   口径与改造前完全一致。写入点：createWorkOrder / updateWorkOrder 各一处，并加静态守卫。
2. worker_sessions.last_seen_at 从"每个请求都写"改为"5 分钟才写一次"：
   32 天被写了 3300 万次（占 DB 总时间 2.8%，并堆出 14% 死元组）。仍用一条语句返回鉴权有效性
   （EXISTS target AS valid），不能因为不写就让上层 401。
3. 保留策略补上 work_order_events（71.7 万行 / 269MB，此前完全没纳入清理，只增不减），
   新增配置 retention.workOrderEventDays（默认 180 天）与 WORK_ORDER_EVENT_RETENTION_DAYS 出口。
4. 内存治理：compose 后端限额 768m→1g 并显式设置 V8 老生代上限（--max-old-space-size=768），
   避免贴 cgroup 上限后 GC 抖动；新增每 10 分钟的进程内存快照日志（rss/heapUsed/heapLimit），
   用于区分"正常 GC 曲线"与"真泄漏"。
5. 限流桶加 5 万条硬上限：key 里含请求体字段（collect 的 orderNo）时可被构造成高基数，
   只按过期清理挡不住内存增长。

验证：后端 530 项单测全绿（新增 11 项，含派生列/会话/保留的静态守卫与解析函数单测）。
 2026-10-01 12:55:09 +08:00
yml2213 9573acc59d fix(consignment): 问题单「退回大厅」也要解绑寄卖现货 
问题单处置的「退回大厅」只把订单置回 open，没有解绑被本工单占用的寄卖现货，也没摘 material 上的
寄售标记。后果是卖家端「我的寄卖」把这张单显示成「履约中 + 关联订单状态已变化，请联系客服核对」
（状态机只认 in_progress / problem / pending_acceptance，open 落到兜底分支），而现货永久停在
consumed 占库不还、既不再参与匹配也没有释放入口。

其余同义路径（后台退回大厅、超时重开、打手退单通过）本来都会解绑，只有问题单这条漏了，属口径不一致。
现在把解绑条件从「仅取消」扩到「取消或退回大厅」；「退回打手重做」保持占用（货还在这一单上履约）。
调用位置仍在状态 UPDATE 之前——该 UPDATE 在 open/cancelled 时会清空 friend_added_at，
清完再解绑会把已确认加好友的货误判成可回池（二次出货）。

验证：真实库跑通两条路径——退回打手重做（现货仍 consumed+绑定的、标记保留、打手端仍「已匹配-待加好友」）
与退回大厅（现货回 in_stock、解绑、标记摘除、打手端变「已通过（在库待匹配）」）；后端 520 项单测全绿。
 2026-10-01 12:22:56 +08:00
yml2213 40ee36d72a fix(consignment): 修复寄卖取消解绑、SUB 单号写空、拼单门禁与后台工单列表实时乱跳 
1. 问题单处置「取消」后打手信息不消失：resolveProblemWorkOrder 的取消分支从未解绑寄卖现货，现货永久停在 consumed 占库不还，工单 material 上的寄售标记残留又让列表继续显示「供货打手」。取消时补上解绑；调用必须排在状态 UPDATE 之前——那条 UPDATE 会清空 friend_added_at，清完再解绑会把已确认加好友的货误判成可回池（二次出货）；
2. 解绑函数在没有现货可解绑时直接 return，跳过了摘标记，于是「库存行早已不存在」的老帖永远摘不掉寄售标记（列表一直显示供货打手）。现在无论是否解绑到现货都摘标记，痕迹保留在 material.consignmentHistory 的 detachReason 里；
3. 内部现货履约写入的 sourceSubmissionNo 恒为空：取的是占库 `UPDATE ... RETURNING *` 的行，只带回本表列，没有 join 出来的 submission_no，导致工单列表把所有寄卖单都显示成「老单无提报单号」，SUB 单号这个唯一锚点丢失。改取带 join 的预读库存（内部现货资料、指派工单资料、指派事件留痕三处）。存量老单按业务口径不回填；
4. 后台接单工单列表实时乱跳：SSE 快照补丁按数组下标读 queryKey，面板 key 加了字段后下标全错（page 被读成 targetWorkOrderId → 任何页都被当成第 1 页），且完全没判「内部寄售匹配」等筛选，于是任意一条不在当前页的老单只要发生变更就被插到列表顶部。改为结构化 queryKey + 三态判定（match 才允许插顶、mismatch 才允许移除、其余只原地更新），插入还要求 page===1 且工单 id 大于当前首行；状态比对改用 rawStatus（快照的 status 是运营态，拼单母单会被显示成 in_progress），分类筛选因快照不带 parentCategoryId 归入不可证伪；
5. 新增「寄卖只做整单」硬门禁：已有人参与的拼单工单不参与现货匹配与库存提醒，履约入口一律返回 work_order_sharing_not_consignable，前端「手动匹配寄卖」入口按同一口径收敛；开了拼单但无人参与的整单不受影响，避免过度拦截。

验证：后端 520 项单测（517 pass / 3 skip）、前端 78 项全绿；并对真实开发库跑通问题单取消三类场景（老帖无库存行 / 回库 / 已加好友作废）、退回打手与退回大厅的反向用例（不得解绑）、履约写入真实 SUB 单号、拼单门禁四入口 + 未过度拦截反向用例。
 2026-10-01 12:17:00 +08:00