Tigshop开源电商系统对接ERP：支付成功只推队列，回调里别硬刚

支付回调里 curl ERP？停。现在就停。慢了微信重试。重了订单状态乱。Tigshop开源电商系统那套支付幂等，会被你亲手拆掉。我见过同步打仓库，回调超时，订单卡在「支付中」——仓库那边货已经开始拣了。你说邪门不邪门。

ERP 对接不是 Tigshop 标配，是二开。但姿势要对：支付成功只推队列，别在回调里硬刚 HTTP。

正确姿势就一个

PaymentService::paySuccess() 里只丢队列：

<?php
use app\job\ErpPushJob;
use think\facade\Queue;

Queue::push(ErpPushJob::class, [
    'order_id' => $orderId,
    'event'    => 'paid',
]);

别在这儿写 HTTP。手别痒。

Job 里再说话

<?php
namespace app\job;

class ErpPushJob
{
    public function fire($job, $data)
    {
        $order = Order::find($data['order_id']);
        if (!$order || $order['erp_pushed']) {
            $job->delete();
            return;
        }
        $resp = ErpClient::pushPaidOrder($order);
        if ($resp['ok']) {
            Order::where('order_id', $order['order_id'])->update(['erp_pushed' => 1]);
            $job->delete();
        } else {
            $job->release(60);
        }
    }
}

签名、推送、日志、重试、补偿表。order_sn 去重。对方也要幂等。测试环境单独 ERP_BASE_URL。别推生产。

回写同理

验签，改状态，写运单。重复通知不能插两行物流。插两行，仓管会来找你喝茶。

白板比 IDE 重要

取消通不通知？部分退款怎么办？先画再写。代码漂亮、状态糊，一样翻车。补偿表加重推按钮。比手改状态香一百倍。第一周盯队列失败次数。别手改状态。手一改，债往后推。

对接方常犯的错

他们也在回调里同步打你们。两边互等，死锁。约定：你们推队列，他们异步消费。消费失败他们重试，别回调你们支付接口。文档写清楚。写不清楚，联调能拖一个月。一个月够你写十遍 Job 了。

监控

队列堆积、失败率、平均延迟。Admin 加一页「ERP 推送记录」，失败的一键重推。仓管催发货的时候，你能告诉他是 ERP 卡了还是商城卡了。能告诉，你就不是背锅侠。不能告诉，你就是背锅侠。