简介：一份基于ASP.NET的返利购物商城系统源码，采用三层架构与工厂模式，前后台拆分为两个独立站点，适合具备.NET基础、需要搭建电商或返利分销平台的开发者、站长。整个资源包共2000个文件、104.52MB，核心文件类型包括cs源代码、aspx页面、ascx控件、js/css前端资源、dll程序集，以及数量较多的JPG/GIF图片素材，项目结构较为完整。功能上覆盖订单管理、购物车、商品管理、会员管理、团购、购物返利、商家加盟等业务，后台另有系统管理、文章管理、支付统计、站点配置、角色管理等模块，前台也保留了红利计划、商家联盟、商户入驻等页面，便于二次开发与模块扩展。源码完全开源，既可作为学习电商业务分层、工厂模式及前后台分离的实践案例，也能作为返利商城项目的基础改造版本。目前已有248人学习下载。
1. 为什么返利商城系统会选择 ASP.NET 而不是其他技术栈
"aspnet 返利购物商城系统源码"这类种子工程，通常不是给刚入门的人做毕业设计的，而是给已经跑过一段时间电商、想加分销返利功能的团队做基座。返利商城比普通商城多一个动作：用户支付完成后，系统要按下单时的规则，把佣金结算给上级、上上级，还要处理退款、冻结、提现。这个链路如果用脚本拼，早期跑得通，订单量一上来就到处漏。ASP.NET 的强类型模型、事务机制和成熟的身份框架，正好把这些状态转换压得比较稳；源码里如果还带了分层结构，那更值得照着拆一遍。
我一般在接手这类源码时，先不看页面，先看三个东西：订单状态机怎么定义、返利记录表有没有唯一索引、返利比例是不是存在数据库而不是硬编码。这三个点决定这套系统能不能在真实运营里扛得住。我按这个顺序讲：先拆核心模块，再给最小可运行骨架，然后调返利参数，最后讲最容易翻车的五个坑，收尾在进阶验证和压测上。适合做社交电商、分销插件、内购返利场景的从业者参考，源码工程里常见的隐藏问题也会提一下。
2. 拆解返利购物商城的核心模块：会员、商品、订单与返利引擎
返利商城表面上是商城，本质上是一个带分账系统的订单处理流水线。商品、订单这些和普通商城共用一套，真正特殊的是会员关系和返利引擎。会员表里要有"推荐人"字段，返利引擎要有明确的结算时序和防重逻辑。这一章先把数据流动串起来，再落到表结构和关键字段上。
2.1 返利链路怎么走：从下单到佣金结算的完整时序
返利的完整链路一般是这样的：用户注册时绑定推荐人，比如A邀请B，B邀请C。C下单支付成功，系统先冻结这笔订单对应的返利总额，然后按规则算出A和B各自该得多少，写入返利记录表，状态是"待结算"。等订单确认收货，并且过了冻结期（一般7天，防止退款），再把记录状态改成"可提现"。如果中间发生退款，就把冻结的记录作废，相应返利回滚。
这个时序里最容易被新手写错的是"下单时就把返利发出去"。常见做法是分两步：下单时只写"待结算"记录，确认收货时再触发明细变更。我一般会在订单状态机里加一个"已结算"的枚举值，这样日志里一眼能看到当前是哪个环节。代码上，用 ASP.NET 的事务把"扣库存、写订单、写返利记录"放在同一个TransactionScope里，保证要么全成功，要么全回滚。
常见实现如下，结构可以直接复用：
public async Task<IActionResult> CreateOrder(OrderCreateDto dto) { using var tx = new TransactionScope(TransactionScopeAsyncFlowOption.Enabled); // 1. 扣库存、生成主订单 var order = await _orderService.CreateAsync(dto); // 2. 计算返利明细，按会员层级生成记录 var commissionList = await _commissionService.CalcAsync(order, dto.BuyerUserId); // 3. 写返利记录，状态为 Pending（待结算） await _commissionService.SavePendingAsync(commissionList); tx.Complete(); return Ok(new { orderId = order.Id }); }这段逻辑的核心在于TransactionScope把所有写操作包在了一个事务里。CalcAsync里会读会员的推荐人链，拿到每个上级的返利比例，然后逐条生成返利记录。SavePendingAsync只负责插入，不做状态变更，这样后续确认收货时再统一结算。参数要注意的是：事务超时时间默认1分钟，计算推荐链如果层级很深，循环里每次查库容易超时，我通常会把推荐链一次性查出来放在内存里算。
确认收货后再执行结算，常见做法是一个OrderReceivedHandler，在订单状态改成已收货时触发：
public async Task Handle(OrderReceivedEvent evt) { var pendingRecords = await _commissionRepo.GetPendingByOrderIdAsync(evt.OrderId); foreach (var record in pendingRecords) { record.Status = CommissionStatus.Settled; record.SettleTime = DateTime.UtcNow; await _commissionRepo.UpdateAsync(record); } }这段做的是把之前写入的待结算记录批量改成已结算，同时记下结算时间。这里一定要给OrderId + UserId + Level加唯一索引，否则同一个订单并发确认收货时，会产生重复返利记录。这也是后面避坑章节要重点讲的问题。
2.2 数据表设计与关键字段：返利比例存哪里、怎么防改
返利商城最忌把返利比例写在代码里。运营三天两头调比例，改一次发一次版，早晚出事故。常见做法是把规则表单独标出来，比例、层级、冻结天数都放数据库，后台改配置即时生效。核心表大概四张：会员表、订单表、返利规则表、返利记录表。
创建会员表时，注意要有一个自关联的推荐人字段：
CREATE TABLE dbo.Member ( Id INT IDENTITY PRIMARY KEY, UserName NVARCHAR(50) NOT NULL, RecommenderId INT NULL, CreatedTime DATETIME DEFAULT GETDATE(), CONSTRAINT FK_Member_Recommender FOREIGN KEY (RecommenderId) REFERENCES dbo.Member(Id) );这里的RecommenderId指向上级会员，形成推荐链。查询上级链时，常见做法是递归CTE，但如果层级很多，我还是建议在内存里遍历，避免数据库递归性能问题。返利规则表是运营改得最多的表：
CREATE TABLE dbo.CommissionRule ( Id INT IDENTITY PRIMARY KEY, ProductId INT NULL, -- 空值表示全局默认规则 Level INT NOT NULL, -- 第几级返利，1=直接上级 Rate DECIMAL(5,4) NOT NULL, -- 返利比例，如 0.1000 表示10% FreezeDays INT NOT NULL, -- 冻结期，单位：天 Enabled BIT NOT NULL );关键点在于ProductId允许为空，空值表示全局默认规则，有值表示商品特定规则。这样就能做到"大部分商品走默认10%，爆款商品单独设15%"。Rate用DECIMAL(5,4)而不是FLOAT，因为浮点数在累加结算时会产生精度误差，倒账对不上。Enabled字段用来临时关闭某条规则，比如大促结束直接禁用，不用删数据。
返利记录表是流水账，必须保留全部历史，不能删改，只做状态流转：
CREATE TABLE dbo.CommissionRecord ( Id INT IDENTITY PRIMARY KEY, OrderId INT NOT NULL, UserId INT NOT NULL, -- 获得返利的会员 Level INT NOT NULL, -- 第几级 Amount DECIMAL(18,2) NOT NULL, Status INT NOT NULL, -- 0=待结算 1=已结算 2=已作废 3=已提现 CreatedTime DATETIME DEFAULT GETDATE(), SettleTime DATETIME NULL, CONSTRAINT UQ_Order_User_Level UNIQUE (OrderId, UserId, Level) );这里的UQ_Order_User_Level唯一索引就是防重地雷。没有它，并发请求把同一个订单的返利重复写入，金额会凭空翻倍。Amount用DECIMAL(18,2)，返利计算时先算分再转换成分，避免中间过程误差。这张表我会定期清理，但只做逻辑删除，不物理删，方便对账。
3. 用 ASP.NET 搭建返利商城的最小可运行骨架：项目分层与关键接口
源码工程如果能直接跑起来，说明项目结构是完整的。但很多号称"aspnet 返利购物商城系统源码"的包，下载下来不是数据库脚本缺失，就是连接字符串没配，再不就是返利逻辑和页面代码糊在一起。所以我拿到源码的第一步，不是看页面，而是先把项目层级和核心接口理顺。常见做法是分四层：Web 层、应用服务层、领域层、基础设施层，这样测试和替换存储都方便。
3.1 创建项目与目录结构：把返利逻辑和购物车分开
我一般会用dotnet new手动搭一个解决方案，而不是直接改别人的目录，因为这样能清楚知道每一层干什么。命令如下：
dotnet new sln -n RebateMall dotnet new webapi -n RebateMall.Api -o src/RebateMall.Api dotnet new classlib -n RebateMall.Application -o src/RebateMall.Application dotnet new classlib -n RebateMall.Domain -o src/RebateMall.Domain dotnet new classlib -n RebateMall.Infrastructure -o src/RebateMall.Infrastructure dotnet sln RebateMall.sln add src/RebateMall.Api src/RebateMall.Application src/RebateMall.Domain src/RebateMall.Infrastructurewebapi生成的是 ASP.NET Core Web API 项目，适合做前后端分离的商城接口。classlib是类库项目，分别放应用逻辑、领域模型、数据访问。这个分层不是摆设：领域层只定义"会员、订单、返利记录"这些实体和值对象，应用层写用例编排，基础设施层放DbContext和仓储实现。这样返利规则变更时，只改领域和应用层，页面和数据库都受影响更小。
目录结构建好后，需要给各项目加引用关系，常见做法用dotnet add reference：
dotnet add src/RebateMall.Application reference src/RebateMall.Domain dotnet add src/RebateMall.Infrastructure reference src/RebateMall.Domain dotnet add src/RebateMall.Api reference src/RebateMall.Application dotnet add src/RebateMall.Api reference src/RebateMall.Infrastructure引用关系决定依赖方向：Web 层只依赖应用层，不直接碰数据库。这样后面换数据库脚本时，只需要动 Infrastructure 层。需要注意，Domain 层不要引用任何 EF Core 的包，保持纯净，测试起来快。
3.2 核心接口实现：下单时计算返利与订单分红
有了骨架，接下来写最核心的下单接口。这个接口要做的事很多：校验库存、算价格、生成订单、保存返利记录。我把返利计算单独抽成一个ICommissionCalculator，避免在控制器里堆业务。
先定义一个简单的返利计算服务：
public class CommissionCalculator : ICommissionCalculator { private readonly IMemberRepository _memberRepo; private readonly ICommissionRuleRepository _ruleRepo; public List<CommissionLine> Calc(Order order, int buyerId) { var lines = new List<CommissionLine>(); var current = buyerId; var level = 1; while (current != null && level <= 3) // 最多三层 { var member = _memberRepo.GetById(current); if (member?.RecommenderId == null) break; var rule = _ruleRepo.GetByProductAndLevel(order.ProductId, level); if (rule == null || !rule.Enabled) break; var amount = Math.Round(order.PayAmount * rule.Rate, 2); lines.Add(new CommissionLine(member.RecommenderId, order.Id, level, amount)); current = member.RecommenderId; level++; } return lines; } }这段逻辑是最常见的三级分销返利。Calc从买家开始向上找推荐人，每层取对应比例，算出金额。Math.Round保留两位小数，避免超出数据库精度。层数上限写死为3，如果需要更多层级，把3改成配置值，不建议无限循环，容易死循环或超时。注意这里每个_memberRepo.GetById都会查一次库，如果会员量大，性能会有问题，常见优化是一次性把推荐链查出来，比如在仓储里写一个GetRecommenderChain方法。
然后下单控制器可以这样写：
[HttpPost("api/orders")] public async Task<IActionResult> CreateOrder([FromBody] CreateOrderRequest request) { using var tx = new TransactionScope(TransactionScopeAsyncFlowOption.Enabled); var order = await _orderService.CreateAsync(request.ProductId, request.BuyerId); var commissionLines = _commissionCalculator.Calc(order, request.BuyerId); await _commissionRecordRepo.SaveLinesAsync(commissionLines); tx.Complete(); return Ok(new { orderId = order.Id, commissionCount = commissionLines.Count }); }这里把"创建订单"和"生成返利记录"放到了同一个事务里，任何一步失败都会整体回滚。TransactionScope在 ASP.NET Core 里使用要加上TransactionScopeAsyncFlowOption.Enabled，否则 async 方法里可能遇到TransactionScope不完整的坑。SaveLinesAsync会批量插入返利记录，并依赖唯一索引防重。这个接口的核心参数是request.BuyerId，因为推荐链是从买家出发的，不是从登录用户出发的。
4. 返利规则配置与参数调优：百分比、层级与结算周期怎么定
返利规则是运营直接触碰的配置，定得不好，要么亏钱，要么分销员没动力。这一章先给核心参数，再讲怎么用配置表实现"改比例不改代码"。
4.1 返利规则的核心参数：佣金比例、级差与冻结期
常见的返利参数有这么几个：佣金比例、层级数、级差、冻结期、提现门槛。比例决定分钱多少，层级决定最多能分给几级，级差是高级别和低级别的比例差，冻结期是防退款的天数，提现门槛是分销员最低能提多少钱。
下面是我常用的参数表，可以直接用来做后台配置项：
| 参数 | 典型值 | 说明 |
|---|---|---|
| Level1Rate | 0.10 | 一级返利10%，给直接推荐人 |
| Level2Rate | 0.05 | 二级返利5%，给上上级 |
| Level3Rate | 0.03 | 三级返利3%，最多三层 |
| FreezeDays | 7 | 确认收货后冻结7天再结算 |
| MinWithdraw | 10 | 提现门槛10元 |
| MaxLevel | 3 | 返利层级上限 |
级差要不要设，取决于模式。如果是"平级"模式，所有层级同一比例；如果是"级差"模式，高级别拿更高比例，但要注意总比例不能超过100%。我一般把比例存成小数，0.10 表示10%，计算时直接乘金额。冻结期不能太短，否则退款风险全在平台这边；也不能太长，否则分销员体验很差。7天是业界比较常见的平衡点。
4.2 用配置表管理返利规则：改比例不改代码
很多源码把返利比例写在web.config或者appsettings.json里，改一次要发一次版。真正能撑住运营的频率，应该是规则存在数据库表里，后台改完立即生效。我一般会建一张CommissionRule表，然后加一个简单的缓存。
服务启动时读取规则并缓存，避免每次下单都查库：
public class CommissionRuleCache { private readonly ICommissionRuleRepository _ruleRepo; private ConcurrentDictionary<(int? ProductId, int Level), CommissionRule> _cache; public CommissionRule GetRule(int? productId, int level) { if (_cache.TryGetValue((productId, level), out var rule)) return rule; var loaded = LoadFromDb(); // 重新加载缓存，避免并发下读到半新数据 Interlocked.Exchange(ref _cache, loaded); return _cache.TryGetValue((productId, level), out rule) ? rule : null; } }这个缓存的 key 是(ProductId, Level)，ProductId 为空表示全局规则。LoadFromDb会把整张表一次性加载到内存，规则表通常只有几十条，这套做法完全够用。改动规则后，清一次缓存或者调一个刷新接口就行。注意ConcurrentDictionary的并发更新，用Interlocked.Exchange整体替换而不是AddOrUpdate，否则会出现读取到一半旧一半新数据。
在应用层，刷新接口可以直接让运营在后台点按钮触发：
[HttpPost("api/admin/commission/refresh")] public IActionResult RefreshRules() { _ruleCache.Reload(); return Ok(); }Reload只是重新执行加载逻辑。真正的参数调优依赖数据，不是靠猜的。我会定期跑一个对账任务，统计各层级的返利占比，如果发现某级比例太高导致平台利润接近零，就调低那一级。这个对账任务会在最后一章详细讲怎么验证。
5. 避坑指南：ASP.NET 返利商城最常见的 5 个翻车点与排查方法
返利商城比普通商城更容易翻车的地方，几乎都在并发和状态一致性上。我把这几年带团队调试时最常遇到的5个问题写在这里，每条按"现象→原因→解决"来写，希望能帮你在生产环境少踩几次坑。
5.1 返利记录重复生成，订单支付一次却给分销员发了两次钱
现象：同一订单在后台看到两条金额完全相同的返利记录，分销员提现时会多拿一倍。原因：下单接口被重复调用，可能是前端重复提交、回调重入或者并发请求。没有给OrderId + UserId + Level建唯一索引，数据库就无法挡住重复插入。解决：在返利记录表上建唯一约束，插入前先查一遍，插入时用INSERT IF NOT EXISTS或捕获重复键异常。我在CommissionRecord表上加了UQ_Order_User_Level后，这个问题基本绝迹。
5.2 确认收货后返利状态没变，分销员一直看不到可提现金额
现象：订单已经确认收货两天了，返利记录还是"待结算"。原因：确认收货的事件没有触发结算逻辑，或者触发时OrderReceivedHandler抛了异常，且没有重试机制。有些源码用的EventBus是同步调用，异常直接吞掉了。解决：给结算逻辑加日志，确认收货后打印OrderId和当前状态；再用IHostedService写一个定时扫描任务，把超过冻结期的待结算记录批量转成已结算，这样即使事件漏了，任务也能补上。
5.3 返利比例改错了，导致金额出现负数或小数位溢出
现象：运营在后台把比例调成 1.5，也就是150%，下单后返利金额超过订单原价，甚至出现负库存的错觉。原因：规则表没有校验比例范围，DECIMAL(5,4)最大只能存9.9999，但后台接口写入时没有范围检查。解决：在Rate字段上做数据库检查约束，后台接口再校验一次，比例必须介于0和1之间；计算金额后统一用Math.Round保留两位小数，避免溢出。
5.4 结算任务重复执行，导致同一笔返利被重复结算
现象：定时任务跑了两遍，已经"已结算"的记录又被改了一次，金额没变但时间被刷新了。原因：任务没有幂等标记，也没有检查当前状态就更新。解决：更新语句加上状态条件，比如UPDATE ... WHERE Status = 0，只有待结算才能转已结算；再给SettleTime记录第一次结算的时间，后续重复执行条件不匹配，自然跳过。
5.5 数据库连接字符串硬编码在源码里，交接时密码直接泄露
现象：源码包里的appsettings.json直接写了Server=...;User Id=sa;Password=...，客户拿到就能连生产库。原因：这是源码分享包最常见的卫生问题，作者图省事把配置写死。解决：把连接字符串移到环境变量或用户机密里，源码只留占位符。我一般用 ASP.NET Core 自带的User Secrets，开发环境读本地配置，生产环境读环境变量，分库密码绝不放进代码仓库。
以上这些翻车点，本质都是"状态机和并发"没处理好。理解了返利记录的状态流转，再看这些坑就很清楚了。遇到问题时，先看日志里有没有OrderId关联的记录，再确认状态值在哪一步断了，基本都能定位。
6. 把源码跑起来的进阶技巧：调试返利线程、验证佣金结算与压测准备
最后一章聊聊怎么把一套源码真正变成可运营的系统。我最常用三个技巧：用后台任务做定时结算、写对账脚本验证金额、用并发模拟压测返利接口。
定时结算我推荐用BackgroundService，它比Timer好控制，能优雅启停。下面这个后台任务每隔一分钟扫一次待结算且已过冻结期的订单：
public class CommissionSettlementService : BackgroundService { private readonly IServiceScopeFactory _scopeFactory; protected override async Task ExecuteAsync(CancellationToken stoppingToken) { while (!stoppingToken.IsCancellationRequested) { using var scope = _scopeFactory.CreateScope(); var repo = scope.ServiceProvider.GetRequiredService<ICommissionRecordRepo>(); await repo.SettleDueRecordsAsync(); await Task.Delay(TimeSpan.FromMinutes(1), stoppingToken); } } }关键点是IServiceScopeFactory，因为BackgroundService是单例，直接拿DbContext会出上下文作用域问题。每次轮询都新建一个作用域，用完释放，避免连接泄漏。SettleDueRecordsAsync里执行的是"把冻结期已过的待结算记录改成已结算"，条件里必须带Status = 0，这就是前面避坑说的幂等。
验证佣金结算，我一般写一个独立脚本，从库里拉数据重新计算一遍，再跟系统结算结果比对。比如用 SQL 直接汇总某个时间段内所有返利记录的总金额，和订单总金额按比例算出来的理论值对比，差值超过1分钱就报警。这里强烈建议用日志把每次结算的OrderId、UserId、Amount打出来，出问题能回溯。
压测准备上，先对下单接口做并发测试，看看是否会产生重复返利。我用dotnet run起服务后，写一个简单的并发请求脚本，比如用Parallel.For模拟100个买家用同一个订单号同时下单：
Parallel.For(0, 100, i => { // 构造HttpClient请求，提交同一个orderId });如果数据库唯一索引生效，最终只会有一条返利记录；否则就会出现多条。这个测试会直接暴露系统有没有把唯一约束加上，花几分钟就能避免上线后的大额赔付。做完这三步，这套返利商城源码才算真正接得住流量。
最后说一个我的习惯：不管源码多完整，拿到手第一件事就是改掉默认管理员密码、清掉示例数据、把连接字符串转到环境变量。返利系统直接和钱打交道，安全底线不能省。希望这篇笔记帮到你，少走几条我当年走过的弯路。
本文还有配套的精品资源，点击获取
