简介：这是基于ASP.NET的多用户微信商城分销直销平台完整源码，面向需要快速搭建微信商城或开展公众号分销运营的开发团队。平台支持多公众号集中管理，每个公众号可配置5个子账号，涵盖自定义菜单、关注回复、客户管理、二维码链式推广、商城模板配置、商品与订单管理、微信支付V3.0等功能，后台还提供大管理端与BI智能图表分析，便于多商户统一运维与数据洞察。整套源码使用C# WebForm开发，数据库为SqlServer2008R2，附带完整项目文件与运行依赖。资源包共2000个文件，约67.24MB，以aspx页面、cs后台逻辑、dll组件、js脚本和css样式为主导，同时包含jpg/png/gif等大量界面与素材图片，以及项目工程文件、SQL脚本和说明文档，结构完整可直接部署修改。当前已有652人学习下载，适合具备一定ASP.NET基础并希望节省开发周期、基于成熟方案二次开发微信商城的开发者。
1. 这套ASPNET微信商城分销直销源码，为什么说“先跑通再改”最容易翻车
很多团队拿到一套「ASPNET多用户微信商城分销直销平台源码」的时候，第一反应都是赶紧部署、绑公众号、发一个分销链接，让客户马上开始卖货。以我经手老电商源码的经验，恰恰是这个“先跑起来”的决定最容易翻车：数据库里几十张表没人给你讲关系，三级分销佣金一跑就乱，微信支付回调进不来，最后页面能打开，但一个订单都成交不了。
这篇文章不评价源码本身好坏，而是把“多用户商城 + 分销直销”这套体系拆开：环境怎么搭、关系表怎么设计、佣金在哪里算、上线前哪些坑必须排。适合两类人：一是刚拿到这类源码准备做二次开发的程序员，二是想从零搭一套可交付微信分销商城的团队，用它作为基础工程起步。
2. 业务模型先立住：多用户、分销、直销在数据表里分别长什么样
2.1 “多用户”不是多管理员：商品、订单、资金归属必须分开
很多第一次接触这个标题的开发者，以为“多用户”只是支持多个管理员登录后台，其实差远了。多用户微信商城里的“用户”，指的是平台上的多个商家或商户角色。每个商家有自己的商品、订单、结算账户；平台运营方负责审核、抽佣和整体配置；普通会员在小程序或H5里下单，订单里要同时记录“从哪个商家买”和“从哪个推广人来”两个维度的归属。
如果表结构上没有把归属拆开，二次开发时一定会出现权限串号：商户A登录后台看到商户B的订单，改一个商品价格，另一个商户的也被改掉。常见的设计是商品表带ShopId，订单表带ShopId和MemberId，平台后台按ShopId过滤，商户后台也按ShopId过滤。拿到源码第一步不是去看页面，而是确认这三张主表里有没有独立归属字段，没有就得改代码前先补上，否则后面加功能全是屎山。
我把这类源码里最核心的几张表列成一个清单，拿到手后对照着找：
| 表 | 关键字段 | 作用 |
|---|---|---|
| Shop 商户表 | ShopId, ShopName, Status | 商家主体，一个平台下挂多个店铺 |
| Member 会员表 | UserId, ParentId, Balance | 会员基本信息与上级关系 |
| Product 商品表 | ProductId, ShopId, Stock, Price | 商品归属于某个Shop |
| Orders 订单表 | OrderId, ShopId, UserId, PayStatus | 订单同时记录商家与买家 |
| OrderItem 订单明细 | OrderId, ProductId, Quantity | 商品快照与数量 |
| Account 资金账户 | UserId, Balance, FrozenBalance | 余额与冻结余额分开 |
| AccountLog 资金流水 | Id, UserId, Amount, Type | 每笔资金变动留痕 |
这七张表能对得上，后面改分销逻辑心里就有底。对不上的，先补字段或修数据，别急着继续。
2.2 分销关系树：上级关系单独建表，别只靠订单表记一个推荐人
分销的核心不在卖货页面，而在上下级绑定关系。常见的错误设计是只在订单表里加一个RecommenderId字段，支付完成后直接按这笔订单给上级返佣，用户关系却没有持久化。后果是追查困难：用户第二笔订单推荐人变了、层级错乱、提现对不上账。
正确做法是有一张类似UserRelation的表，专门维护会员上下级关系：
| 字段 | 类型 | 说明 |
|---|---|---|
| UserId | int | 会员ID，主键 |
| ParentId | int | 直属上级会员ID |
| BindTime | datetime | 绑定时间 |
| BindType | tinyint | 绑定方式：0=分享链接注册，1=扫码，2=后台指定 |
| Status | tinyint | 关系是否有效，1=正常，0=解绑 |
这张表的好处是关系稳定：一旦通过分享链接注册成功，上下级关系就固定下来，不随订单变化。佣金计算始终以这张表为准，订单里只记录“下单人是谁”。注意一个会员只能有一个直属上级，最好在数据库里给UserId加唯一约束，否则层级链分叉，算佣金时出现两条路径，整个系统直接乱掉。
绑定时机也有讲究。常见做法是“注册时绑定”：用户点开分享链接进入小程序或H5，后台获取到分享者ID，在注册接口里写入ParentId。有的源码做成“首次下单时绑定”，这会导致对比链接、帮朋友下单后关系才形成，业务上容易扯皮。我一般要求注册时绑定，并且绑定后默认不允许在用户端自助改绑，只能后台手动调整，防止恶意刷层级。
2.3 直销和分销的触发点不同：算佣金的位置都应在支付成功回调
“直销”和“分销”在同一套源码里并不是重复概念。直销模式下，店主自己分享商品链接，客户直接下单，店主拿销售佣金；分销模式下，普通会员把链接分享给朋友，朋友下单，分享者作为推广人拿返佣。两者最终都落到“给某个推广人算钱”，但触发点不同。
正确做法是在“支付成功回调”这个节点统一触发，而不是在创建订单时触发。原因很实际：创建订单时用户可能还没付款，回调没到，此时分佣会把未付款订单也算进去；而且订单可能被取消，退款后佣金要回滚。支付成功回调里拿到的实付金额、优惠金额、运费，才是算佣金的真实基数。
很多源码在这个点偷懒，把分佣逻辑写在提交订单的Action里，这是“没付款也能拿佣金”漏洞的根源。改动前先搜一遍，找到真正处理微信支付回调的文件，再动逻辑。
2.4 数据流向：从支付成功到佣金到可提现，一条链路走完
我每次看这类源码，都会沿着一条链路去查：支付成功回调 → 写入佣金流水 → 增加用户可提现余额 → 用户申请提现 → 余额冻结 → 管理员审核打款。这条链路完整，商城资金才安全。
简化写法是：支付成功时只写佣金流水和累计待结算金额，不直接加可提现余额；用户确认收货后再把待结算转成可提现余额。这里沉淀了一个很重要的经验：不要让“订单支付成功”和“余额到账”同步发生，中间隔一层确认收货，能少处理大量退款纠纷。很多老源码没有这层隔离，支付成功就加余额，退款时再去扣，扣不回来就只能坏账。
3. 环境与部署：IIS + SQL Server 从建库到微信入口跑通
3.1 运行环境准备：老源码不要上 Linux，Windows Server 更省事
这套源码是ASP.NET那代的产品，不要试图放到Linux容器跑，默认就是Windows + IIS + SQL Server的搭配。我一般用Windows Server 2016或2019，SQL Server 2016/2019都行，.NET Framework 4.x 提前装好。
| 环境项 | 推荐版本 | 说明 |
|---|---|---|
| 操作系统 | Windows Server 2016/2019 | 兼容老IIS模块 |
| Web服务器 | IIS 8.5/10 | 自带即可 |
| 数据库 | SQL Server 2016/2019 | 兼容老脚本 |
| .NET | .NET Framework 4.x | 应用池选v4.0 |
| 证书 | HTTPS证书 | 微信回调强制要求 |
这里有个判断技巧：源码里如果用的是Web Forms，目录里带一堆aspx文件，应用池选v4.0集成模式基本能跑；如果源码带HttpModule或老组件，可能要切经典模式。不用一开始纠结，集成模式跑不通再切换。
3.2 还原数据库：先看逻辑文件名，再执行 RESTORE
拿到数据库备份，第一步不是直接还原，而是先查备份里的逻辑文件名：
RESTORE FILELISTONLY FROM DISK = N'C:\backup\MallDb.bak';查出来的LogicalName，才是下一步MOVE后面要写的名字。很多新人把备份文件名当逻辑名，还原报错“文件路径无效”。看到逻辑名后，执行完整还原：
RESTORE DATABASE MallDb FROM DISK = N'C:\backup\MallDb.bak' WITH MOVE N'MallDb_Data' TO N'D:\Data\MallDb.mdf', MOVE N'MallDb_Log' TO N'D:\Data\MallDb_log.ldf', REPLACE;还原完顺手执行SELECT name FROM sys.databases确认库在线。数据文件不要放C盘系统盘，单独建一个D:\Data目录，后续磁盘满了好处理。
3.3 改连接串与建专用账号：别拿sa跑线上
数据库还原成功后，打开Web.config。老源码连接串通常长这样：
<connectionStrings> <add name="MallConnection" connectionString="Server=.;Database=MallDb;User Id=sa;Password=YourPassword;MultipleActiveResultSets=true;" providerName="System.Data.SqlClient" /> </connectionStrings>我建议建一个专用账号，而不是直接拿sa跑线上。建账号和授权的SQL：
CREATE LOGIN MallUser WITH PASSWORD = 'StrongPass_2024'; CREATE USER MallUser FOR LOGIN MallUser; ALTER ROLE db_owner ADD MEMBER MallUser;连接串里改成User Id=MallUser;Password=StrongPass_2024。注意这类源码经常有多套配置文件，Web.config之外，可能App_Data或Config目录里还有一份，漏改一处就报“用户登录失败”。全局搜MallConnection或connectionString，找到几处改几处，别凭记忆。
3.4 发布站点到 IIS：应用池、物理路径、权限三件事
老源码不一定有发布后的bin目录，你拿到的可能是一整套源码工程。目录里如果已经带了bin和Web.config，直接作为站点物理路径就行，不用打开Visual Studio重新编译。
IIS站点用命令行创建更快：
%windir%\system32\inetsrv\appcmd add apppool /name:"MallAppPool" /managedRuntimeVersion:"v4.0" /managedPipelineMode:"Integrated" %windir%\system32\inetsrv\appcmd add site /name:"MallSite" /physicalPath:"D:\web\MallSite" /bindings:http/*:80:mall.example.com %windir%\system32\inetsrv\appcmd set app "MallSite/" /applicationPool:"MallAppPool"应用池要先创建再绑定站点，顺序反了会找不到池。物理路径要给IIS_IUSRS和NETWORK SERVICE读取权限，否则页面能开，但登录接口和后台全报403。第一次用集成模式打开，如果报500.19或提示需要经典模式，再到应用池把托管管线改成Classic。
3.5 微信入口配置：服务器 URL、支付回调地址、HTTPS 一个都不能少
商城要真正能用微信登录和微信支付，必须把微信公众平台的服务器配置指到源码里的处理接口。老源码一般有专门的Handler或路径，比如/api/wechat/notify或/pay/notify.aspx。不要凭印象填，先在源码里搜“notify”“callback”“微信支付”关键字，找到支付成功后实际处理的文件路径再填。
公众号后台配置时，服务器URL填HTTPS域名加该路径，Token要和源码里WeixinConfig保持一致。支付回调地址在微信支付商户平台设置，填成https://mall.example.com/pay/notify.aspx。这一步出错的表现是：支付成功但订单状态不变、佣金不产生，因为支付成功的消息根本没进到处理器。
提示：微信支付回调要求HTTPS。如果域名还是http，回调会静默丢失，排查半天都找不到原因。上线前先把证书装好，再把回调和接口地址全部改成https。
4. 改佣金计算的落地：参数表、存储过程、提现与退款回滚
4.1 分销参数放数据库：佣金比例、层级上限、佣金基数一次配齐
三级分销最容易踩的坑，是把佣金比例写死在C#代码里。比例一变就要重新编译发布，改错一个文件所有返佣全错。我要求这套配置独立成表，后台能直接改：
| 配置项 | 默认值 | 说明 |
|---|---|---|
| Level1Rate | 0.10 | 一级分销佣金比例 |
| Level2Rate | 0.05 | 二级分销佣金比例 |
| Level3Rate | 0.03 | 三级分销佣金比例 |
| MaxLevel | 3 | 分销层级上限 |
| IsSelfBuy | 0 | 自己买自己是否算佣金，1=算 |
| BaseType | 1 | 佣金基数：1=实付金额-运费，2=实付金额 |
这张表的初始化和读取都很直接：
CREATE TABLE DistConfig ( Id int PRIMARY KEY, Level1Rate decimal(18,4) NOT NULL, Level2Rate decimal(18,4) NOT NULL, Level3Rate decimal(18,4) NOT NULL, MaxLevel int NOT NULL DEFAULT 3, IsSelfBuy tinyint NOT NULL DEFAULT 0, BaseType tinyint NOT NULL DEFAULT 1 ); INSERT INTO DistConfig(Id, Level1Rate, Level2Rate, Level3Rate, MaxLevel, IsSelfBuy, BaseType) VALUES(1, 0.10, 0.05, 0.03, 3, 0, 1);Level1Rate对应直推下线，Level2Rate对应下线的下线，Level3Rate对应第三层。组合起来的分佣比例总和不要太高，这是做这类平台源码的基本商业约束。MaxLevel必须有限制，不能做成无限级，否则系统里层级链路无限拉长，佣金计算开销巨大，业务上也站不住。
4.2 分佣存储过程：幂等检查、逐级向上找上级、一个事务写多笔佣金
分佣逻辑放在数据库存储过程里是常见做法，事务好控制，改算法不用重新编译整个网站。核心思路是：在支付成功回调里调用存储过程，读取买家的UserRelation链，逐级向上找三级上级，按配置比例计算佣金，一次性写入多笔佣金流水。
一个完整度足够上线的简化版本：
CREATE PROCEDURE [dbo].[sp_CalcCommission] @UserId int, @OrderId int, @PayAmount decimal(18,2), @Freight decimal(18,2) AS BEGIN SET NOCOUNT ON; IF EXISTS(SELECT 1 FROM CommissionLog WHERE OrderId = @OrderId AND Status = 1) RETURN; DECLARE @BaseAmount decimal(18,2) = @PayAmount - @Freight; IF @BaseAmount <= 0 RETURN; DECLARE @Level1 int, @Level2 int, @Level3 int; DECLARE @Rate1 decimal(18,4), @Rate2 decimal(18,4), @Rate3 decimal(18,4); DECLARE @MaxLevel int, @IsSelfBuy tinyint, @BaseType tinyint; SELECT @Rate1 = Level1Rate, @Rate2 = Level2Rate, @Rate3 = Level3Rate, @MaxLevel = MaxLevel, @IsSelfBuy = IsSelfBuy, @BaseType = BaseType FROM DistConfig WHERE Id = 1; IF @BaseType = 1 SET @BaseAmount = @PayAmount - @Freight; ELSE SET @BaseAmount = @PayAmount; SELECT @Level1 = ParentId FROM UserRelation WHERE UserId = @UserId; IF @Level1 IS NULL AND @IsSelfBuy = 0 RETURN; SELECT @Level2 = ParentId FROM UserRelation WHERE UserId = @Level1; SELECT @Level3 = ParentId FROM UserRelation WHERE UserId = @Level2; BEGIN TRANSACTION; IF @IsSelfBuy = 1 AND @Level1 IS NULL BEGIN INSERT INTO CommissionLog(UserId, OrderId, Level, Amount, Status, CreateTime) VALUES(@UserId, @OrderId, 0, @BaseAmount * @Rate1, 1, GETDATE()); END; IF @Level1 IS NOT NULL AND @MaxLevel >= 1 INSERT INTO CommissionLog(UserId, OrderId, Level, Amount, Status, CreateTime) VALUES(@Level1, @OrderId, 1, @BaseAmount * @Rate1, 1, GETDATE()); IF @Level2 IS NOT NULL AND @MaxLevel >= 2 INSERT INTO CommissionLog(UserId, OrderId, Level, Amount, Status, CreateTime) VALUES(@Level2, @OrderId, 2, @BaseAmount * @Rate2, 1, GETDATE()); IF @Level3 IS NOT NULL AND @MaxLevel >= 3 INSERT INTO CommissionLog(UserId, OrderId, Level, Amount, Status, CreateTime) VALUES(@Level3, @OrderId, 3, @BaseAmount * @Rate3, 1, GETDATE()); COMMIT TRANSACTION; END;这段逻辑里最容易忽略的细节：先做幂等检查，同一订单重复回调直接返回，否则微信支付重试时佣金翻倍；再判断上级是否存在，NULL参与计算会得到空结果甚至报错；只有实付金额减掉运费后的部分才是佣金基数。注意我只是演示核心思路，真实项目还要在同一个事务里同步更新用户余额，并记录订单表的分佣标记。
4.3 在支付回调里调用分佣：C# 侧的参数传递与精度处理
存储过程写好后，在支付回调代码里调用它。老源码回调通常是一个.aspx.cs或.ashx文件，在“支付成功”分支里加调用：
using (SqlConnection conn = new SqlConnection(connString)) { using (SqlCommand cmd = new SqlCommand("sp_CalcCommission", conn)) { cmd.CommandType = CommandType.StoredProcedure; cmd.Parameters.Add("@UserId", SqlDbType.Int).Value = userId; cmd.Parameters.Add("@OrderId", SqlDbType.Int).Value = orderId; cmd.Parameters.Add("@PayAmount", SqlDbType.Decimal).Value = payAmount; cmd.Parameters.Add("@Freight", SqlDbType.Decimal).Value = freight; conn.Open(); cmd.ExecuteNonQuery(); } }这里不用AddWithValue处理金额，是因为AddWithValue在小数字段上偶尔会推断成float，导致精度偏移。改用显式SqlDbType.Decimal更稳。调用完记得在回执里输出微信要求的success字符串，让微信停止重试。
4.4 提现冻结与退款回滚：两个最容易漏的资金操作
佣金流水写好只是第一步，用户提现时还有两个高频漏洞。一是提现申请生成后没冻结余额，用户可以在待审核期间把同一笔钱提两次；二是退款发生后没有回滚佣金，平台倒贴钱。
我一般要求余额字段拆成“可用余额”和“冻结余额”两部分。发起提现时：
BEGIN TRANSACTION; UPDATE Account SET AvailableBalance = AvailableBalance - @Amount, FrozenBalance = FrozenBalance + @Amount WHERE UserId = @UserId AND AvailableBalance >= @Amount; IF @@ROWCOUNT = 0 BEGIN ROLLBACK TRANSACTION; RETURN -1; END; INSERT INTO CashOut(UserId, Amount, Status, ApplyTime) VALUES(@UserId, @Amount, 0, GETDATE()); COMMIT TRANSACTION;审核驳回时做反向操作。订单退款时，要把已发佣金按原路径扣回，扣不够就记负数等后续佣金冲抵。老源码里最常见的坏账，就是退款时只退了货款，佣金流水却没动。改的时候全局搜“退款”，把佣金回滚加进去，这一步不能省。
4.5 源码改造从哪下手：先找回调入口，再搜存储过程，最后动页面
拿到完整工程，我建议按这个顺序动手：先在解决方案里搜“notify”“支付成功”找回调入口；再搜sp_CalcCommission或CommissionLog找数据层；最后才看分销页面。原因很简单，只要把“支付成功→分佣→冻结→提现”这条主链改通，后台页面显示多少佣金都只是展示层问题。
另外要留意，老源码里经常存在两套以上页面：一套给PC后台，一套给微信端，它们可能调用不同的存储过程。改佣金算法时，把CommissionLog的所有写入点都搜出来，否则会出现“用户在微信端下单有佣金，在PC端下单没有”的诡异现象。
5. 上线前必查的五个坑：每个都可能导致分销体系直接返工
5.1 微信支付回调重复通知，佣金翻倍
现象：用户支付成功后，服务器收到回调不止一次，佣金重复计算，用户余额多出好几倍。
原因：微信支付在回调没收到正确应答时会重试多次；如果回调处理代码没做幂等，每收到一次就执行一次分佣。
解决：分佣前先查订单是否已分佣，或者给CommissionLog的OrderId加唯一约束。代码里判断到已分佣后直接返回success，不再执行后续逻辑。上面的存储过程已经在开头加了幂等检查，这一行救了很多次线上事故。
5.2 库存并发扣减导致超卖
现象：高并发下单时，商品库存100件，用户A和用户B同时下单，最终卖了101件。
原因：老源码里扣库存是“先SELECT再UPDATE”，两个请求同时读到库存为1，各自扣减后库存变0，但两个订单都创建成功。
解决：把库存扣减和订单创建放进同一存储过程，用条件更新方式扣库存：
UPDATE Product SET Stock = Stock - 1 WHERE ProductId = @ProductId AND Stock > 0;再判断影响行数，如果为0说明库存不足，回滚订单。不要用先查再改的写法，条件更新才是处理并发扣减的正解。
5.3 佣金金额精度与对账不平
现象：佣金算出来是0.001元这样的数，用户提现时对不上账，财务对账差几分钱。
原因：金额字段用float或double，乘除之后产生二进制浮点误差。
解决：金额类型的字段全部用decimal(18,2)，佣金计算时比例用decimal(18,4)，相乘后取整到两位小数。对账时拿CommissionLog和微信支付账单逐笔比对，差一分钱都优先怀疑精度，而不是怀疑丢单。
5.4 多用户后台越权：商户A看到商户B的数据
现象：商户登录后台，订单列表里出现别的商户订单，改一个商户商品，另一个商户的价格也变了。
原因：后台查询没有按ShopId过滤，或者商品表没有归属字段。
解决：全局搜后台订单列表、商品列表的SQL，强制加WHERE ShopId = @ShopId。做这类多用户源码的底线是：任何一条跨商户查询都不允许裸奔。改动后用两个商户账号各下一单，交叉验证数据隔离。
5.5 分销层级失去上限
现象：推广链条越来越长，佣金层级超过三级，系统性能下降，业务模式也失控。
原因：代码没有限制MaxLevel，或者只在前端页面限制，后端接口直接传层数。
解决：参数表里的MaxLevel必须在存储过程中生效，从数据库层面截断。每一笔佣金写入前判断Level是否小于等于MaxLevel，不满足就终止。该检查放在后端和数据库层，不能只靠前端页面挡住。
6. 上线前用一笔模拟订单验证分销链路：自检清单与我的习惯
每次上线这类源码，我做的最有价值的事不是看演示，而是亲手走通一轮完整流程：准备两个测试微信号，让用户B通过用户A的分享链接注册，B下单买一件10元的商品，支付后查CommissionLog，确认A拿到第一级佣金；再让用户C通过B的链接注册并下单，确认A拿到第二级佣金。整个过程用一条SQL检查：
SELECT UserId, Level, Amount, Status, CreateTime FROM CommissionLog WHERE OrderId = 12345 ORDER BY Level;| 自检项 | 预期结果 |
|---|---|
| 佣金流水笔数 | 等于已分佣层级数 |
| 各层级金额 | 符合DistConfig配置比例 |
| 重复回调 | 多次模拟回调不重复生成佣金 |
| 提现申请 | 发起提现后可用余额减少，冻结余额增加 |
| 退款后佣金 | 原佣金流水状态变更，余额回滚 |
五个自检项全过，我才认为这套源码在业务上能交付。做这类老源码久了，我的习惯是每次接手先摸数据库脚本和回调入口，再动页面。你以为的小改动，往往埋在存储过程里；不改存储过程，改一百行页面代码也是隔靴搔痒。希望这篇笔记能让你在部署ASP.NET微信商城分销直销源码时少走几趟弯路，把精力留给真正的业务问题。
本文还有配套的精品资源，点击获取
