Files
junhong_cmp_fiber/migrations
break ba0855d9eb feat(退款): AUG26-006 退款方式选择与原路退款
按 PRD 2.3/2.4/2.5 落地套餐退款的方式矩阵与原路渠道退款:

- 退款申请派生并冻结权威实收金额(线上取原成功支付记录,钱包/线下取订单实际收款),
  提交人不可填写或修改;按来源支付方式生成可选方式矩阵并在创建、提交、执行前重复校验。
- 审批切换为「每次提交一条不可变审批尝试记录 + 独立企业微信审批实例」,业务标识取尝试
  记录主键;终态消费按尝试记录优先、退款申请兜底双读,兼容存量无实例与已关联实例申请。
  新增活动退款部分唯一索引 (order_id) WHERE status IN (1,5,6)。
- 本地人工终审保持既有开关,补齐通过入口的 approval_instance_id IS NULL 守卫,使三个
  入口一致拒绝已关联审批实例的申请;重提按尝试模式重写(仅已拒绝/已退回/原路失败且无异常)。
- 权益时点:企微通过事务写退款终态、按方式确定的订单态、钱包回款、员工账单冲销与可靠
  失效事实;套餐失效/接续/停机仍由既有可靠机制最终一致执行,不把外部调用放入资金事务。
  订单支付状态按方式置位:凭证退款与退回原钱包在企微通过时置已退款,原路须渠道明确成功。
- 按官方契约实现微信直连 v3、微信 v2(双向证书)、富友(/commonRefund 与 /refundQuery)、
  支付宝四类原路退款;能力只由服务商类型与退款必需凭证完整性决定,无人工开关。
  渠道请求号在提交时冻结到尝试记录,并以 channel_submitted_at 条件认领保证资金动作至多
  提交一次(重复投递只查询不二次提交);不向任何渠道传递退款结果通知地址。
- 新增 refund:channel:recovery 恢复任务只查询回填;本地查询窗口超期(富友 72 小时、
  微信 v2 7 天)转原路退款失败、渠道状态已失败、分类超时未知并置异常转人工,不放行自动
  重提以避免重复退款。
- 同步退款 DTO/导出/审计资源与审计查询关联、商户凭证文档,并修正 fuiou 集成契约文档。

迁移 000218(退款尝试与渠道退款事实)、000219(微信 v2 客户端证书凭证)成对提供,
未修改既有迁移;测试库 junhong_cmp_test 完成 up/down/up 与行为核对,未调用真实渠道。
2026-09-14 11:55:16 +08:00
..
2026-08-06 09:35:00 +08:00
2026-08-06 09:35:00 +08:00

数据库迁移说明

当前结构

migrations/
├── 000114_squash_baseline.up.sql   ← ⚠️ 待创建(见下方说明)
├── 000114_squash_baseline.down.sql ← ⚠️ 待创建
├── 000115_init_data.up.sql         ← 初始化数据(轮询配置 + purchase_role 回填)
├── 000115_init_data.down.sql
├── 000116_remove_legacy_commission_fields.up.sql  ← 删除废弃分佣字段
├── 000116_remove_legacy_commission_fields.down.sql
└── archive/                        ← 已归档的历史迁移000000~000113

⚠️ 发布前必做:生成 000114 squash 基线

背景历史迁移000000-000113已归档但尚未生成汇总基线文件。 现有测试环境的表是在 migrate 工具之外创建的,不受影响。 但全新环境本地搭建、CI、生产首次部署必须有 000114 才能通过 migrate up 建表。

执行时机:正式发布前,确认 schema 已稳定后执行一次。

步骤

  1. 安装 PostgreSQL 客户端(若未安装):

    brew install libpq
    export PATH="/opt/homebrew/opt/libpq/bin:$PATH"
    
  2. 生成 schema 基线(仅 DDL不含数据

    PGPASSWORD=<密码> pg_dump \
      --schema-only --no-owner --no-acl \
      -h <host> -U <user> -d <dbname> \
      > migrations/000114_squash_baseline.up.sql
    
  3. 在生成的 000114_squash_baseline.up.sql 头部加上注释(参考其他迁移文件格式)。

  4. 创建 000114_squash_baseline.down.sql(删除所有表):

    -- 回滚:删除所有业务表(谨慎执行)
    DROP TABLE IF EXISTS tb_wechat_config CASCADE;
    DROP TABLE IF EXISTS tb_tag CASCADE;
    -- ... 其他表(按依赖倒序)
    
  5. 找 AI 协助完成 down.sql 和验证步骤(在全新数据库执行 migrate up 验证链路)。

  6. 更新 scripts/reset_db.sh 中的注释,确认脚本可用。

迁移链路(目标状态)

全新数据库
  └─ migrate up
       ├─ 000114: 建表squash 基线)
       ├─ 000115: 写初始化数据
       └─ 000116: 删除废弃字段

现有测试环境说明

测试环境的表通过历史方式创建,schema_migrations 中仅记录版本 116。 对正在运行的服务没有影响。 若需在测试库补齐迁移记录,可手动运行 migrate up000115 全部幂等,安全)。