简介：多用户微信商城分销直销平台源码，基于ASP.NET(C#)与Webform技术栈，搭配SqlServer2008R2数据库，面向具备.NET基础的中小商户、系统集成商及希望快速切入微信商城分销的开发者。支持同时管理多个公众号，每号可配置5个子账号；功能覆盖关注回复、自定义菜单、客户管理、二维码链式推广、商城模板配置、商品与订单管理、订单及运单打印、微信支付V3.0等，并提供分销模板与直销模板两套模式。后台含导航菜单管理、大管理端（查看所有商户及子公众号、开启计费运维）与BI智能图表分析，形成完整微商城业务闭环。资源包共2000个文件，以cs源码、aspx页面、js/css前端脚本、jpg/png/gif图片素材及dll组件为主，另含SqlServer脚本和工程文件，整体大小67.24MB，目录按功能模块组织，便于部署和二次改造。已有652人学习下载，对需要直接获得多用户可扩展商城源码并深度定制分销逻辑的开发者，是实用的参考。

1. 你在找的ASPNET多用户微信商城分销直销源码，实际是这三块东西

老板们在微信里卖货，最早是拉群发通告，卖到上千单之后，人肉对账和手写佣金就成了灾难。ASPNET多用户微信商城分销直销平台源码，就是把三件事打包给你：一份跑在Windows服务器上的ASP.NET商城程序，一套支持多个商户或事业部独立运营的数据库结构，以及分销（发展下级拿返佣）与直销（按业绩阶梯拿奖励）两套结算引擎。对创业者来说，它可以少写几万行业务代码；对接.NET外包的开发者来说，它是现成的返佣算法参考；对想在微信里靠老带新做增长的运营来说，这个方向能不能接，最终取决于你能不能把返佣账对平。这篇笔记从选型、表结构、返佣算法、支付回调、上线避坑五条线展开。

2. 技术选型与架构：为什么“分销直销”这类源码大多是ASP.NET而不是Java

2.1 技术栈现实：老商城源码与新项目的选择分岔

在网上搜“多用户商城源码”，结果里经常出现两类：一类是ASP.NET的Web Forms或MVC 4/5老项目，配套SQL Server；另一类是Java系的spring boot + mybatis多商户商城，前端用Vue3商城做SPA，部署要Linux、Redis、Docker一套。很多接单的人看到Java就先犹豫，因为运维和招人成本都重；而ASP.NET老商城往往一台Windows 2012以上的服务器就能跑，IIS发布后改个连接串就上线。微信支付的C#版本官方demo历史比Java长，所以2016到2019年那波微商城源码大多用.NET来写，分销树、佣金报表这些模块都是现成的，接手成本较低。

我的建议是分场景：要“快速跑起来、自己维护”，老ASP.NET是条捷径；预算充足、团队本来就会容器化，再考虑Java版本，否则会被部署环境拖慢。别迷信新框架，这套业务的核心是返佣与对账，不是框架版本号。项目如果要做微信小程序前端，常见做法是用uni-app打包小程序，后端接口还是挂在ASP.NET WebApi上，不影响整体结构。

2.2 多用户是租户隔离，不是管理员数量

“多用户”这三个字最容易误解。它不是指后台能建多个管理员账号，而是指多个商户或事业部共用一套系统，各自卖货、各自算账。常见做法是在核心业务表上加MerchantId字段。租户隔离一般有三种强度：单库共享表，适合刚起步；单库分Schema，适合几十个商户的中型平台；独立数据库，数据最安全但成本高，适合大平台。多数二手源码是第一种，因为查询最简单，报表也好写。

表结构上，Member、Product、OrderInfo这些表都带MerchantId，写代码时约定“所有数据访问查询强制拼接MerchantId”，否则就会串号。我一般还会在数据访问层统一封装一个QueryFilter，避免每个开发人员各自拼条件，拼漏一次线上就得翻车。多用户分销的佣金也要按MerchantId分开结算，不能把不同商户的会员混进同一条分销链。

2.3 分销与直销在设计上是不一样的东西

分销是“A介绍B，B下单给A返佣”，通常最多做两级：直接上级拿商品佣金比例的一部分，二级上级拿剩下的一小部分。直销是“按本人一段时间内的销售额提升佣金档位”，比如月销售额从5000元涨到5万元，佣金比例从5%提到10%。两者可以并存：订单支付后先按分销关系发一级、二级佣金，再把金额累计到直销业绩里。

规则必须做成可配置。商品表可以单独配CommissionRatio，Merchant表放一级佣金比例、是否启用二级、二级佣金比例，以及月直销目标档位。配置表的作用是以后运营调佣金时不需要改代码，直接在后台改数值。否则你上线一个月后发现某个商品毛利只有20%，分销佣金却给了18%，改代码再发布一次就太被动了。

2.4 架构分层：把返佣独立成服务，而不是塞在订单Controller里

ASP.NET老项目典型分层是：Controller（接口层）、BLL（业务层）、DAL（数据层）。分销计算建议单独做一个CommissionService，订单支付成功后由支付回调触发，不要在提交订单时就算佣金，因为订单还没付款，不能发钱。Service里做两件事：校验订单是否已支付且未结算，然后按规则写入佣金流水。

这样做的好处有三个：支付回调重复时可以安全重入；后台可以做一个“重新结算”按钮处理历史脏数据；后续就算订单量大，也能抽成定时任务扫描未结算订单。我见过太多把佣金计算直接写在OrderController里的代码，表面省事，实际上每次调整规则都要去翻接口，风险极高。设计上宁可多一个类，也别省这一层。

3. 数据库设计与返佣实现：先搭六张表，再写两级分销算法

3.1 用六张表撑起多用户商城分销直销的最小闭环

只要跑通“商户 → 商品 → 会员下单 → 支付回调 → 佣金入账”这条主链路，最核心的六张表就够了。建表脚本按SQL Server语法写，字段只用常用类型，便于理解。

-- 商户表：多用户隔离的第一道边界 CREATE TABLE Merchant ( Id INT IDENTITY(1,1) PRIMARY KEY, Name NVARCHAR(100) NOT NULL, DirectRatio DECIMAL(5,2) NOT NULL DEFAULT 10.00, EnableSecond BIT NOT NULL DEFAULT 1, SecondRatio DECIMAL(5,2) NOT NULL DEFAULT 5.00, MonthTargets NVARCHAR(500) NULL, -- JSON数组，如 [5000,20000,50000] MonthRatio NVARCHAR(500) NULL, -- JSON数组，如 [5,8,12] CreateTime DATETIME NOT NULL DEFAULT GETDATE() ); -- 会员表：自带上级关系和层级深度 CREATE TABLE Member ( Id INT IDENTITY(1,1) PRIMARY KEY, MerchantId INT NOT NULL REFERENCES Merchant(Id), OpenId NVARCHAR(64) NOT NULL, NickName NVARCHAR(100) NULL, ParentId INT NULL REFERENCES Member(Id), Depth INT NOT NULL DEFAULT 0, -- 0表示根会员，1为一级分销员，2为二级分销员 LockParentUntil DATETIME NULL, -- 锁定上级关系，防止恶意改绑 CreateTime DATETIME NOT NULL DEFAULT GETDATE() ); CREATE INDEX IX_Member_Merchant_OpenId ON Member(MerchantId, OpenId); -- 商品表：佣金比例可以按商品覆盖商户配置 CREATE TABLE Product ( Id INT IDENTITY(1,1) PRIMARY KEY, MerchantId INT NOT NULL REFERENCES Merchant(Id), Name NVARCHAR(200) NOT NULL, Price DECIMAL(10,2) NOT NULL, CommissionRatio DECIMAL(5,2) NULL, -- 为空则取商户默认比例 Stock INT NOT NULL DEFAULT 0, CreateTime DATETIME NOT NULL DEFAULT GETDATE() ); -- 订单主表：支付与结算状态分开维护 CREATE TABLE OrderInfo ( Id INT IDENTITY(1,1) PRIMARY KEY, OrderNo VARCHAR(32) NOT NULL UNIQUE, MerchantId INT NOT NULL REFERENCES Merchant(Id), MemberId INT NOT NULL REFERENCES Member(Id), TotalAmount DECIMAL(10,2) NOT NULL, PayStatus TINYINT NOT NULL DEFAULT 0, -- 0未支付，1已支付，2已退款 SettleStatus TINYINT NOT NULL DEFAULT 0, -- 0未结算，1已结算 PayTime DATETIME NULL, CallbackCount INT NOT NULL DEFAULT 0, -- 记录微信回调次数，排查重复 CreateTime DATETIME NOT NULL DEFAULT GETDATE() ); CREATE INDEX IX_OrderInfo_Settle ON OrderInfo(MerchantId, SettleStatus); -- 订单明细表：保存下单时的商品快照 CREATE TABLE OrderItem ( Id INT IDENTITY(1,1) PRIMARY KEY, OrderId INT NOT NULL REFERENCES OrderInfo(Id), ProductId INT NOT NULL, ProductName NVARCHAR(200) NOT NULL, -- 冗余商品名，防止商品后来改名 Price DECIMAL(10,2) NOT NULL, Quantity INT NOT NULL, CommissionRatio DECIMAL(5,2) NOT NULL DEFAULT 0 ); -- 佣金流水表：每一笔返佣都留痕 CREATE TABLE Commission ( Id INT IDENTITY(1,1) PRIMARY KEY, MerchantId INT NOT NULL, OrderNo VARCHAR(32) NOT NULL, FromMemberId INT NOT NULL, -- 下单人 ToMemberId INT NOT NULL, -- 拿佣金的人 Level TINYINT NOT NULL, -- 1一级佣金，2二级佣金，0直销奖励 Amount DECIMAL(10,2) NOT NULL, Status TINYINT NOT NULL DEFAULT 0, -- 0有效，1已冲正 ReversalLog NVARCHAR(500) NULL, -- 退款冲正原因 CreateTime DATETIME NOT NULL DEFAULT GETDATE() ); CREATE INDEX IX_Commission_Order ON Commission(OrderNo, Level);

参数说明：Depth字段放在Member表里，查询时直接用，不用递归算层级；LockParentUntil用来防止用户注册后反复改上级薅佣金。OrderInfo的SettleStatus和PayStatus是两个独立状态，前者管返佣结算，后者管支付退款，不能混用。Commission表里Level=0的用途是记录直销奖励，月度结算时生成。这六张表建立之后，主流程的SQL就能全部走索引。

3.2 注册时绑定分销关系：校验闭环和深度限制

会员注册或扫码进商城时，要绑定上级。这个动作必须放在存储过程或服务层里做，不能直接写一条INSERT完事，因为要同时校验商户一致性和层级深度。

CREATE PROCEDURE sp_BindMemberParent @MemberId INT, @ParentId INT AS BEGIN DECLARE @MerchantId INT, @ParentMerchantId INT, @ParentDepth INT; SELECT @MerchantId = MerchantId FROM Member WHERE Id = @MemberId; SELECT @ParentMerchantId = MerchantId, @ParentDepth = Depth FROM Member WHERE Id = @ParentId; -- 上级必须存在、商户必须一致、不能是自己、层级不能超过2 IF @ParentMerchantId IS NULL OR @ParentMerchantId <> @MerchantId OR @ParentId = @MemberId THROW 51000, '上级会员不存在或不属于当前商户', 1; IF @ParentDepth >= 2 THROW 51001, '超过最大分销层级，不允许绑定', 1; UPDATE Member SET ParentId = @ParentId, Depth = @ParentDepth + 1 WHERE Id = @MemberId; END;

逻辑说明：存储过程一次性完成四件事，查出当前会员和上级会员的商户、深度，当前会员的上级是自己时直接拒绝，深度大于等于2时抛出异常。这样即使将来有多个入口调用绑定逻辑，也不会出现绕过校验的情况。参数上要注意Depth上限是2，意味着根会员算0级，一级分销员Depth=1，其下线Depth=2，二级分销员不能再发展下级。这是从结算复杂度和风险两个角度都更稳妥的配置。

3.3 订单支付成功后的返佣计算

支付回调进来后，调用佣金服务。下面是核心方法，使用订单号做幂等键。

public bool TrySettleOrder(string orderNo, int merchantId) { using (var conn = new SqlConnection(_connString)) { conn.Open(); using (var tx = conn.BeginTransaction()) { // 一：把订单标记为结算中，防止并发重复进入 // 注意条件里带 SettleStatus = 0，影响行数为0说明已被处理 string updateSql = @" UPDATE OrderInfo SET SettleStatus = 1 WHERE OrderNo = @OrderNo AND MerchantId = @MerchantId AND SettleStatus = 0"; using (var cmd = new SqlCommand(updateSql, conn, tx)) { cmd.Parameters.AddWithValue("@OrderNo", orderNo); cmd.Parameters.AddWithValue("@MerchantId", merchantId); if (cmd.ExecuteNonQuery() == 0) return false; // 已结算，直接返回 } // 二：查订单明细，算出一级佣金 string itemSql = @" SELECT oi.CommissionRatio, oi.Price, oi.Quantity, o.MemberId, o.TotalAmount FROM OrderItem oi INNER JOIN OrderInfo o ON oi.OrderId = o.Id WHERE o.OrderNo = @OrderNo AND o.PayStatus = 1"; // 三：查下单会员以及其上级关系 string memberSql = @" SELECT m.MemberId, m.ParentId, p.ParentId AS GrandParentId FROM Member m LEFT JOIN Member p ON m.ParentId = p.Id WHERE m.MerchantId = @MerchantId AND m.Id = @MemberId"; // 四：按商品行计算佣金，插入Commission表，Level=1给直接上级，Level=2给二级上级 // 二级佣金比例取商户配置，计算基数为一级佣金之外的剩余部分 } } }

逻辑说明：先更新SettleStatus再查明细，是典型的“先占坑再干活”，用影响行数挡掉并发重复。第2步查订单明细里的CommissionRatio，这个比例是下单时从商品表快照过来的，后续后台改佣金不影响历史订单。第3步查出下单会员的ParentId和GrandParentId，如果为空，说明没有上级或只有一级，就不生成对应佣金。

参数上要特别注意：一级佣金按商品金额乘以CommissionRatio算；二级佣金是按商户的SecondRatio算，计算基础我习惯用“一级佣金计算基数减去一级佣金”，也就是先发大头，再发余量。这样两级佣金加起来不会超过商品毛利。还有一个细节，订单里如果同时有多个商品，每个商品按各自比例算，而不是按整单一个比例算，这样才对得上商品的实际毛利。

3.4 直销月度奖励：单独定时任务，别和订单回调掺在一起

直销奖励按月结算，常见做法是写一个SQL作业或定时任务，每月1号凌晨扫描上月已支付订单，按会员汇总销售额，再按商户配置的MonthTargets和MonthRatio计算档位，把差额写进Commission表，Level=0。为什么不能并到支付回调里？因为直销看的是月度累计，当月的每一单都要等整月结束才知道落到哪个档位。回调里就算，只能按当前档位预发，月底再补差，逻辑复杂且容易出错。定时任务出错的补救方式也更简单：删掉当月Level=0的流水，重新跑一次即可，不影响日常分销佣金。

4. 接入微信生态：OAuth登录、分享追踪与支付回调验签

4.1 微信网页授权OAuth2.0：拿到OpenId而不是拿手机号

微信商城第一个接口就是网页授权，目的是拿到用户的OpenId，OpenId才是整个分销关系里的用户主键。下面是一个极简的授权处理流程。

public ActionResult WxAuth(string code, string spm) { if (string.IsNullOrEmpty(code)) { // 第一次进来没有code，跳转到微信授权页 string redirect = HttpUtility.UrlEncode("https://yourdomain.com/WxAuth", Encoding.UTF8); string url = $"https://open.weixin.qq.com/connect/oauth2/authorize" + $"?appid={_appId}&redirect_uri={redirect}&response_type=code" + $"&scope=snsapi_base&state={spm}#wechat_redirect"; return Redirect(url); } // 第二次进来带code，用它换OpenId string tokenUrl = $"https://api.weixin.qq.com/sns/oauth2/access_token" + $"?appid={_appId}&secret={_appSecret}&code={code}" + $"&grant_type=authorization_code"; string json = new WebClient().DownloadString(tokenUrl); // 解析json，取出openid和access_token // 如果scope是snsapi_userinfo，还需要再调一次用户信息接口取昵称头像 }

逻辑说明：WxAuth被调用两次。第一次没有code，拼接授权链接，state参数里带着分销追踪标识spm，这个值就是上级会员Id；第二次微信回调带了code，再用code换OpenId。换到OpenId后，同步到Member表；如果这个OpenId第一次出现，就在Member表插入新会员，并把他和spm指向的上级绑定。参数scope=snsapi_base只返回OpenId，请求快但拿不到昵称头像；要昵称头像用snsapi_userinfo，用户会看到授权提示，转化率会略降。我一般默认snsapi_base，昵称头像等用户下单时再引导补全。

4.2 JS-SDK分享与分销追踪：所有入口URL都带spm

分销传播靠的是微信里分享出去的链接和二维码。别人点开链接，要能确定是谁推荐的。做法是在生成分享链接时，统一在URL后面拼一个spm参数，值为推荐人的MemberId。

// 微信内置浏览器里解析URL中的spm参数，存入localStorage (function () { var match = location.search.match(/[?&]spm=(\d+)/); if (match) { localStorage.setItem('spm_member', match[1]); } var spm = localStorage.getItem('spm_member'); if (spm) { // 把spm放到后续所有商品链接、下单接口的header或body里 $('#share-link').attr('href', '/Product/Detail/1?spm=' + spm); } })();

逻辑说明：JS在页面加载时解析URL参数，spm存在localStorage里。用户从A的分享链接进来，spm=A；然后他分享给B，URL带着spm=A；B进入后再分享给C，URL还是带着spm=A。但如果B是自己点进商城，并没有A的链接，localStorage为空，后续下单就只用他自己的身份。参数spm建议命名统一，服务端接收后校验这个会员号属于当前商户，防止伪造他人ID刷关系。微信JS-SDK的分享卡片可以自定义标题和图片，但底层追踪依然靠URL参数，不要只依赖SDK的分享回调。

4.3 微信支付API v3：回调验签与结果通知

支付回调是整个系统里最不能出错的接口。API v3的回调和旧版v2有很大区别，老源码大多是v2的MD5签名，新申请的商户号基本都要走v3。v3的签名方式是微信支付平台证书验签，回调内容里的resource字段是AES-256-GCM加密的，需要APIv3密钥来解密。

public ActionResult PayNotify() { // 一：从HTTP头取Wechatpay-Signature、Wechatpay-Timestamp、Wechatpay-Nonce // 二：用微信支付平台证书公钥验证签名，确认回调确实来自微信支付 // 三：解密resource里的AES-GCM密文，拿到out_trade_no、trade_state、amount // 四：检查out_trade_no对应订单是否存在，金额是否一致 // 五：调用TrySettleOrder(orderNo, merchantId)结算佣金 // 六：返回给微信支付： // 成功返回 {"code":"SUCCESS"} // 失败返回 {"code":"FAIL"}，微信会稍后重试 }

参数说明里最容易踩坑的是回调响应体。v3接口要求返回的Content-Type必须是application/json，而且失败返回要是一段包含code字段的JSON，而不是HTTP 500。如果响应不规范，微信支付会一直重试，同一笔回调把你的接口打很多次。另一个坑是金额校验：回调里的amount.total和订单里的TotalAmount必须一致，精确到分。曾经有人只验签名不验金额，黑客改不了回调内容，但测试环境里金额不一致的单子会把账搞乱，所以这一步不能省。

回调接口要在微信支付商户平台配置HTTPS地址，不能用IP，不能带端口，证书要有效。本地调试时可以用内网穿透工具把外网请求转发到本机，但线上一定要走正式域名，否则支付结果回不来。这笔账怎么强调都不过分：回调接口通了，佣金才敢发；回调不通，订单永远停在已支付未结算状态。

5. 避坑排查：多用户隔离、支付回调幂等与分销层级失控

下面五个问题是我认为跑这套源码最容易翻车的点，每一条都按现象、原因、解决三步写清楚，可以当排查手册用。

5.1 支付回调重复导致佣金翻倍

现象：同一笔订单在Commission表里出现了两条相同金额的记录，运营对账时发现支出多了好几倍。

原因：微信支付回调本来就可能重复推送，常见于网络超时后重试；更隐蔽的是开发人员重启应用时，回调线程被杀，重启后消息队列或微信再次推送同一事件。如果结算代码只判断“订单已支付”，不判断“是否已结算”，就会重复发佣金。

解决：在佣金结算入口加状态位和唯一约束。前面代码里的UPDATE OrderInfo SET SettleStatus = 1 WHERE OrderNo = @OrderNo AND SettleStatus = 0就是核心防线：影响行数为0就说明已经结算过，直接返回成功响应。另外在Commission表加唯一索引（OrderNo, Level, ToMemberId），即使代码有漏洞，数据库也会挡一道。这一步是防重复的后悔药，上线前必须确认索引建上。

5.2 分销层级被撑破，出现三级四级

现象：后台会员关系树里出现层级很深的链路，A推荐B，B推荐C，C又推荐D，佣金按整条链结算，会员和商户对账都不满意。

原因：注册绑定上级时没有校验Depth，或者校验逻辑只写了前端，接口层能直接传ParentId绕过。老源码里不少人把参数校验放JavaScript里，等于没校验。还有一类原因：用户注册时没有上级，后来通过“修改推荐人”功能绑了一个深度很深的会员，层级一下就爆了。

解决：绑定逻辑下沉到存储过程，服务端强制校验Depth不超过2。另外给会员加LockParentUntil字段，注册后30天内不允许改绑上级。这个锁定时间也非常管用，否则用户可以在下单前改到自己小号下面，把本该属于A的佣金刷走。我遇到过一个真实案例，一个用户注册后每次下单前都换上级，换到一个新注册的小号上，把平台当提款机，亏了一周佣金才查出来。

5.3 退款后佣金不回滚

现象：买家下单支付后，分销佣金已经发给上级。买家申请退款，钱退回去了，但上级的佣金没扣回，月底财务对账对不上。

原因：退款回调里只改了OrderInfo的PayStatus为2，没有去冲正Commission记录。常见的是写代码的人以为退单量小，不需要处理；或者退款的逻辑写在管理后台手动操作，不小心漏掉。

解决：在退款回调里，按退款金额占订单金额的比例，把已经入账的佣金按同等比例冲正。冲正不是物理删除，而是把原Commission记录设为Status=1，再插入一条金额为负的流水，字段ReversalLog写明退款单号。这样报表可以保留原始返佣记录，同时显示冲正后的实际支出。冲正逻辑要放在同一个数据库事务里，退款和冲正一起成功或一起失败，不能各干各的。

5.4 IIS部署后路由404与上传目录无权限

现象：本地调试正常，发布到Windows服务器IIS后，首页打开正常，但点击商品详情或调用接口返回404，后台图片上传也一直报错。

原因：两个问题叠在一起。404多半是URL重写规则导致的，老项目里商城伪静态规则和MVC路由冲突，或者IIS没有安装URL Rewrite组件，规则没生效，接口路径匹配不上。上传报错则是IIS应用程序池账号对上传目录没有写权限。

解决：第一次部署时，先不启用URL重写规则，用原始路径确认MVC路由能跑通；再装好URL Rewrite模块，把伪静态绑定到具体规则，不要用通配符直接吞掉WebApi的路由。上传目录单独给IIS应用程序池账号（通常是IIS AppPool\你的池名）开放修改权限。我自己习惯把日志和上传目录都放到网站根目录外的专用目录，避免网站升级时被覆盖。

5.5 多用户数据串号：查询漏了MerchantId

现象：A商户的商品在B商户的商城里显示出来，或者A商户的会员佣金结算到了B商户的账上。

原因：数据访问层没有强制过滤MerchantId，某些查询用了过期的存储过程，或者开发人员图省事，在Controller里直接拼接SQL忘了商户条件。电商系统一但有多个商户，这类串号是迟早的事，不是概率问题。

解决：统一数据访问入口，禁止在Controller里写SQL，所有查询必须走封装好的方法，方法内部强制带MerchantId条件；报表SQL也全部按MerchantId分组。上线前做一个自动巡检脚本，每天扫描一次每个商户的订单、佣金、商品数量，发现某个商户的OpenId或商品数据异常就告警。数据隔离的优先级高于功能迭代，这个不能讲人情。经验是：开发规范里写“必须带租户条件”没用，要让漏写条件直接编译不过或测试失败，比如封装一个DataFilter，构造查询时如果没赋值商户Id，直接抛异常。

6. 上线前自检：用对账脚本守住返佣结算这条命脉

最后这一道工序，是我每次上线必做的第一件事：建立一个“订单-佣金-退款”日终对账口径。逻辑很简单：今天的已支付订单金额，乘以每个商品的应收佣金比例，应该等于今天新增的佣金流水金额；今天的退款订单金额，乘以对应佣金比例，应该等于今天的冲正流水金额。两边对得上，分销系统才敢继续跑；对不上，一切增长动作都是白搭。

-- 日终对账第一关：按商户核对当日应结佣金与实际发放佣金 SELECT o.MerchantId, SUM(oi.Price * oi.Quantity * oi.CommissionRatio / 100.0) AS ExpectedCommission, ISNULL((SELECT SUM(c.Amount) FROM Commission c WHERE c.MerchantId = o.MerchantId AND c.CreateTime >= @TodayStart AND c.CreateTime < @TodayEnd AND c.Status = 0), 0) AS ActualCommission FROM OrderInfo o INNER JOIN OrderItem oi ON oi.OrderId = o.Id WHERE o.PayTime >= @TodayStart AND o.PayTime < @TodayEnd AND o.PayStatus = 1 GROUP BY o.MerchantId HAVING ABS(SUM(oi.Price * oi.Quantity * oi.CommissionRatio / 100.0) - ISNULL((SELECT SUM(c.Amount) FROM Commission c WHERE c.MerchantId = o.MerchantId AND c.CreateTime >= @TodayStart AND c.CreateTime < @TodayEnd AND c.Status = 0), 0)) > 0.01;

运行后如果结果集为空，说明当日分销佣金发放和订单金额吻合。如果查出差异，优先排查“退款未冲正”和“回调重复结算”两类问题。这个脚本要在每天凌晨自动跑，生成一张差异报表，发到运维群。我踩过的最大教训，是把返佣结算当成“订单支付后顺带做的事”，没有检查结果，一个月之后才发现账已经烂了一大截。后来养成的习惯是先跑通对账，再做页面优化，因为支付回调是钱的事，页面只是脸面。“支付成功但佣金没发出去”比“页面慢1秒”严重一百倍。希望这个方向能帮你少走弯路。

本文还有配套的精品资源，点击获取