 kate522
|
ca9dc7794f
|
refactor(pay): 流水号扩至 22 字符，移除资金流水归档方案与删单守卫
四件事合在一笔，因为它们落在同一批文件里——OrderRepositoryCore 与流水契约测试
同时承载号码规则与订单清理逻辑，硬拆会产生引用不通的中间提交。
1) 号码熵。{YmdHis}{6 位随机} 在同一秒内只有 10^6 的取值空间，高并发下单会因
随机后缀碰撞触发 uniq_order_number / uniq_flow_number 冲突（每秒 3 单约
2.6 天撞一次，每秒 10 单约每天 4 次）。后缀扩到 8 位后空间升至 10^8
（+6.6 bit），撞号频率下降两个数量级。
选 8 位纯数字而非等长 base36：保持定长纯数字形态，号码仍可被运营从截图或
邮件整段复制、电话口述；且表默认排序规则是 utf8mb4_*_ci（大小写不敏感），
混入大小写字母会让唯一索引把 aB 与 Ab 判为重复行，反而凭空制造冲突。22 字符
仍满足 VARCHAR(32) 与网关 out_trade_no ≤ 32，拼上重试后缀 P999 后为 26 字符。
2) 自带订单号形态校验。create() 此前对调用方传入的 order_number 不做检查，传数组
会因 (string) 转换把字面量 "Array" 写进列。现收紧为「全数字、20 或 22 位」，
不合规即弃用并回落到分配器（WP_DEBUG 下留痕）。放行 20 位是为了兼容扩位前
分配的历史号码——该方法原有的注释就声明服务于导入、补单与幂等重放。
3) 流水表补 KEY idx_flow_created (created_at)。后台「资金流水」页默认视图是
WHERE 1=1 ORDER BY created_at DESC, id DESC LIMIT n 加同条件 COUNT(*)，界面
上的日期区间筛选也只有 created_at 可用。此前没有任何以 created_at 为前导列的
索引（idx_flow_event_time 的前导列是 event_type，筛选时可空），于是每次翻页
都是全表扫描 + filesort，且与表大小无关地重复付出。
4) 移除归档方案与删单守卫。归档表 + 每日清理 cron 需要配套的归档浏览入口才闭环，
未闭环时运营会误以为记录丢失；而第 3 条的索引已覆盖它要解决的主要问题，且
不必在财务表上执行 DELETE。一并撤回删单 / 清理订单时对财务记录的拦截。
- BusinessNumber：后缀位数与上界收敛为 SUFFIX_DIGITS / SUFFIX_MAX，去掉三处
重复的魔法数字；类文档写明选型依据，避免日后被改回字母方案
- OrderRepositoryCore：新增 ORDER_NUMBER_PATTERN 与 is_scalar 守卫；
clear_closed_orders 与 delete_order 恢复单路签名（去掉 $force 与
$include_orders_with_records）
- DBMigratorPart2：流水表新增 idx_flow_created，并删除两张归档表 DDL
- PayOrders：清理与删除订单回到单路处理，移除 orders_clear_blocked /
order_delete_blocked 两条提示
- 删除 FinancialFlowRetention 类与 functions.php 中的引导注册
- 测试：BusinessNumberTest 期望值改 22 字符、越界用例改 10^8、补纯数字与 P999
余量断言；流水契约测试并入索引断言、归档移除的反向断言、号码重试与形态断言
按用户要求不写双路逻辑与数据迁移。新索引依赖 dbDelta 在下次迁移时补到既有表；
若此前已跑过迁移，两张归档空表需手工 DROP（未写迁移，故不自动处理）。
验证：PHPUnit 44 项 / 106 断言全部通过；node --test（已追踪用例）333 项 /
333 通过，含本地专用用例共 370 项全部通过；php -l 全部改动的 PHP 文件通过；
残留引用扫描确认 FinancialFlowRetention、两张归档表名、has_financial_records、
count_closed_orders_with_records、financial_records_exists_sql、两条 blocked
提示、$force 与 $include_orders_with_records 均已无残留。
|
2026-09-18 23:17:36 +08:00 |
|
|
kate522
|
aad83072a8
|
refactor(pay): 统一流水号，移除订单/流水/提现三类号码前缀
订单号、资金流水号、提现单号此前各自带前缀配置，同一笔业务在不同界面会
呈现多个号码口径，对账与客诉排查都要先做一次前缀换算。现收敛为单一流水号
分配器，不再按业务类型区分号码形态。
- 删除 payment_order_prefix / payment_flow_prefix /
payment_withdrawal_prefix 三项配置项及其生成、校验链路
- BusinessNumber::allocate() 成为唯一入口，输出 {YmdHis}{6 位随机}，
共 20 位无前缀，满足 VARCHAR(32) 与网关 out_trade_no ≤ 32 的限制
- 订单、资金流水、提现、卡密渠道交易号四处生成点全部改走该分配器
- 后台支付中心表头「订单号 / 提现单号」统一为「流水号」
- 前台用户中心与订单卡片文案同步统一；前台订单详情合并为单行流水号，
账本流水号不再下发到前台，避免同一单据出现两个对外号码
- 同步更新 financial-flow / pay-card / card-pass-order-numbers 契约测试
与 BusinessNumberTest 断言
按用户要求不做双路逻辑与数据迁移，直接替换为统一方案，历史行不做转换。
验证：node --test tests/**/*.test.cjs 362/364 通过，新增 37 项契约；失败的
2 项在改动前的干净 HEAD 基线上同样失败（基线 327 项 / 失败 2 项），分别命中
遗留的 fa fa- 标记与 FA 版本号断言，与本次改动无关。phpunit 44 项 / 103
断言全部通过；php -l 全部改动的 PHP 文件通过。
|
2026-09-18 22:14:27 +08:00 |
|
|
kate522
|
ba8d4b1b90
|
卡密充值与兑换接入统一订单号与支付流水号
此前卡密核销虽已建订单，但订单号硬编码 CARD{卡ID}、渠道交易号硬编码
card_pass_{卡ID}，均不受后台前缀控制；且核销产生的资金流水没有挂到
订单上（order_number 为 NULL），订单详情页的「支付流水号」恒为「—」。
ChargeCard：
- 新增 allocate_redeem_order_number()：走 OrderRepository 统一分配器，
消费后台「订单前缀」（payment_order_prefix）。
- 新增 card_pass_transaction_number()：BusinessNumber::candidate(flow_prefix)，
消费后台「流水号前缀」（payment_flow_prefix）。
- 两条兑换路径（redeem_asset_card / redeem_vip_card）替换硬编码取号；
create_redeem_order 接收调用方传入的交易号。
- 账本重放（replayed）时回取已落库订单号，不再把本次新分配的号回给前端。
FinancialFlowService：
- record_card_pass_payment()：会员卡（0 元、无账本参与）直接落一条
与订单关联、零分录的 order_payment 流水；record() 新增
allow_empty_entries 通道（prepare_entries 拒绝 delta=0，占位分录不可行）。
- record_order_event() 新增凭证结算模式：豁免「金额必须 > 0」与
「资产类订单不得记现金流水」两条门槛（卡密核销既无第三方现金流入，
订单还可能为 0 元或以积分计价）。
- attach_order_to_ledger_flow()：账本提交后把流水补挂到订单上，
event_type 归一为 order_payment，使「支付流水号」可反查。
- is_successful_order_payment() 认可 card_pass 凭证结算；
is_external_recharge() 把 card_pass 与 balance/points 一并列为平台内部
结算方式，不再为卡密充值伪造现金出账分录（现金在售卡时已确认）。
关键取舍：随机订单号不得进入 LedgerCommand 的 metadata —— payload_hash
覆盖 metadata，会破坏账本幂等重放（实测撞 uniq_operation_key 后报
aksrt_ledger_idempotency_conflict），因此订单关联改在账本提交后补挂。
测试：新增 tests/admin/card-pass-order-numbers.test.cjs 钉住上述约束；
容器内三类卡密实测通过（订单号/渠道交易号/支付流水号三项均带后台前缀，
流水行分别携带 balance:in / points:in / 零分录），重放幂等恢复正常。
|
2026-09-17 14:15:55 +08:00 |
|
|
kate522
|
07c4e969c3
|
新增全局流水号
|
2026-08-25 05:33:01 +08:00 |
|