Q1: 两边必须同时成功吗？还是允许中间状态？
Q2: 中间状态持续多久？如果是几毫秒，用户看得见吗？
Q3: 失败了能不能补偿？补偿的业务成本是多少？

// chain-cloud-ms-web-customer OmsServiceImpl#cancel
@GlobalTransactional
@Override
public void cancel(Long id) {
    // 更新订单（OMS 库）
    orderFeign.updateStatus(ListUtil.of(id), OrderStatusEnum.CANCELLED.getCode());

    // 查询取派件任务（work 库）
    List<PickupDispatchTaskDTO> pickupDispatchTaskDTOS =
            pickupDispatchTaskFeign.findByOrderId(id, PickupDispatchTaskTypeEnum.PICKUP);
    if (CollUtil.isEmpty(pickupDispatchTaskDTOS)) {
        // 暂未生成取件任务
        log.info("{}订单暂无取派件任务", id);
        return;                              // ← 提前返回，正常提交
    }

    // 更新取件任务（work 库）
    PickupDispatchTaskDTO taskDTO = pickupDispatchTaskDTOS.get(0);
    taskDTO.setStatus(PickupDispatchTaskStatusEnum.CANCELLED);
    taskDTO.setCancelReason(PickupDispatchTaskCancelReasonEnum.CANCEL_BY_USER);
    pickupDispatchTaskFeign.updateStatus(taskDTO);
}

BEGIN
  INSERT cc_order          ← 本地事务
COMMIT
sendMsg(delay = 5s)        ← 事务外，失败落库补偿

// chain-cloud-ms-driver-service DriverJobServiceImpl#intoStorage
@Override
@GlobalTransactional
public void intoStorage(DriverDeliverDTO driverDeliverDTO) {
    // 1. 查作业单
    DriverJobEntity driverJob = super.getById(driverDeliverDTO.getId());
    if (ObjectUtil.isEmpty(driverJob)) {
        throw new CCException(DriverJobExceptionEnum.DRIVER_JOB_NOT_FOUND);
    }

    // 2. 状态机校验：只有"运输中"的作业单才能入库
    if (ObjectUtil.notEqual(driverJob.getStatus(), DriverJobStatusEnum.PROCESSING)) {
        throw ...;              // 状态不对 → 拒绝（幂等的第二道）
    }
    Long transportTaskId = driverJob.getTransportTaskId();

    // 3. 加锁：只能有一个司机操作
    String lockRedisKey = Constants.LOCKS.DRIVER_JOB_LOCK_PREFIX + transportTaskId;
    RLock lock = this.redissonClient.getFairLock(lockRedisKey);
    if (lock.tryLock()) {
        try {
            TransportTaskDTO transportTask = this.transportTaskFeign.findById(transportTaskId);

            // 4. 业务短路：任务已结束就直接返回（不是抛异常，是正常提交）
            if (ObjectUtil.equalsAny(transportTask.getStatus(),
                    TransportTaskStatusEnum.CANCELLED,
                    TransportTaskStatusEnum.COMPLETED)) {
                return;          // ← 幂等的第三道：已结束，提交而非回滚
            }

            // 5. 真正的业务：更新运单 + 完成任务
            this.transportOrderFeign.updateByTaskId(String.valueOf(transportTaskId));
            this.transportTaskFeign.completeTransportTask(transportTaskCompleteDTO);
        } finally {
            lock.unlock();      // ← 注意 finally 的位置：在 if 里面
        }
    } else {
        throw new CCException(DriverJobExceptionEnum.DRIVER_JOB_INTO_STORAGE_ERROR);
    }
    ...
}

第 1 道：分布式锁（Redisson 公平锁）
  作用：同一时刻只有一个线程能进入临界区
  解决：并发请求同时修改同一条数据
  粒度：lockKey = "DRIVER_JOB_LOCK_" + transportTaskId   （按运输任务粒度）

第 2 道：状态机前置校验
  作用：进入业务前先判断当前状态合不合法
  解决：顺序问题（用旧状态做了决策）
  实现：if (status != PROCESSING) throw

第 3 道：业务短路（关键！）
  作用：锁拿到后、真正改数据前，再查一次下游状态
  解决：跨服务场景下的"已结束"判定
  实现：if (status in {CANCELLED, COMPLETED}) return;   ← 注意是 return 不是 throw

if (已结束) {
    return;                    // ✅ 正常提交
}

if (已结束) {
    throw new CCException("任务已结束");   // ❌ 会触发 Seata 全局回滚
}

RLock lock = this.redissonClient.getFairLock(lockRedisKey);

// driver 服务：无参（不等待，拿不到就返回 false）
if (lock.tryLock()) { ... }

// trade 服务：有等待时间，无 leaseTime
if (lock.tryLock(TradingCacheConstant.REDIS_WAIT_TIME, TimeUnit.SECONDS)) { ... }

一阶段：
  业务 SQL 正常执行 → 本地提交
  同时记录"前后镜像"到 undo_log 表：
    id | branch_id | xid | table_name | pk | before_image | after_image

二阶段（成功）：
  删除 undo_log 记录

二阶段（失败）：
  校验当前数据 vs after_image 是否被其它事务改过
    ├─ 未被改过 → 用 before_image 回滚（UPDATE 回去）→ 删 undo_log
    └─ 被改过  → 人工介入（这是 AT 的脏写问题）

Q: 两边的数据必须"同时"可见吗？
  ├─ 是 → Q: 允许中间态存在多久？
  │        ├─ 不能有任何中间态 → Seata AT / TCC
  │        └─ 可以有几秒/几分钟 → 本地事务 + MQ（最终一致）
  └─ 否（可以异步） → 本地事务 + MQ

Q: 失败之后能不能接受"人工介入"？
  ├─ 不能 → 强一致
  └─ 能   → 补偿表 + 定时对账（成本低很多）

本地事务：把退款单置为"退款中" + 累加退款金额 → 提交
  ↓
异步：调微信退款接口
  ↓
回调/轮询：把退款单置为"成功"或"失败"
  ↓
对账任务：扫描长时间"退款中"的单，人工或自动处理

// chain-cloud-ms-web-courier TaskServiceImpl#pickup
@GlobalTransactional
@Override
public boolean pickup(TaskPickupVO vo) {
    var taskDTO = pickupDispatchTaskFeign.findById(Long.valueOf(vo.getId()));
    if (ObjectUtil.notEqual(taskDTO.getStatus(), PickupDispatchTaskStatusEnum.NEW)) {
        throw new CCWebException("快递必须是未取状态！");     // ← 状态校验
    }
    ...
    orderFeign.orderPickup(orderPickupDTO);                 // OMS 本地事务
    ...
    this.mqFeign.sendMsg(Constants.MQ.Exchanges.COURIER,     // ← MQ 发送
                         Constants.MQ.RoutingKeys.COURIER_PICKUP, msg);
    return true;
}

1. Feign 调用顺序：先改 work 任务状态，再改 OMS 订单状态，再发 MQ
2. Seata 全局事务覆盖了 1 和 2（两个 DB）
3. ★ 但是 MQ 不是 Seata 管辖的资源
4. 假设第 2 步失败：
   → Seata 回滚 work 和 OMS 的数据库 ✅
   → 但第 3 步的 MQ 已经发出去了 ❌ 不会撤回
   → 下游收到"快递员已揽收"的消息，但它去查订单，订单还是"待取件"
   → 数据不一致，且这条消息无法撤回

@Transactional
public boolean pickup(TaskPickupVO vo) {
    orderFeign.orderPickup(dto);

    // 消息和业务数据在同一个本地事务里写！
    TaskMessage msg = TaskMessage.builder()
            .msgId(UUID.randomUUID().toString())
            .exchange(Constants.MQ.Exchanges.COURIER)
            .routingKey(Constants.MQ.RoutingKeys.COURIER_PICKUP)
            .payload(json)
            .status("PENDING")          // 待发送
            .build();
    taskMessageMapper.insert(msg);     // ← 和业务数据同一个事务
    return true;
}

// 独立的调度任务轮询发送
@Scheduled(fixedDelay = 1000)
public void scanAndSend() {
    List<TaskMessage> list = taskMessageMapper.selectPending(100);
    for (TaskMessage m : list) {
        try {
            mqService.sendMsg(m.getExchange(), m.getRoutingKey(), m.getPayload());
            m.setStatus("SENT");
            taskMessageMapper.update(m);
        } catch (Exception e) {
            m.setRetryCount(m.getRetryCount() + 1);
            if (m.getRetryCount() > 10) m.setStatus("DEAD");
            taskMessageMapper.update(m);
        }
    }
}

@Transactional
public boolean pickup(TaskPickupVO vo) {
    orderFeign.orderPickup(dto);
    publisher.publishEvent(new CourierPickedUpEvent(orderId));   // 发领域事件
    return true;
}

// 监听器：只在本地事务真正提交后才执行
@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
public void onPickedUp(CourierPickedUpEvent event) {
    mqService.sendMsg(EXCHANGE, KEY, buildMsg(event));
}

// chain-cloud-ms-trade-service BasicPayServiceImpl#refundTrading
String key = TradingCacheConstant.REFUND_PAY + tradingOrderNo;
RLock lock = redissonClient.getFairLock(key);
try {
    if (lock.tryLock(TradingCacheConstant.REDIS_WAIT_TIME, TimeUnit.SECONDS)) {
        // ... 业务
        return true;
    }
    throw new CCException(TradingEnum.NATIVE_QUERY_FAIL);      // tryLock 返回 false 时走到这
} catch (CCException e) {
    throw e;
} catch (Exception e) {
    log.error(...);
    throw new CCException(TradingEnum.NATIVE_QUERY_FAIL);
} finally {
    lock.unlock();          // ← 不管有没有拿到锁，都会执行
}

if (lock.tryLock(...)) { ... return true; }
throw new CCException(...);       // 抛出 → 进入 finally → lock.unlock()
// 但这把锁根本不是当前线程持有的！
// → Redisson 抛 IllegalMonitorStateException
// → 这个异常会【覆盖】掉原来要抛的 CCException

boolean locked = false;
try {
    locked = lock.tryLock(WAIT_TIME, TimeUnit.SECONDS);
    if (locked) {
        // 业务
        return true;
    }
    throw new CCException(TradingEnum.NATIVE_QUERY_FAIL);
} finally {
    if (locked && lock.isHeldByCurrentThread()) {
        lock.unlock();
    }
}

if (lock.tryLock()) {
    try {
        // 业务
    } finally {
        lock.unlock();      // ← 在 if 里面，只在拿到锁时才解锁
    }
} else {
    throw new CCException(...);
}

// 统一的锁模板，杜绝这类错误
public <T> T withLock(String key, Duration wait, Supplier<T> action) {
    RLock lock = redissonClient.getFairLock(key);
    boolean locked = false;
    try {
        locked = lock.tryLock(wait.toMillis(), TimeUnit.MILLISECONDS);
        if (!locked) throw new CCException(AcquireLockFailedException, key);
        return action.get();
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
        throw new CCException("获取锁被中断", e);
    } finally {
        if (locked && lock.isHeldByCurrentThread()) lock.unlock();
    }
}

// MailingSaveDTO 的完整字段
sendAddress, receiptAddress, pickUpTime, pickupType, payMethod,
goodsType, goodsName, goodNum, totalVolume, totalWeight,
measureLong, measureWidth, measureHigh, mark, memberId
// ↑ 没有 requestId，没有 idempotentKey，没有 orderNo

// 第 1 层：前端幂等键（最标准）
// 客户端生成一个 requestId（UUID），下单时带上
// 服务端按 (memberId, requestId) 唯一索引拦截

// 第 2 层：短时间窗口去重（Redis）
// key = "ORDER_SUBMIT_" + memberId + "_" + 寄收地址哈希
// TTL 30 秒，命中就返回上次的结果（注意不是报错，而是返回同一个订单）
public OrderDTO mailingSave(MailingSaveDTO dto) {
    String key = "ORDER_SUBMIT:" + dto.getMemberId() + ":"
               + DigestUtils.md5Hex(dto.getSendAddress() + dto.getReceiptAddress());
    RLock lock = redissonClient.getFairLock(key);
    try {
        if (lock.tryLock()) {
            // 双重检查：拿到锁后再查一次
            OrderDTO existing = findRecentOrder(dto, 30, TimeUnit.SECONDS);
            if (existing != null) {
                return existing;      // ← 返回已有订单，而不是报错
            }
            return doMailSave(dto);
        }
        throw new CCException("订单正在提交中，请勿重复操作");
    } finally {
        if (lock.isHeldByCurrentThread()) lock.unlock();
    }
}

// 第 3 层：业务唯一键兜底
// 对强幂等要求的场景（比如支付回调），靠数据库唯一索引

@Test
void Seata全局事务有效性验证() {
    // 1. 确认 XID 传递：让某个服务把 XID 打印出来
    //    Seata 的 RootContext.bind(xid) 之后，Feign 会自动传播

    // 2. 构造回滚场景
    //    在 work 的 updateStatus 里加一个测试专用的开关：
    //    if (System.getProperty("test.fail.after.update") != null) throw new RuntimeException();

    // 3. 断言：
    //    - OMS 的 cc_order.status 应该还是原值（回滚了）
    //    - work 的 cc_pickup_dispatch_task.status 应该还是原值
    //    - 如果两个都改了 → 说明 Seata 没生效
}

Q1: 中间状态用户看得见吗？
Q2: 能接受这个中间状态持续多久？
Q3: 失败了能不能补偿？

一阶段：业务 SQL 正常执行并提交，同时把数据的前后镜像写进 undo_log
二阶段成功：删 undo_log
二阶段失败：拿 before_image 回滚，但要先【校验 after_image 没被别人改过】
           —— 这个校验需要持有全局锁

第 1 道：分布式锁（Redisson 公平锁）
  解决【并发】—— 同一时刻只有一个请求进入临界区
  为什么要公平锁：司机端是高频操作，非公平锁会导致某些请求长期抢不到而饿死

第 2 道：状态机前置校验
  解决【顺序】—— 用旧状态做了不该做的决策
  实现：if (status != PROCESSING) throw

第 3 道：业务短路（最重要，也最容易做错）
  解决【跨服务的最终判定】
  实现：拿到锁后再查一次下游，已结束就直接 return
  ★ 必须 return 而不是 throw —— 因为 throw 会触发 Seata 回滚整个全局事务，
    把一个"重复提交"变成了"破坏性回滚"

先问：这个中间态业务能接受吗？
能接受 → 本地事务 + 业务消息表（outbox）+ 定时补偿

// 与其：Seata 保证订单和任务同时取消
// 不如：任务表加一个"订单状态"冗余字段，
//      所有状态变更走【条件更新】，天然幂等且可重试
UPDATE cc_pickup_dispatch_task
SET status = 'CANCELLED'
WHERE order_id = ? AND status = 'NEW'

web-* BFF  →  order-orchestrator（专门的编排服务）
                  ├── @GlobalTransactional
                  ├── 只做编排，不含业务逻辑
                  └── 可以独立扩缩容、独立降级