zhaoxing
6a5a8d70b0
feat:拼单订单新增一个取消部分的按钮功能，点击之后，打手进行中和待接单的都会取消订单
2026-10-26 12:15:52 +08:00
zhaoxing
60fe00b28c
fix:打手端/我的订单/验收：验收视频和验收图片至少上传一个就好了，其他逻辑按照上传图片走
2026-10-25 16:45:38 +08:00
zhaoxing
9c620d39cb
feat:拼单明细管理加一个撤份额的功能，指定数量
2026-10-25 13:44:34 +08:00
zhaoxing
a7a8634a96
feat:加一个网站发布公告会弹出来点确定我已知晓的弹窗;mock数据自动匹配接单模板;本地访问模式修改
2026-10-25 12:27:32 +08:00
zhaoxing
0ee5554f57
add:新增验证视频可选上传功能
2026-10-24 16:12:56 +08:00
zhaoxing
f9aeece7ab
add:新增同一个工单同一人可以多次拼单：拼单明细ui优化
2026-10-23 17:45:05 +08:00
zhaoxing
7e1e1f7075
add:新增同一个工单同一人可以多次拼单：拼单后按钮固定显示「再拼一次」
2026-10-23 16:37:59 +08:00
zhaoxing
2befb57ef8
add:新增同一个工单同一人可以多次拼单：拼单后台撤单，不影响母单状态
2026-10-23 15:20:14 +08:00
zhaoxing
1d5615f1ae
add:新增同一个工单同一人可以多次拼单
2026-10-23 15:14:07 +08:00
zhaoxing
bfd2325ac5
add:新增同一个工单同一人可以多次拼单
2026-10-23 14:26:41 +08:00
zhaoxing
067d54fdd8
接单平台：新增店铺筛选条件
2026-10-22 14:45:40 +08:00
yml2213
7542d547bf
feat: 新增客服备用金台账与后台用户中文显示名
...
- 新增备用金账户、流水、支出、对账与权限
- 后台用户支持中文显示名并同步备用金姓名
- 审计、登录记录、任务及工单操作人优先展示中文名
- 补充备用金与人工支出方案文档
2026-10-18 13:55:24 +08:00
yml2213
6850bc64ff
feat(work-order): 发布并核销支持抖音券（按来源分流，抖音走 DYC 券核销）
2026-10-15 13:22:18 +08:00
yml2213
584b6f52aa
fix(work-order): 问题单处置存在活跃拼单份额时禁止取消/退回大厅/重开
...
生产实锤 WK26101503335487：客服对份额已提交的拼单母单走问题单处置-取消，
母单整单 cancelled 后份额验收/单人撤单全部被母单状态挡死，后台无补救入口。
- 抽出 getActiveWorkOrderShareCountWithClient 统一活跃份额统计口径
- resolveProblemWorkOrder 的 cancel/cancel_deduct/reopen 先过活跃份额防线
（return_to_worker 不拦），返回结构改为 {order, failureReason}
- settleOverdueWorkOrder 复用同一统计函数，消除两份 COUNT 口径
- 服务层映射 409 work_order_problem_resolution_has_active_shares，
文案引导客服先单独验收/单人撤单
2026-10-15 10:34:43 +08:00
yml2213
10464fea89
refactor(product-match): 抽离接单模板匹配引擎（来源适配器/引擎/价格收口 + 后台按订单项试匹配）
...
新增 services/product-match：来源适配器（kuaishou-91 合成 91+快手 / pdd / douyin-mashida）+ 平台无关匹配上下文 + 条件打分引擎（并列最高=ambiguous 不猜、逐维诊断）+ 价格数量拼单唯一实现。
- 商店键命名空间化（kuaishou:/pdd:/douyin:），店铺为可选作用域：留空即可按订单信息匹配
- 抖音匹配文本只取内部 SKU，引流标题只进 promoTitle，itemTitle 恒空（修复 0.85 元误命中碎梦浮光珍宝礼盒、拼单未开）
- work-product-match-mappers 改为门面（签名不变），work-order-pricing 改为转发
- 新增后台「按订单项试匹配」接口与面板：走发单同一套链路，返回模板/数量/单价/总额/拼单
- 生产样本回放：91/PDD 6000 条决策 0 差异；抖音 5 条全为修正
设计见 docs/接单模板匹配引擎重构设计.md
2026-10-14 15:58:21 +08:00
yml2213
4b081d88c5
feat(douyin-mashida): 抖音按 SKU 三层分类接入（对齐 91/快手）
...
- sku_code 恒为内部 SKU（不再被英文 sku 覆写）；英文 sku / 引流标题分别落 snapshot
- 命中映射 → affiliate_dash；未命中不再兜底 manual_dispatch（无执行载体 = 待人工，不建任务）
- 抖音映射支持「常量表 + 后台 skuMapping 增量」，新增商品不必发版
- 载体唯一守卫：命中自动发货的订单项不再建工单
- 券 cert_link 与命中解耦（/h5 一律按订单号拼）；券写入工单 material_json.douyinMashidaVoucher
- 新增/修正 16 例单测；后端全量 717 例 / 0 失败
2026-10-14 13:00:49 +08:00
yml2213
cb064d7cd5
fix(worker-platform): 工单号前缀改 WK 并在检索侧容错 O/0，彻底解决「按工单号搜不到」
...
## 线上定位到的真正根因
客服搜 `WO26101213031939` 搜不到，但用同单的平台号 `2628501763808879` 搜得到。
到生产库核对后确认：
- 库里真实值 `work_order_no = WO26101213031939`（hex 574f… = 字母 O），状态 pending_acceptance；
- 用字母 O 的 SQL 分支 → 1 行；用数字 0（`W026101213031939`）→ 0 行；
- 全库 127,906 单**全部**以 `WO` 开头、`W0` 开头 0 单、字母 `o` 只出现在第 2 位。
即：前缀里的字母 O 被输成数字 0（`WO` / `W0` 在界面字体里几乎无法区分），
落进通配符分支后必然为空 —— 与前面几轮的「筛选把单藏起来」是两个独立成因，
这也解释了为什么改筛选逻辑一直没解决。
## 修法
1. 生成端换前缀：generateWorkOrderNo 产出 `WK…`（K 与 0 不会看混），从源头消掉歧义；
2. 检索端同时兼容三种写法（历史 WO 号无需迁移）：
- isWorkOrderNoLookupKeyword 放宽为 `^W[oOkK0]…`；
- 新增 buildWorkOrderNoKeywordVariants：W0→[W0, WO, WK]、WO→[WO, W0]、WK→[WK]，
SQL 分支对每个候选下发「等值 + 前缀」条件（仍是索引条件，不会退化成全表扫）；
- 前端 isExplicitOrderNoSearch 同步（否则面板不清理筛选、实时补丁护栏也不生效）；
3. 顺手加一层归一化：NFKC（全角→半角）+ 去零宽字符，前后端同一口径
（normalizeLookupKeyword / normalizeSearchText），覆盖「粘贴带不可见字符」这类同族问题；
4. 寄卖匹配弹窗的占位提示更新为 WK... / WO...。
## 验证
- 后端 npm run check 全绿：692 tests（689 pass / 3 skip），新增
work-order-keyword-lookup.test.ts 直接断言 SQL 参数与「不得出现前置通配符」；
- 前端 npm run check 全绿：139 tests；
- 既有用例 worker-platform-repo.test.ts 的期望值同步为新形态（两条候选条件）。
2026-10-12 16:51:08 +08:00
yml2213
fe4d02d136
fix(worker-platform): 按工单号搜不到彻底收口 —— 显式单号检索不再被任何排他筛选吞掉
...
## 修的是什么
线上反复复发的「后台接单平台按工单号搜不到、某些状态尤其明显」，根因不是一处，
而是同一类问题在 5 个地方各留了一半（历次修复都只补了一处，所以总复发）：
1. 状态筛选走运营态派生：拼单母单一旦有人参与，open → in_progress /
pending_acceptance，于是「单号 + 待接单」永远为空（没人参与时反而搜得到），
这正是「有人接单后就搜不到」；非拼单单子被接单后同理。
2. 「单号 + 接单人员 / 分类 / 打手等级 / 创建时间」照样过滤掉目标单
（接单人员是 INNER JOIN 可见集合，不在集合里整行消失）。
d6523635
2026-10-12 15:48:30 +08:00
yml2213
6012add3c9
feat(worker): 打手接单界面支持查看超时历史订单并增加安全免责警示
...
- 数据库与查询层：通过索引 idx_work_order_events_timeout_worker_id 关联打手历史 timeout 事件与取消的拼单份额，打手在退回大厅或被他人抢走后仍能在「已超时」tab 查看历史记录；
- 状态与权限管控：针对超时工单将个人端状态稳定映射为 open，报酬与冻结押金置为 0，彻底禁用上传图片、提交验收、好友资料、申请取消等履约操作；
- 风险防护与免责说明：列表与抽屉详情顶部增加醒目的免责声明与警示横幅（告知订单已退回大厅或被他人接手，严禁在游戏内继续赠送，造成的损失平台概不负责）；锁定买家游戏资料与快捷复制；
- 验证方式：通过后端全部 676 个测试、typecheck、check:sql 及前端 check（eslint、vitest/node:test、tsc、vite build）。
2026-10-11 15:20:46 +08:00
yml2213
b82f9c4063
fix(worker-platform): 补齐拼单份额超时自动处置机制与退回大厅流程
...
- 根因排查：此前超时扫描仅针对整单 in_progress，而拼单母单为 open 且 deadline_at 为空，导致打手超时的拼单份额无法被定时扫描命中与释放；
- 定时扫描：在 settleOverdueWorkOrders 中引入 listOverdueWorkOrderShares，自动扫描超时未提交资料的拼单份额（joined）；
- 超时处置：新增 settleOverdueWorkOrderShare 事务处理，按母单 timeout_policy 释放或扣除押金，份额标记 cancelled，母单保持或恢复 open 状态重回抢单大厅，记录 timeout 事件并推送实时变更；
- 提交防呆：在打手提交拼单验收时检测个人份额是否已超时，超时则立即执行处置并拦截提交；
- 倒计时展示：在 mapWorkOrderForWorker 中根据 myShare.created_at + timeout_minutes 为拼单打手计算并展示个人履约截止时间；
- 质量验证：补齐拼单截止时间计算与处置链路测试，全量 676 个测试均通过，通过 npm run check 校验。
2026-10-11 14:53:56 +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
893388b37f
feat(consignment): 寄售仓库在库列表增加通过审核入库时间并在手动匹配中补全时间展示
...
- 寄售仓库 (ConsignmentInventoryPanel)：表格中增加「通过审核入库时间」列并格式化展示，详情弹窗规范化展示入库时间、出库时间与提报时间
- 手动匹配弹窗 (ConsignmentManualMatchModal)：候选订单列表展示工单创建时间，顶部横幅与已选概要展示现货入库时间及订单创建时间；从订单匹配现货时展示现货入库时间
- 内部匹配接口与工单拦截：后端 listInventoryMatchableOrders 返回工单创建时间及平台单号；发布拦截弹窗中增加展示现货入库时间
- 验证方式：运行前后端单元测试全部通过，前端 build 校验通过
2026-10-08 15:41:23 +08:00
yml2213 and Cursor
250c456a46
fix(consignment): 内部库存履约后不再把买家资料暴露给上一手打手
...
退回大厅留下的 last_assigned 在状态离开待接单后会重新可见。履约时摘掉上一手，并清掉已经漏出的内部现货工单。
Co-authored-by: Cursor <cursoragent@cursor.com >
2026-10-05 19:18:43 +08:00
yml2213 and Cursor
eae78aae34
fix(consignment): 退库后不再带出上一单买家资料，撤单清掉上一手验收痕迹
...
现货退回仓库后只留卖家提报，不再挂买家角色、赠送凭证和店铺；工单撤单、退回、抢单时清掉验收与备注，买家下单资料仍保留。
Co-authored-by: Cursor <cursoragent@cursor.com >
2026-10-05 14:55:42 +08:00
yml2213 and Cursor
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
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
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
yml2213 and Cursor
b6c0e06f45
style: 补齐筛选统计守卫测试的格式
...
Co-authored-by: Cursor <cursoragent@cursor.com >
2026-10-01 15:05:56 +08:00
yml2213 and Cursor
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
yml2213
1636616ec1
feat(worker-platform): 寄卖价格改由接单模板只读定价，我的寄卖支持服务端搜索与分页
...
1. 寄售价不再由卖家填写：打手端改为只读展示模板价（与履约押金同款只读框），服务端在发布时按同一套规则复算金额，保证展示口径与落库口径一致，直连接口也无法随意定价；
2. 模板缺档按「最接近的已配置档位」报价、距离相同取更低档：后台只配了 1/3/7 钻时，号主出 2 钻报 1 钻价、出 6 钻报 7 钻价，不再因为中间档没配价而拿不到价格；
3. 我的寄卖列表把分组、关键字、翻页全部下沉到 SQL：新增 listWorkerConsignmentPage 用 UNION ALL 合成「提报单行 + 无提报单库存兜底行」，CASE 推导 待审核/履约中/已完成 分组，返回当前分组 total 与三个分组的角标计数；
4. 关键字覆盖寄卖单号、规格名、系统/区服/系列/钻级、卖家角色名与数字 ID、联系方式、买家昵称与游戏 ID（读取 work_orders.material_json.collect.fields 的多种历史键名）；
5. 前端搜索框 300ms 防抖后才请求服务端、换分组或换关键字自动回到第 1 页、列表底部增加分页器，并移除原来固定 pageSize 200 的隐形截断；
6. 新增仓库层与匹配层单测，其中包含 SQL 分组 CASE 与 domain/consignment-item-stage.ts 的 group 映射交叉断言，防止两处状态机漂移；后端 516 项、前端 66 项测试全部通过。
2026-10-01 11:07:28 +08:00
yml2213 and Cursor
9298b31b9b
feat(worker-platform): 增加寄卖白名单总开关，关闭后全员可发布
...
资金配置与打手列表可一键切换白名单模式；发布校验、打手端入口按总开关放行。同时收紧未开通判定、关权限确认和开通弹窗文案。
Co-authored-by: Cursor <cursoragent@cursor.com >
2026-09-21 14:23:00 +08:00
yml2213
cb8b249e57
feat(worker-platform): 实现打手寄卖白名单权限控制与存量发布打手平滑过渡
...
1. 新增数据库迁移 082_worker_consignment_whitelist.sql，worker_users 表增加 can_consign 与 consignment_activated_at 字段，存量在 consignment_submissions 提报过的打手默认自动开启；
2. 打手端提报接口 publishWorkerConsignment 增加白名单权限服务端强校验拦截（403 consignment_permission_required）；
3. 管理后台打手管理表格增加「寄卖权限」实时 Switch 开关列与打手详情抽屉权限展示，支持客服即时开通或关闭打手寄卖权限；
4. 打手端我要寄卖页面在未开通权限时展示专属白名单引导卡片，一键呼起联系客服开通寄卖弹窗；
5. 补充寄卖权限拦截与路由单测，前端59项单测与后端507项单测全部通过。
2026-09-21 13:30:33 +08:00
yml2213
c80bd0e337
fix(worker-platform): 修复寄售匹配工单详情中卖家上架截图丢失问题，并收敛手动匹配为内部现货直接履约
...
1. 修复文件归一化器 normalizeUploadedFiles 遇到纯字符串 URL 数组被误过滤为空的问题，自动提取 objectKey 并构造规范 UploadedFile 结构；
2. 优化工单展示映射器 resolveWorkOrderEffectiveBoosterMaterial：当工单资料中截图为空时，自动回退并加载寄售卖家上架/主页截图；
3. 前端管理后台详情抽屉与打手端详情抽屉支持读取 detailOrder.gift.boosterMaterial.screenshots 与 consignmentInfo.screenshots 降级兜底渲染；
4. 手动匹配弹窗与发布拦截弹窗全面收敛为单一标准的【内部现货直接履约】，废除旧版指派打手带来的重复扣押金与二次填资料问题；
5. 新增 consignment-booster-material 单元测试，更新寄卖库存优化现状与进度追踪文档，前后端全套测试通过。
2026-09-21 11:35:38 +08:00
yml2213 and Cursor
040b3db84c
fix(finance): 移除资金审核取消按钮，避免提现冻结资金未退回
...
Co-authored-by: Cursor <cursoragent@cursor.com >
2026-09-20 21:59:29 +08:00
yml2213
f07e4087ad
feat(consignment): 优化寄售仓库与接单工单双向手动匹配，支持工单号与提报单号检索与强制匹配
...
1. 寄售仓库手动匹配订单扩充支持 open 状态工单，增强 WO 工单号与纯数字的模糊/前缀搜索，修复工单搜不到的问题并在卡片高亮展示内部工单号与状态；
2. 接单工单操作列全面支持【手动匹配寄售】，允许从接单工单主动调起寄售匹配弹窗；
3. 寄售现货筛选支持通过 SUB 提报单号、INV 仓库号、供货打手等快速搜索；
4. 完善规格冲突下的强制匹配确认与必填原因提交机制，确保履约全流程留痕合规。
2026-09-19 17:59:05 +08:00
zhaoxing
yml2213