简介：这是一套用 Golang 编写的四方支付系统完整源码，面向具备一定后端基础、希望深入理解支付业务链路的开发者与二次开发团队。四方支付平台连接商户、消费者、银行及第三方支付机构，源码覆盖订单创建、支付接口调用、状态同步、退款处理等核心环节，适合用于学习支付系统架构或搭建自有支付服务。压缩包共 154 个文件，约 2.09MB，以 vue 前端页面、js 脚本、png 与 svg 图标资源、scss 样式为主，另含 go 主程序、conf 配置、Dockerfile 与 nginx 配置等部署文件，前后端结构相对完整。目前已有 1006 人学习下载。通过研读这套源码，读者可掌握 Go 语言在高并发支付场景下的并发模型与内存管理实践，理解支付网关、订单模块与渠道对接的设计模式，并借助配置文件与容器化脚本快速完成本地部署与调试，对提升后端支付领域开发能力有实际参考价值。
1. 一套 Golang 四方支付系统源码：从「能跑」到「敢收单」之间差了什么
很多人拿到一套 Golang 四方支付系统源码，第一反应是go build跑起来，看到后台能登录、订单能创建，就觉得这事成了。真到接商户、跑真实资金流的时候才发现，问题全在后面：回调没验签被伪造、订单状态和渠道状态对不上、对账文件解析错位、并发下单把同一个商户号余额扣穿。四方支付系统本质是一个「资金信息中转 + 状态机 + 对账」的系统，Golang 在这里的价值是高并发下的稳定性和部署简单，但语言本身不解决业务正确性。
这套源码适合两类人：一类是想自建聚合收款能力的技术负责人，需要判断这套东西能不能改造成生产可用；另一类是接手了别人交付的支付系统、要把它从 demo 推到线上的工程师。下面按「架构怎么读 → 核心链路怎么写 → 对账怎么做 → 坑在哪 → 怎么验证」的顺序拆，代码和参数都给到能直接抄的程度。热搜里常提的 golang 八股文、源码剖析与架构实战，放到支付系统里其实就一句话：并发安全和状态一致性，这两点没做对，其他都是花架子。
2. 先读懂这套 Golang 四方支付系统的分层与资金流
2.1 四方支付系统的角色和资金流到底怎么走
先把角色理清楚，不然读源码会迷路。典型四方支付系统里有四个角色：商户（发起收款请求）、平台（这套源码本身）、上游渠道（真正处理资金的第三方或银行通道）、用户（付款人）。资金流是：用户付款 → 上游渠道收款 → 渠道回调平台 → 平台回调商户 → 平台与商户、平台与渠道分别结算。注意平台本身通常不碰资金池，它做的是信息流和状态流的编排，这一点决定了源码里最核心的表是订单表和流水表，而不是账户余额表。
一套健康的源码，目录结构一般长这样：cmd/放启动入口，internal/放业务逻辑，pkg/放通用工具，configs/放配置，migrations/放建表 SQL。读的时候先看internal/order（订单）、internal/channel（渠道适配）、internal/notify（回调）、internal/reconcile（对账）这四个包，支付系统的命脉全在这。如果源码里渠道逻辑和订单逻辑糊在一个文件里，说明抽象没做好，改造量会很大。
2.2 订单状态机：源码里最该先看懂的一张表
订单状态机是四方支付系统的骨架。常见状态有：created（已创建）、paying（支付中）、success（支付成功）、failed（支付失败）、closed（已关闭）、refunded（已退款）。状态流转必须是单向的、可审计的，任何「从 success 改回 paying」的操作都是 bug。看源码时重点找状态变更函数，正常写法是把状态变更收敛到一个方法里，带乐观锁版本号。
-- 订单表核心字段，注意 version 和 channel_order_no CREATE TABLE `pay_order` ( `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, `merchant_no` VARCHAR(32) NOT NULL COMMENT '商户号', `merchant_order_no` VARCHAR(64) NOT NULL COMMENT '商户订单号', `platform_order_no` VARCHAR(64) NOT NULL COMMENT '平台订单号', `channel_code` VARCHAR(32) NOT NULL COMMENT '渠道编码', `channel_order_no` VARCHAR(64) DEFAULT NULL COMMENT '上游订单号', `amount` BIGINT NOT NULL COMMENT '金额，单位分', `status` TINYINT NOT NULL DEFAULT 0 COMMENT '0创建 1支付中 2成功 3失败 4关闭', `version` INT NOT NULL DEFAULT 0 COMMENT '乐观锁版本', `notify_status` TINYINT NOT NULL DEFAULT 0 COMMENT '商户回调状态', `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_platform_order_no` (`platform_order_no`), UNIQUE KEY `uk_merchant_order` (`merchant_no`, `merchant_order_no`), KEY `idx_channel_order_no` (`channel_order_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;金额用BIGINT存分，不要用DECIMAL或浮点，浮点在并发累加时会出现精度玄学。uk_merchant_order这个唯一索引是防重复下单的第一道闸，很多源码漏了它，结果商户重试就生成两笔订单。channel_order_no单独建索引，因为对账和回调查询全靠它。
2.3 渠道适配层：为什么必须做接口抽象
上游渠道少则三五个，多则几十个，每个渠道的下单接口、签名方式、回调格式都不一样。如果源码里用if channel == "alipay" { ... } else if channel == "wxpay" { ... }这种写法，加一个渠道就要改一遍主流程，迟早翻车。正确做法是定义统一接口，每个渠道实现自己的适配器。
// 渠道适配统一接口，放在 internal/channel 包 type Channel interface { // 下单，返回上游订单号和支付参数 CreateOrder(ctx context.Context, req *CreateOrderReq) (*CreateOrderResp, error) // 查询订单，用于主动补偿 QueryOrder(ctx context.Context, platformOrderNo string) (*QueryOrderResp, error) // 验签回调，返回解析后的统一结构 VerifyNotify(ctx context.Context, raw []byte, headers map[string]string) (*NotifyData, error) // 发起退款 Refund(ctx context.Context, req *RefundReq) (*RefundResp, error) } type CreateOrderReq struct { PlatformOrderNo string Amount int64 // 分 Subject string NotifyURL string Extra map[string]string }接口里Amount统一用int64分，NotifyURL由平台生成而不是商户传，避免商户传错地址导致回调丢失。Extra放渠道特有参数，比如某些渠道要传商品类目。实现时每个渠道一个文件，注册到一张 map 里，主流程只依赖接口。这样加渠道就是加文件加注册，不动主流程，这是判断一套源码能不能长期维护的关键。
3. 核心链路落地：下单、回调、幂等三件事怎么写
3.1 下单接口：从参数校验到落库的完整代码
下单是入口，也是最容易出并发问题的地方。完整流程是：验签商户请求 → 参数校验 → 幂等检查 → 生成平台订单号 → 落库 → 调渠道下单 → 更新渠道订单号。每一步都要能失败回滚或补偿。
func (s *OrderService) CreateOrder(ctx context.Context, req *CreateOrderReq) (*CreateOrderResp, error) { // 1. 商户签名校验，防止伪造请求 if err := s.verifyMerchantSign(req); err != nil { return nil, ErrSignInvalid } // 2. 金额必须为正，且不超过商户单笔限额 if req.Amount <= 0 || req.Amount > s.limitOf(req.MerchantNo) { return nil, ErrAmountInvalid } // 3. 幂等：先查是否已存在同商户订单号 if exist, err := s.repo.GetByMerchantOrderNo(ctx, req.MerchantNo, req.MerchantOrderNo); err == nil && exist != nil { return buildResp(exist), nil // 直接返回原订单，不重复下单 } // 4. 生成平台订单号并落库，状态 created order := &Order{ MerchantNo: req.MerchantNo, MerchantOrderNo: req.MerchantOrderNo, PlatformOrderNo: genPlatformOrderNo(), ChannelCode: req.ChannelCode, Amount: req.Amount, Status: StatusCreated, } if err := s.repo.Insert(ctx, order); err != nil { // 唯一索引冲突说明并发重复，回查返回 if isDuplicate(err) { old, _ := s.repo.GetByMerchantOrderNo(ctx, req.MerchantNo, req.MerchantOrderNo) return buildResp(old), nil } return nil, err } // 5. 调渠道下单，失败则标记订单失败 ch := s.channelMgr.Get(req.ChannelCode) resp, err := ch.CreateOrder(ctx, toChannelReq(order)) if err != nil { _ = s.repo.UpdateStatus(ctx, order.PlatformOrderNo, StatusFailed, 0) return nil, err } // 6. 回写渠道订单号，状态置为 paying _ = s.repo.UpdateChannelOrderNo(ctx, order.PlatformOrderNo, resp.ChannelOrderNo, StatusPaying) return buildResp(order), nil }关键点在第三步和第四步的双重幂等：先查一次减少无谓插入，靠唯一索引兜底并发。genPlatformOrderNo建议用「时间戳 + 商户号后四位 + 随机数」，不要用纯自增，避免被遍历。第五步渠道失败要落失败状态，不能只返回错误不落库，否则订单永远停在 created，对账时对不上。UpdateStatus带 version 参数做乐观锁，防止并发覆盖。
3.2 回调处理：验签、幂等、状态机三重防护
回调是资金确认的唯一可信来源，也是最容易被攻击的入口。处理顺序必须是：先验签 → 再幂等 → 再改状态 → 最后异步通知商户。顺序错了就是血泪教训。
func (s *NotifyService) HandleChannelNotify(ctx context.Context, channelCode string, raw []byte, headers map[string]string) error { ch := s.channelMgr.Get(channelCode) // 1. 验签，失败直接拒绝，不落任何数据 data, err := ch.VerifyNotify(ctx, raw, headers) if err != nil { return ErrNotifySignInvalid } // 2. 幂等：同一笔渠道订单只处理一次 if ok, _ := s.redis.SetNX(ctx, "notify:lock:"+data.ChannelOrderNo, 1, 10*time.Minute); !ok { return nil // 已处理过，直接返回成功，避免渠道重推 } // 3. 查订单，校验金额一致，防止篡改 order, err := s.repo.GetByChannelOrderNo(ctx, data.ChannelOrderNo) if err != nil { return err } if order.Amount != data.Amount { return ErrAmountMismatch } // 4. 状态机流转，只有 paying 才能转 success if err := s.repo.UpdateStatusCAS(ctx, order.PlatformOrderNo, StatusPaying, StatusSuccess, order.Version); err != nil { return err // 状态不对说明重复或异常，交给对账兜底 } // 5. 异步通知商户，失败进重试队列 s.notifyQueue.Push(order.PlatformOrderNo) return nil }SetNX做幂等锁，key 用渠道订单号，过期时间给 10 分钟足够覆盖渠道重推窗口。金额校验不能省，曾经见过渠道回调金额被中间人改大导致多记账的案例。UpdateStatusCAS是带原状态和版本号的 CAS 更新，只有当前是 paying 才允许转 success，这样即使锁失效重复进来，第二次也会因为状态已是 success 而失败，天然幂等。通知商户走异步队列，不要同步等商户响应，商户接口慢会拖垮回调线程。
3.3 通知商户：重试策略和签名怎么设计
通知商户是平台对外的最后一步，做不好商户会说「你没通知我」。策略是：立即通知一次，失败后按 1min、5min、15min、30min、1h、2h、6h 退避重试，最多 8 次，仍失败则标记为需人工介入。每次通知都带签名，签名串包含订单号、金额、状态、时间戳，商户侧用同样规则验签。
func (s *NotifyService) notifyMerchant(ctx context.Context, order *Order) error { body := map[string]interface{}{ "merchant_order_no": order.MerchantOrderNo, "platform_order_no": order.PlatformOrderNo, "amount": order.Amount, "status": "success", "timestamp": time.Now().Unix(), } // 按 key 字典序拼接后加商户密钥做 HMAC-SHA256 sign := signMD5OrHMAC(body, s.merchantSecret(order.MerchantNo)) body["sign"] = sign resp, err := s.httpClient.PostJSON(ctx, order.NotifyURL, body, 5*time.Second) if err != nil || resp.Code != "SUCCESS" { return s.retryQueue.PushWithBackoff(order.PlatformOrderNo) } return s.repo.MarkNotified(ctx, order.PlatformOrderNo) }超时给 5 秒，商户接口正常都在几百毫秒内。签名用 HMAC-SHA256 比裸 MD5 安全，密钥每个商户独立。重试队列建议用 Redis 的 ZSet 按时间戳排序，worker 轮询到期任务，比内存队列可靠，重启不丢。
4. 对账与补偿：让账目自己说话
4.1 对账文件的下载、解析与比对
对账是四方支付系统的后悔药。每天定时拉取上游渠道的对账文件，解析后和本地订单逐笔比对，找出「本地成功渠道没有」「渠道成功本地没有」「金额不一致」三类差异。文件格式各渠道不同，常见是 CSV 或定长文本。
func (s *ReconcileService) Reconcile(ctx context.Context, channelCode, billDate string) error { // 1. 下载对账文件 localPath, err := s.channelMgr.Get(channelCode).DownloadBill(ctx, billDate) if err != nil { return err } // 2. 解析成统一结构 records, err := parseBillFile(localPath) if err != nil { return err } // 3. 拉取本地当日成功订单 localOrders, _ := s.repo.ListSuccessByDate(ctx, channelCode, billDate) localMap := indexByChannelOrderNo(localOrders) // 4. 逐笔比对 var diffs []Diff for _, r := range records { lo, ok := localMap[r.ChannelOrderNo] if !ok { diffs = append(diffs, Diff{Type: "channel_only", Record: r}) continue } if lo.Amount != r.Amount { diffs = append(diffs, Diff{Type: "amount_mismatch", Local: lo, Channel: r}) } delete(localMap, r.ChannelOrderNo) } // 5. 剩下的本地订单就是 local_only for _, lo := range localMap { diffs = append(diffs, Diff{Type: "local_only", Local: lo}) } return s.repo.SaveDiffs(ctx, channelCode, billDate, diffs) }parseBillFile要处理编码问题，很多渠道给的是 GBK，直接按 UTF-8 读会乱码，用golang.org/x/text/encoding/simplifiedchinese转。比对用 map 索引，O(n) 复杂度，十万笔订单秒级完成。差异结果落库，人工处理界面按类型分组展示。
4.2 差异处理：三类差异分别怎么补
channel_only说明渠道收了钱但本地没记录，通常是回调丢失，处理方式是补单：根据渠道订单号反查商户订单号，补一条成功记录并触发商户通知。local_only说明本地记了成功但渠道没有，可能是渠道退款或本地状态错误，需要人工核实后决定是否冲正。amount_mismatch最危险，必须人工介入，不能自动改金额。
func (s *ReconcileService) FixChannelOnly(ctx context.Context, d Diff) error { // 补单前先确认本地确实没有 if _, err := s.repo.GetByChannelOrderNo(ctx, d.Record.ChannelOrderNo); err == nil { return nil } // 从渠道记录里取商户订单号，补一条成功订单 order := &Order{ MerchantNo: d.Record.MerchantNo, MerchantOrderNo: d.Record.MerchantOrderNo, PlatformOrderNo: genPlatformOrderNo(), ChannelOrderNo: d.Record.ChannelOrderNo, Amount: d.Record.Amount, Status: StatusSuccess, } if err := s.repo.Insert(ctx, order); err != nil { return err } s.notifyQueue.Push(order.PlatformOrderNo) return nil }补单必须记录操作日志，谁在什么时候补的、依据是什么，这是审计要求。补单接口要做权限控制，不能开放给普通运营。
4.3 主动查询补偿：回调没来怎么办
不能只等回调，要有主动查询兜底。对paying状态超过 5 分钟的订单，定时任务调渠道查询接口，查到成功就按回调逻辑处理。这个机制能覆盖大部分回调丢失场景。
func (s *CompensateJob) Run(ctx context.Context) { // 查 5 分钟前到 24 小时前的 paying 订单 orders, _ := s.repo.ListPayingBetween(ctx, time.Now().Add(-24*time.Hour), time.Now().Add(-5*time.Minute)) for _, o := range orders { ch := s.channelMgr.Get(o.ChannelCode) resp, err := ch.QueryOrder(ctx, o.PlatformOrderNo) if err != nil { continue // 查询失败下次再试 } if resp.Status == "SUCCESS" { _ = s.notifyService.HandleChannelNotify(ctx, o.ChannelCode, resp.Raw, nil) } } }查询频率别太高，渠道有频率限制，一般 1 分钟一轮，每轮限制并发数。24 小时还没成功的订单基本可以判定异常，转人工。
5. 这套源码最容易翻车的 5 个坑
5.1 坑一：回调没验签，被伪造通知刷单
现象：后台突然多出一批成功订单，但渠道对账文件里没有。原因：回调接口直接信任请求体，没做签名校验，攻击者构造 POST 请求就能把订单改成成功。解决：所有渠道回调必须先验签再处理，验签失败直接返回错误码，不落任何数据。验签逻辑放在渠道适配器里，主流程强制调用，不给绕过的机会。
5.2 坑二：订单状态用字符串且到处改
现象：同一笔订单在不同接口里状态值不一致，有的写success有的写SUCCESS，对账时匹配不上。原因：状态没有统一定义，各模块自己写字符串。解决：状态用常量或枚举统一定义，数据库存数字，对外转换。所有状态变更收敛到一个方法，禁止在业务代码里直接UPDATE status。
5.3 坑三：金额用浮点或元做单位
现象：对账时出现 0.01 元的差异，累加多了差几块钱。原因：金额用float64或DECIMAL存元，浮点运算有精度损失。解决：全链路用int64存分，接口出入参也是分，只在展示层转元。数据库字段用BIGINT，Go 结构体用int64，一处都不能漏。
5.4 坑四：回调处理同步等商户响应
现象：渠道回调超时，渠道重推，订单被处理多次。原因：回调处理里同步调商户通知接口，商户接口慢导致整个回调超时。解决：回调只做验签、幂等、改状态，商户通知丢异步队列。回调接口响应时间控制在 100ms 内，渠道才不会重推。
5.5 坑五：没有对账，全靠回调
现象：运行几个月后发现账对不上，但不知道从哪天开始错的。原因：只依赖回调，回调丢了没人知道。解决：每天定时对账，差异落库，人工处理。对账是最后一道防线，没有对账的支付系统等于裸奔。
6. 上线前怎么验证这套系统真的能用
验证分四层，从单元到全链路。第一层单元测试，重点测状态机流转和幂等逻辑，用表驱动覆盖所有状态组合。第二层集成测试，用渠道的沙箱环境跑完整下单到回调，验证签名和金额。第三层压测，用wrk或hey对下单接口打 1000 并发，看订单表有没有重复、状态有没有错乱。
# 用 hey 压测下单接口，1000 并发，共 10000 请求 hey -n 10000 -c 1000 -m POST \ -H "Content-Type: application/json" \ -d '{"merchant_no":"M001","merchant_order_no":"T'$(date +%s%N)'","amount":100,"channel_code":"test"}' \ http://127.0.0.1:8080/api/order/create压测后立刻查库：SELECT merchant_order_no, COUNT(*) FROM pay_order GROUP BY merchant_order_no HAVING COUNT(*) > 1;如果有结果说明幂等没做好。再查状态分布，看有没有卡在 paying 的订单。
第四层对账演练，手动造几笔差异：删掉一笔本地成功订单模拟channel_only，改一笔金额模拟amount_mismatch，跑对账任务看能不能正确识别。这一步很多人跳过，真出问题时才发现对账逻辑有 bug。
我自己的习惯是上线前必做一次「断网演练」：把渠道回调地址改成不可达，看主动查询补偿能不能在 10 分钟内把订单补成功。这个演练能暴露 80% 的补偿逻辑问题。支付系统没有后悔药，能提前演练的坑就别留到线上。希望帮到你。
本文还有配套的精品资源，点击获取
