Files

赵忠林 eadaa8c4dd docs(memory): 补充分销佣金解冻任务分析与排查日志

- 新增 DealerCommissionUnfreeze10584Task 解冻规则详解
- 说明送水套餐与非送水套餐的不同解冻触发条件
- 解析“已送达”与“已完成”状态区别及影响
- 列出常见未解冻原因及排查优先级
- 增加长期记忆文件中分销佣金解冻相关业务规则和状态流转说明
- 添加2026-04-18排查解冻任务未触发的问题及可能原因
- 更新专家历史记录，新增高级开发工程师吴八哥信息
- 新增生产环境 application-test.yml 配置文件示例

2026-04-18 10:58:38 +08:00

3.8 KiB

Raw Blame History

2026-04-16 工作记录

支付回调状态不更新问题诊断与修复

问题接口: POST /api/shop/shop-order/notify/{tenantId}

发现的 Bug

根因 Bug：ShopOrderServiceImpl.updateByOutTradeNo() 第837行有 order.setExpirationTime(null)，强制覆盖了 Controller 中设置的 expirationTime（LocalDateTime.now().plusYears(10)），导致 XML 中 expirationTime 条件不生效。已修复：删除了该行。
XML 缺少 update_time：ShopOrderMapper.xml 的 updateByOutTradeNo SQL 的 <set> 块中没有 update_time = NOW() 和 expiration_time 字段。已修复：新增了这两个字段更新。
回调地址路由问题：Controller 路由为 /notify/{tenantId}，但测试访问的 /notify（无 tenantId）不存在，返回 fail。正确回调地址格式为 https://glt-api.websoft.top/api/shop/shop-order/notify/{tenantId}（需带租户ID）。待检查：数据库 Payment 表的 notify_url 字段是否正确配置了带 tenantId 的完整路径。

修复文件

src/main/java/com/gxwebsoft/shop/service/impl/ShopOrderServiceImpl.java
src/main/java/com/gxwebsoft/shop/mapper/xml/ShopOrderMapper.xml

支付回调签名验证失败：Transaction 类错误（00:29修复）

错误日志关键信息：

signature verification failed, signType[WECHATPAY2-SHA256-RSA2048]
serial[test]  message[test\ntest\n{"test":"test"}]  sign[test]

根本原因（最致命）

ShopOrderController.java 导入了 服务商模式 的 Transaction 类：

// 错误（服务商模式）
import com.wechat.pay.java.service.partnerpayments.jsapi.model.Transaction;

而 ShopOrderServiceImpl.java 下单时用的是直连商户模式：

// 正确（直连商户模式）
import com.wechat.pay.java.service.payments.model.Transaction;

两个 Transaction 包路径不同，字段结构有差异（服务商 Transaction 有 spAppid/spMchid 等字段），用错误的类解析回调会导致字段映射失败，交易状态无法正确读取。已修复：改为正确的直连商户模式 Transaction。

配送员提成直接入账（01:15修改）

文件：src/main/java/com/gxwebsoft/glt/service/impl/GltTicketOrderServiceImpl.java

变更：配送员提成（ticketOrderId 关联送水订单）从进入 freeze_money 改为直接进入 money（可提现余额）。修改了 2 处 LambdaUpdateWrapper SQL（freeze_money → money），注释同步更新。total_money 不变（仍累计）。

分销佣金解冻任务分析（DealerCommissionUnfreeze10584Task）

订单号：2038841514750459904

解冻规则

送水套餐（shop_order.form_id IN 水票模板的 goods_id）：该订单关联的水票第一条送水订单 deliveryStatus=40（已完成）才触发解冻
非送水套餐（form_id 不在水票模板中）：shop_order.order_status=1 即触发解冻

"已送达"≠"已完成"的关键区别

deliveryStatus=30（送达待确认）：配送员拍照确认送达，此时不触发解冻
deliveryStatus=40（已完成）：需用户手动确认收货 OR 超时24h自动确认后才到达此状态

常见未解冻原因（按排查优先级）

送水订单停在 deliveryStatus=30（送达待确认），未到 40（已完成）
shop_order.form_id 在水票模板里，走的是"送水套餐"逻辑，但没有找到对应的 glt_user_ticket 记录
glt_user_ticket 记录缺失或 order_no 字段为空
已有 flowType=50 的解冻 marker（说明已解冻）

次要原因

RSAAutoCertificateConfig 每次回调都重新 build()，SDK 内部会发一次 serial=test 的探测验签，网络问题或并发场景下可能导致首次回调失败。已优化：添加 notifyConfigCache（ConcurrentHashMap）按 mchId 缓存 config，避免重复初始化。

3.8 KiB Raw Blame History Unescape Escape