简介网上商城购物系统源码基于C#与ASP.NET开发面向计算机专业课程设计、毕业设计以及希望熟悉Web购物流程的初中级开发者可作为商品展示、购物车、订单处理与后台管理等模块的完整实现参考。压缩包共205个文件、约1.51MB含43个cs业务源码、30个aspx页面、6个ascx用户控件以及gif/jpg界面素材、db/mdf/ldf数据库文件和配置说明覆盖表现层、逻辑层、数据层与静态资源分层与目录组织较清晰。已有676人学习下载具备一定参考价值。读者可重点了解用户控件复用、商品浏览、购物车增减、订单列表与订单修改等流程也能借助现成页面结构和数据库文件快速搭建练习环境用于功能对照、代码阅读和二次改造减少从零搭建购物系统时在页面组织与数据衔接上的摸索。1. 网上商城购物系统C# 版一份能从前台逛到后台发货的完整源码上周帮人看一个接手的老项目前台商品页能打开点加购物车报 500后台订单列表永远是空的。翻了两个小时才发现问题既不在控制器也不在 SQL而是初始化脚本里少跑了一张表外键全断。这类「界面看着完整、跑起来处处是坑」的处境恰恰是拿到一份网上商城购物系统C# 版源码后最常见的开局。这份C# 源码把商品、分类、购物车、订单、会员、后台管理六条主流程串成了一个闭环技术选型是 ASP.NET MVC 5 ADO.NET 三层 SQL Server前后台一体业务表结构清晰适合拿来当管理系统类项目的骨架也适合想把电商下单链路从头理顺一遍的开发者。接下来按「结构怎么分、请求怎么走、钱怎么算、坑怎么躲、功能怎么加」拆下去。2. 解决方案结构拆解C# 三层架构在这个商城里怎么落地2.1 从 .sln 到五个项目每层到底管什么打开解决方案第一眼看到的是五个类库加一个 Web 项目。很多人拿到源码习惯直接从 Default.aspx 或者 HomeController 往下读读三层就迷路。先看目录比读代码省时间。ShopMall/ ├── ShopMall.Web/ # 表现层Controllers、Views、Content、Scripts、Uploads │ ├── Controllers/ # HomeController、ProductController、CartController、OrderController、Admin/* │ ├── Views/ # Razor 视图前后台分两个目录 │ ├── Content/ # Bootstrap 3 自定义样式 │ └── Web.config # 连接字符串、Session 配置、上传限制 ├── ShopMall.BLL/ # 业务层ProductService、CartService、OrderService、UserService ├── ShopMall.DAL/ # 数据层SqlHelper、ProductDal、OrderDal、UserDal ├── ShopMall.Model/ # 实体层Product、Order、OrderItem、CartItem、User └── ShopMall.Common/ # 工具层LogHelper、Md5Helper、PagerHelper、CacheHelper依赖方向是单向的Web 引用 BLL 和 ModelBLL 引用 DAL 和 ModelDAL 引用 ModelCommon 被所有层引用Model 谁也不引用。这条线守住了改一个 SQL 不会牵动页面换一套 UI 也不用碰业务逻辑。我在类似项目里见过最糟的改法是在 Controller 里直接 new SqlConnection 写 SQL半年后要加一个「商品下架不删除」的需求得把十几个 Action 全翻一遍。实体层用的是贫血模型只有属性和少量计算属性没有 ORM 的导航属性也就没懒加载那套玄学。这么做的好处是查询走向完全可预测哪一页慢去 DAL 里找对应方法就行不用猜 EF 生成了什么 SQL。// ShopMall.BLL/ProductService.cs public class ProductService { private readonly ProductDal _dal new ProductDal(); // pageIndex 从 1 开始pageSize 由前端传入但这里做上限保护 public PagedResultProduct GetList(int pageIndex, int pageSize, int categoryId) { if (pageIndex 1) pageIndex 1; if (pageSize 1 || pageSize 60) pageSize 12; var total _dal.CountOnSale(categoryId); var items _dal.GetPaged(pageIndex, pageSize, categoryId); return new PagedResultProduct(items, total, pageIndex, pageSize); } }pageSize的上限保护经常被忽略。没有这行判断前端改个参数就能一次拉几万条商品出来服务器内存直接起飞。PagedResultT里同时带着总数、当前页和总页数视图里翻页控件直接读属性不用再算一遍。2.2 八张核心表撑起整个商城商城类项目的表结构其实高度相似看懂了这几张看别的系统也能对上号。表名作用关键字段注意点Users前台会员UserId、UserName、PasswordHash、Salt、Status密码不存明文存 MD5盐Categories商品分类CategoryId、ParentId、SortOrderParentId 为 0 表示一级分类Products商品主表ProductId、Price、Stock、Sales、IsOnSale、IsDeleted价格用 decimal(18,2)ProductImages商品图ImageId、ProductId、ImageUrl、IsMain一个商品多图IsMain 取封面Orders订单主表OrderNo、UserId、TotalAmount、Status、CreateTimeOrderNo 唯一索引OrderItems订单明细ItemId、OrderNo、ProductId、UnitPrice、Quantity单价必须快照不关联商品现价Addresses收货地址AddressId、UserId、Receiver、Phone、Detail下单时也做快照Admins后台账号AdminId、Account、PasswordHash、RoleId前后台账号体系分开OrderItems里的UnitPrice要存下单那一刻的价格不能下单后现查Products.Price。这条经验是踩过的商品调价之后历史订单金额跟着变财务对账直接对不上。同理收货地址也要在订单上留一份快照字段用户改了默认地址旧订单不该跟着变。2.3 配置与连接字符串跑不起来多半卡在这几个节点Web.config里有三处必改改完才能编译运行。configuration connectionStrings !-- 三个参数必须对服务器实例名、数据库名、账号密码 -- add nameShopMallConn connectionStringData Source.\SQLEXPRESS;Initial CatalogShopMall;User Idsa;Password你的密码;MultipleActiveResultSetsTrue providerNameSystem.Data.SqlClient / /connectionStrings system.web !-- 超时 30 分钟购物车放 Session 里太短会丢 -- sessionState modeInProc timeout30 / !-- 商品图上传默认 4MB 不够用 -- httpRuntime targetFramework4.7.2 maxRequestLength10240 / authentication modeForms forms loginUrl~/Admin/Account/Login timeout120 / /authentication /system.web /configurationMultipleActiveResultSetsTrue不是可选项。三层架构里读 Reader 的同时再发起一次查询没有这个参数就会抛「已有打开的与此 Command 相关联的 DataReader」。maxRequestLength单位是 KB10240 就是 10MB改完还要去 IIS 的requestFiltering里同步改maxAllowedContentLength两处不一致是上传翻车的经典原因。3. 商品浏览与购物车一次加购请求的完整链路3.1 商品列表分页SQL 与 DAL 层怎么写列表页是流量入口写法直接决定首屏速度。项目里用的是 SQL Server 的OFFSET FETCH比ROW_NUMBER()套子查询干净。-- 只查上架且未删除的商品销量倒序OFFSET 必须配合 ORDER BY 使用 SELECT ProductId, ProductName, Price, Stock, MainImage, Sales FROM Products WHERE IsDeleted 0 AND IsOnSale 1 AND (CategoryId 0 OR CategoryId CategoryId) ORDER BY Sales DESC, ProductId DESC OFFSET Offset ROWS FETCH NEXT PageSize ROWS ONLY;CategoryId 0表示查全部分类这是种偷懒但好用的写法省得在 C# 里拼 WHERE 子句。ORDER BY后面跟了ProductId DESC作为第二排序键保证销量相同时分页结果稳定不会出现第二页重复出现第一页的商品。对应的 DAL 方法// ShopMall.DAL/ProductDal.cs public IListProduct GetPaged(int pageIndex, int pageSize, int categoryId) { const string sql SELECT ... OFFSET Offset ROWS FETCH NEXT PageSize ROWS ONLY; var ps new[] { new SqlParameter(CategoryId, categoryId), new SqlParameter(Offset, (pageIndex - 1) * pageSize), // 从 0 开始的偏移量 new SqlParameter(PageSize, pageSize) }; var list new ListProduct(); using (var reader SqlHelper.ExecuteReader(sql, ps)) { while (reader.Read()) { list.Add(new Product { ProductId Convert.ToInt32(reader[ProductId]), ProductName reader[ProductName].ToString(), Price Convert.ToDecimal(reader[Price]), Stock Convert.ToInt32(reader[Stock]) }); } } return list; }SqlHelper.ExecuteReader返回SqlDataReader调用方using包住连接在 Helper 内部用CommandBehavior.CloseConnection绑定Reader 关闭时连接自动释放。这套写法简单但要注意 Reader 必须在同一线程读完异步场景下要换成ExecuteReaderAsync不然会卡线程池。价格字段统一Convert.ToDecimal。见过有人写成double.Parse的商品列表价格显示 19.900000000000002用户截图来投诉这就是浮点数的锅。3.2 购物车数据结构Session 里到底存了什么这个版本的购物车没落库直接放 Session键名固定为CART_SESSION值是ListCartItem。对中小流量够用也没有「用户没登录不能加购」的门槛。// ShopMall.Model/CartItem.cs [Serializable] // InProc 下不是必须但换 StateServer 或 Redis 就必须 public class CartItem { public int ProductId { get; set; } public string ProductName { get; set; } public decimal UnitPrice { get; set; } // 加购时刻的价格 public int Quantity { get; set; } public string MainImage { get; set; } public decimal Subtotal UnitPrice * Quantity; }// ShopMall.BLL/CartService.cs public class CartService { private const string CartKey CART_SESSION; private const int MaxQuantityPerItem 99; public ListCartItem Current { get { var cart HttpContext.Current.Session[CartKey] as ListCartItem; return cart ?? new ListCartItem(); } } public void Add(CartItem item) { var cart Current; var exist cart.FirstOrDefault(x x.ProductId item.ProductId); if (exist ! null) { // 同一商品累加数量但封顶 99防止前端刷数量 exist.Quantity Math.Min(exist.Quantity item.Quantity, MaxQuantityPerItem); } else { item.Quantity Math.Min(item.Quantity, MaxQuantityPerItem); cart.Add(item); } HttpContext.Current.Session[CartKey] cart; // 值类型集合必须回写 } }Session[CartKey] cart这行不能省。ListT是引用类型理论上改了里面的元素不用回写但一旦 Session 模式切到 StateServer 或者 Redis每次读取都是反序列化出来的新对象不回写就等于没改。我一般养成「改完必回写」的习惯省得将来换 Session 存储时背这个锅。加购时价格取的是加购那一刻的Products.Price但结算时必须重新查一次价格这是后面下单章节要强调的点。3.3 金额计算与前端联动小计、运费、优惠的边界购物车页要显示商品总额、运费、应付总额这三项的计算集中在 BLL 里视图只负责渲染。// ShopMall.BLL/CartService.cs public CartSummary BuildSummary(ListCartItem items) { if (items null || items.Count 0) return CartSummary.Empty; // 商品小计decimal 保证精度绝不用 double decimal goodsAmount items.Sum(x x.UnitPrice * x.Quantity); // 运费规则满 99 免运费否则 8 元这里规则硬编码后续可挪到配置表 decimal freight goodsAmount 99m ? 0m : 8m; // 应付总额四舍五入到分AwayFromZero 与财务口径一致 decimal payable Math.Round(goodsAmount freight, 2, MidpointRounding.AwayFromZero); return new CartSummary { GoodsAmount goodsAmount, Freight freight, Payable payable, TotalQuantity items.Sum(x x.Quantity) }; }三个金额字段分开返回不做「随便给个总数」。购物车页面要显示「还差 X 元免运费」缺了GoodsAmount这个字段就得前端再算一遍前后端两套算法迟早对不上。MidpointRounding.AwayFromZero是必须要写的.NET 默认的银行家舍入会把 0.125 舍成 0.12和收银台习惯不一样差一分钱的事故就是这么来的。前端联动这块数量加减按钮通过 Ajax 调CartController.UpdateQty服务端返回最新的CartSummary的 JSON页面用 jQuery 更新三个数字不整页刷新。// 数量变更后只刷新金额区域避免整页重绘丢失滚动位置 function updateQty(productId, qty) { $.post(/Cart/UpdateQty, { productId: productId, quantity: qty }, function (res) { if (!res.success) { alert(res.message); return; } $(#goodsAmount).text(¥ res.data.goodsAmount.toFixed(2)); $(#freight).text(¥ res.data.freight.toFixed(2)); $(#payable).text(¥ res.data.payable.toFixed(2)); }); }服务端一定要再校验一遍quantity是否在 1 到 99 之间、商品是否上架、库存是否够。前端传什么都得当成不可信输入这条没有例外。4. 下单与库存扣减订单状态机和事务边界4.1 下单主流程从购物车到 Orders 与 OrderItems下单是整个系统里唯一必须开事务的地方。它要同时完成五件事写订单主表、写订单明细、扣库存、加销量、清空购物车。任何一步失败都得整体回滚不然就出现「订单生成了但库存没扣」或者「库存扣了但订单没生成」的对不上账。// ShopMall.BLL/OrderService.cs public OrderResult CreateOrder(int userId, ListCartItem cart, int addressId, string remark) { if (cart null || cart.Count 0) return OrderResult.Fail(购物车是空的); // 1. 服务端重新查价格与库存前端传来的金额一律不采信 var products new ProductDal().GetByIds(cart.Select(x x.ProductId).ToArray()); var details new ListOrderItem(); decimal goodsAmount 0m; foreach (var item in cart) { var p products.FirstOrDefault(x x.ProductId item.ProductId); if (p null) return OrderResult.Fail($商品 {item.ProductName} 不存在); if (!p.IsOnSale) return OrderResult.Fail($商品 {p.ProductName} 已下架); if (p.Stock item.Quantity) return OrderResult.Fail($商品 {p.ProductName} 库存不足); details.Add(new OrderItem { ProductId p.ProductId, ProductName p.ProductName, UnitPrice p.Price, // 快照当前价格 Quantity item.Quantity }); goodsAmount p.Price * item.Quantity; } decimal freight goodsAmount 99m ? 0m : 8m; var order new Order { OrderNo DateTime.Now.ToString(yyyyMMddHHmmss) new Random().Next(1000, 9999), UserId userId, AddressId addressId, TotalAmount Math.Round(goodsAmount freight, 2), Status (int)OrderStatus.WaitPay, Remark remark, CreateTime DateTime.Now }; // 2. 事务写主表 写明细 扣库存三步同生共死 using (var conn new SqlConnection(SqlHelper.ConnString)) { conn.Open(); using (var tran conn.BeginTransaction()) { try { var orderId new OrderDal().Insert(conn, tran, order); new OrderItemDal().InsertBatch(conn, tran, orderId, details); new ProductDal().ReduceStock(conn, tran, details); // 内部做条件更新 tran.Commit(); return OrderResult.Ok(order.OrderNo); } catch (Exception ex) { tran.Rollback(); LogHelper.Error(创建订单失败, ex); return OrderResult.Fail(下单失败请稍后重试); } } } }几个细节值得说。OrderNo用「时间戳 4 位随机数」生成实际生产里更稳的做法是加一列自增序列或者用雪花算法随机数在并发高的时候有碰撞可能虽然加了唯一索引兜底但会抛异常给用户。这里的details是在事务外就组装好的事务内只做写入事务持有时间越短越好连接池不容易被耗尽。ReduceStock传的是conn和tran不是自己新开连接。三层项目里很常见的错误是 DAL 方法内部using (var conn new SqlConnection(...))事务就断了后面的操作根本不在同一个事务里回滚只回滚了主表。下单成功后要清购物车这一步可以放在事务提交之后因为它不影响账务一致性// 事务提交成功后再清空 Session失败时购物车保留用户可以重试 HttpContext.Current.Session.Remove(CART_SESSION);如果把它塞进事务里事务回滚了购物车也空了用户得重新挑一遍商品体验很差。4.2 库存扣减与并发为什么不能先查再减新手写扣库存常见的是先在 C# 里if (p.Stock qty)判断然后UPDATE Products SET Stock Stock - Qty。单线程跑没问题两个人同时下单都读到库存 1都判断通过最后库存变成 -1。正确做法是把判断和扣减压进一条 SQL让数据库来做原子操作-- 条件更新库存不够时影响行数为 0调用方据此判断是否回滚 UPDATE Products SET Stock Stock - Qty, Sales Sales Qty WHERE ProductId Pid AND Stock Qty AND IsOnSale 1;// ShopMall.DAL/ProductDal.cs public void ReduceStock(SqlConnection conn, SqlTransaction tran, ListOrderItem details) { foreach (var d in details) { var ps new[] { new SqlParameter(Pid, d.ProductId), new SqlParameter(Qty, d.Quantity) }; // 返回受影响行数0 表示没扣成功库存不足或已下架 int rows SqlHelper.ExecuteNonQuery(conn, tran, UPDATE Products SET Stock Stock - Qty, Sales Sales Qty WHERE ProductId Pid AND Stock Qty AND IsOnSale 1, ps); if (rows 0) throw new InvalidOperationException($商品 {d.ProductName} 库存不足下单失败); } }抛异常的目的是触发外层事务的Rollback前面已经写进去的订单主表、明细全部撤销库存也不会出现扣了一半的情况。WHERE Stock Qty这一句是整段的核心它把「判断」和「扣减」做成了一次原子操作SQL Server 会在行上加锁第二个请求进来时读到的就是扣完后的值。如果业务上允许超卖比如预售就把这个条件去掉改成允许负库存然后人工补。但只要不是明确要求一律走条件更新。4.3 订单状态流转待付款到已完成订单状态用枚举定义存库时存 int避免改文案时动数据。// ShopMall.Model/OrderStatus.cs public enum OrderStatus { WaitPay 10, // 待付款 Paid 20, // 已付款待发货 Shipped 30, // 已发货 Completed 40, // 已完成 Cancelled 90, // 已取消 Refunded 99 // 已退款 }状态不允许随便改必须按白名单走。加一个CanTransferTo方法做守卫后台点「发货」时先校验当前状态是不是Paid防止把待付款订单直接发出去。// ShopMall.BLL/OrderService.cs private static readonly DictionaryOrderStatus, OrderStatus[] Allowed new() { [OrderStatus.WaitPay] new[] { OrderStatus.Paid, OrderStatus.Cancelled }, [OrderStatus.Paid] new[] { OrderStatus.Shipped, OrderStatus.Refunded }, [OrderStatus.Shipped] new[] { OrderStatus.Completed, OrderStatus.Refunded }, [OrderStatus.Completed] new OrderStatus[0], [OrderStatus.Cancelled] new OrderStatus[0], [OrderStatus.Refunded] new OrderStatus[0] }; public bool CanTransferTo(OrderStatus from, OrderStatus to) Allowed.TryGetValue(from, out var list) list.Contains(to);后台的改状态接口统一调这个方法返回 false 就提示「当前状态不允许该操作」。有了这层守卫测试提的「已取消订单还能发货」这种 bug 基本不会再冒出来。取消订单还要把库存加回去走的是UPDATE Products SET Stock Stock Qty同样放在事务里和状态变更一起提交。5. 跑起来与排查环境、初始化脚本和几个血泪坑5.1 本地环境搭建顺序错一步就得重来环境要求不高但顺序有讲究先建库跑脚本再改配置最后编译运行。反过来做会浪费很多时间在排查「为什么连接不上」上。开发工具Visual Studio 2019 及以上安装「ASP.NET 和 Web 开发」工作负载运行时.NET Framework 4.7.2项目目标框架装错版本会提示找不到引用数据库SQL Server 2016 及以上Express 版够用Web 服务器调试用 IIS Express部署用 IIS 10 集成模式数据库初始化用sqlcmd一条命令就能跑完脚本里包含建库、建表、索引和一批演示数据。# -S 指定实例名Express 版默认是 .\SQLEXPRESS # -i 指向初始化脚本脚本里已经写好 USE ShopMall sqlcmd -S .\SQLEXPRESS -U sa -P 你的密码 -i db/ShopMall_Init.sql脚本跑完SSMS 里刷新一下应该能看到 8 张核心表加若干辅助表。缺表说明脚本中途报错但被忽略了翻一下窗口里Msg开头的行。演示数据里的商品图存放在Uploads/目录用的是相对路径别把目录删了。5.2 常见问题排查五个踩过的坑坑一后台录入的中文变成问号现象是商品名称在后台输入框里打「测试商品」保存后列表里显示???。原因是数据库的默认排序规则是SQL_Latin1_General_CP1_CI_AS表字段用了varchar。改成nvarchar并且把排序规则换成Chinese_PRC_CI_AS已存在的表用ALTER TABLE Products ALTER COLUMN ProductName nvarchar(100)逐列改。参数化查询里SqlParameter会自动带N前缀但如果有人手工拼 SQL那就得自己写N中文。坑二路由全部 404只有静态页面能开现象是首页能显示点任何菜单都报 404。原因八九成是部署到 IIS 时应用程序池用了「经典模式」MVC 的路由模块不工作。改应用程序池为「集成模式」即可实在改不了就在Web.config的system.webServer/modules里加runAllManagedModulesForAllRequeststrue但这是兜底方案会增加所有静态资源的处理开销。坑三商品图上传成功前台却显示裂图上传接口返回成功Uploads/目录里也确实有文件但前台img是空白。两个原因叠在一起一是保存进数据库的是绝对路径D:\...\Uploads\a.jpg换个环境就不对了二是Uploads目录没有给IIS_IUSRS写权限实际写入被重定向到了临时目录。解决方式是存相对路径~/Uploads/xxx.jpg然后在 IIS 里给目录加写权限别用Everyone。坑四订单金额总是差一分钱对账时发现订单总额和明细加总差 0.01。原因是早期某段代码用了double计算运费0.1 0.2结果是0.30000000000000004四舍五入后就偏了。全部换成decimal并把数据库字段从float改成decimal(18,2)所有Math.Round显式指定MidpointRounding.AwayFromZero。坑五两个人同时下单库存变成负数现象是并发压测时出现负库存。原因是 DAL 里先SELECT Stock判断再UPDATE两个请求都读到了旧值。改成 4.2 节那种条件更新把库存判断写进WHERE子句受影响行数为 0 就抛异常回滚事务。改完之后压测 200 并发库存最低停在 0没有出现负数。5.3 日志与错误定位先看黑匣子再看代码排查线上问题最怕的是没有任何线索。这个项目的Common/LogHelper按天写文件落在App_Data/Logs/yyyy-MM-dd.logGlobal.asax里挂了Application_Error所有未捕获异常先记日志再跳错误页。// ShopMall.Web/Global.asax.cs protected void Application_Error(object sender, EventArgs e) { var ex Server.GetLastError(); LogHelper.Error($未处理异常URL{Request.RawUrl}, ex); // 清掉错误避免用户看到黄页 Server.ClearError(); Response.Redirect(~/Home/Error); }LogHelper内部用lock保证并发写不串行错乱日志内容包含时间、线程 ID、URL、异常堆栈。看日志的顺序是先按时间定位请求再看堆栈最内层通常真正的原因在InnerException里外层那个NullReferenceException只是被包装过的表象。6. 二次开发加一个支付回调要动哪几个文件需求来了要接一个第三方支付回调地址接收异步通知。这件事看着吓人实际改动集中在四处我按改过的顺序列出来。改造点涉及文件改动量回调入口Controllers/PayController.cs新增NotifyAction约 60 行状态流转OrderService.UpdateStatus复用已有守卫3 行支付流水新建PayLogs表 一个 DAL 方法约 40 行配置项Web.config加appSettings三个键3 行核心的Notify方法要处理三件事验签、幂等、状态更新。// ShopMall.Web/Controllers/PayController.cs [HttpPost] [AllowAnonymous] // 支付平台回调带的是签名不走登录态 public ActionResult Notify() { // 1. 读原始报文不用 Request.Form避免编码与签名不一致 string body; using (var reader new StreamReader(Request.InputStream)) body reader.ReadToEnd(); // 2. 验签失败直接返回 fail让支付平台稍后重试 if (!PayHelper.VerifySign(body, Request.Headers[X-Sign])) return Content(fail); var notify PayHelper.Parse(body); // 解析出 OrderNo、TradeNo、Amount、TradeStatus var order _orderService.GetByOrderNo(notify.OrderNo); if (order null) return Content(fail); // 3. 幂等已处理过直接返回 success避免重复发货 if (order.Status (int)OrderStatus.Paid || order.Status (int)OrderStatus.Shipped) return Content(success); // 4. 金额必须核对防止篡改报文 if (order.TotalAmount ! notify.Amount) return Content(fail); // 5. 事务内改状态 写流水 var ok _orderService.MarkPaid(order.OrderNo, notify.TradeNo, notify.Amount); return Content(ok ? success : fail); }幂等判断放在最前面因为支付平台的回调会重复推送直到收到success为止。没有这一步同一笔订单会被标记多次触发多次发货或者重复加积分。金额核对也不能省签名只保证报文没被改但有些支付渠道的签名不覆盖金额字段自己再比一次最稳。验证方法不建议直接拿真实支付环境试。我一般的做法是写一个Mock/PayMockController手动构造报文调Notify跑三个用例正常支付、重复推送、金额被改。三个都通过再上联调环境。改造完记得回头确认一件事MarkPaid里改状态必须走 4.3 节那个CanTransferTo守卫别图省事直接UPDATE Orders SET Status 20。我吃过这个亏某次春节前的版本上线一个手工补单的脚本绕过了状态机把已取消的订单改成了已付款第二天对账多出十几笔「幽灵订单」两个同事查了一通宵。从那以后凡是改订单状态我都强制走一遍那个方法哪怕只是一行临时脚本也先调守卫再动手。希望这些能帮你少绕点路。本文还有配套的精品资源点击获取 
长河君 · 2026/10/30 10:29:47 · 阅读 1.2k C#网上商城购物系统源码解析：三层架构、下单库存与支付回调
简介网上商城购物系统源码基于C#与ASP.NET开发面向计算机专业课程设计、毕业设计以及希望熟悉Web购物流程的初中级开发者可作为商品展示、购物车、订单处理与后台管理等模块的完整实现参考。压缩包共205个文件、约1.51MB含43个cs业务源码、30个aspx页面、6个ascx用户控件以及gif/jpg界面素材、db/mdf/ldf数据库文件和配置说明覆盖表现层、逻辑层、数据层与静态资源分层与目录组织较清晰。已有676人学习下载具备一定参考价值。读者可重点了解用户控件复用、商品浏览、购物车增减、订单列表与订单修改等流程也能借助现成页面结构和数据库文件快速搭建练习环境用于功能对照、代码阅读和二次改造减少从零搭建购物系统时在页面组织与数据衔接上的摸索。1. 网上商城购物系统C# 版一份能从前台逛到后台发货的完整源码上周帮人看一个接手的老项目前台商品页能打开点加购物车报 500后台订单列表永远是空的。翻了两个小时才发现问题既不在控制器也不在 SQL而是初始化脚本里少跑了一张表外键全断。这类「界面看着完整、跑起来处处是坑」的处境恰恰是拿到一份网上商城购物系统C# 版源码后最常见的开局。这份C# 源码把商品、分类、购物车、订单、会员、后台管理六条主流程串成了一个闭环技术选型是 ASP.NET MVC 5 ADO.NET 三层 SQL Server前后台一体业务表结构清晰适合拿来当管理系统类项目的骨架也适合想把电商下单链路从头理顺一遍的开发者。接下来按「结构怎么分、请求怎么走、钱怎么算、坑怎么躲、功能怎么加」拆下去。2. 解决方案结构拆解C# 三层架构在这个商城里怎么落地2.1 从 .sln 到五个项目每层到底管什么打开解决方案第一眼看到的是五个类库加一个 Web 项目。很多人拿到源码习惯直接从 Default.aspx 或者 HomeController 往下读读三层就迷路。先看目录比读代码省时间。ShopMall/ ├── ShopMall.Web/ # 表现层Controllers、Views、Content、Scripts、Uploads │ ├── Controllers/ # HomeController、ProductController、CartController、OrderController、Admin/* │ ├── Views/ # Razor 视图前后台分两个目录 │ ├── Content/ # Bootstrap 3 自定义样式 │ └── Web.config # 连接字符串、Session 配置、上传限制 ├── ShopMall.BLL/ # 业务层ProductService、CartService、OrderService、UserService ├── ShopMall.DAL/ # 数据层SqlHelper、ProductDal、OrderDal、UserDal ├── ShopMall.Model/ # 实体层Product、Order、OrderItem、CartItem、User └── ShopMall.Common/ # 工具层LogHelper、Md5Helper、PagerHelper、CacheHelper依赖方向是单向的Web 引用 BLL 和 ModelBLL 引用 DAL 和 ModelDAL 引用 ModelCommon 被所有层引用Model 谁也不引用。这条线守住了改一个 SQL 不会牵动页面换一套 UI 也不用碰业务逻辑。我在类似项目里见过最糟的改法是在 Controller 里直接 new SqlConnection 写 SQL半年后要加一个「商品下架不删除」的需求得把十几个 Action 全翻一遍。实体层用的是贫血模型只有属性和少量计算属性没有 ORM 的导航属性也就没懒加载那套玄学。这么做的好处是查询走向完全可预测哪一页慢去 DAL 里找对应方法就行不用猜 EF 生成了什么 SQL。// ShopMall.BLL/ProductService.cs public class ProductService { private readonly ProductDal _dal new ProductDal(); // pageIndex 从 1 开始pageSize 由前端传入但这里做上限保护 public PagedResultProduct GetList(int pageIndex, int pageSize, int categoryId) { if (pageIndex 1) pageIndex 1; if (pageSize 1 || pageSize 60) pageSize 12; var total _dal.CountOnSale(categoryId); var items _dal.GetPaged(pageIndex, pageSize, categoryId); return new PagedResultProduct(items, total, pageIndex, pageSize); } }pageSize的上限保护经常被忽略。没有这行判断前端改个参数就能一次拉几万条商品出来服务器内存直接起飞。PagedResultT里同时带着总数、当前页和总页数视图里翻页控件直接读属性不用再算一遍。2.2 八张核心表撑起整个商城商城类项目的表结构其实高度相似看懂了这几张看别的系统也能对上号。表名作用关键字段注意点Users前台会员UserId、UserName、PasswordHash、Salt、Status密码不存明文存 MD5盐Categories商品分类CategoryId、ParentId、SortOrderParentId 为 0 表示一级分类Products商品主表ProductId、Price、Stock、Sales、IsOnSale、IsDeleted价格用 decimal(18,2)ProductImages商品图ImageId、ProductId、ImageUrl、IsMain一个商品多图IsMain 取封面Orders订单主表OrderNo、UserId、TotalAmount、Status、CreateTimeOrderNo 唯一索引OrderItems订单明细ItemId、OrderNo、ProductId、UnitPrice、Quantity单价必须快照不关联商品现价Addresses收货地址AddressId、UserId、Receiver、Phone、Detail下单时也做快照Admins后台账号AdminId、Account、PasswordHash、RoleId前后台账号体系分开OrderItems里的UnitPrice要存下单那一刻的价格不能下单后现查Products.Price。这条经验是踩过的商品调价之后历史订单金额跟着变财务对账直接对不上。同理收货地址也要在订单上留一份快照字段用户改了默认地址旧订单不该跟着变。2.3 配置与连接字符串跑不起来多半卡在这几个节点Web.config里有三处必改改完才能编译运行。configuration connectionStrings !-- 三个参数必须对服务器实例名、数据库名、账号密码 -- add nameShopMallConn connectionStringData Source.\SQLEXPRESS;Initial CatalogShopMall;User Idsa;Password你的密码;MultipleActiveResultSetsTrue providerNameSystem.Data.SqlClient / /connectionStrings system.web !-- 超时 30 分钟购物车放 Session 里太短会丢 -- sessionState modeInProc timeout30 / !-- 商品图上传默认 4MB 不够用 -- httpRuntime targetFramework4.7.2 maxRequestLength10240 / authentication modeForms forms loginUrl~/Admin/Account/Login timeout120 / /authentication /system.web /configurationMultipleActiveResultSetsTrue不是可选项。三层架构里读 Reader 的同时再发起一次查询没有这个参数就会抛「已有打开的与此 Command 相关联的 DataReader」。maxRequestLength单位是 KB10240 就是 10MB改完还要去 IIS 的requestFiltering里同步改maxAllowedContentLength两处不一致是上传翻车的经典原因。3. 商品浏览与购物车一次加购请求的完整链路3.1 商品列表分页SQL 与 DAL 层怎么写列表页是流量入口写法直接决定首屏速度。项目里用的是 SQL Server 的OFFSET FETCH比ROW_NUMBER()套子查询干净。-- 只查上架且未删除的商品销量倒序OFFSET 必须配合 ORDER BY 使用 SELECT ProductId, ProductName, Price, Stock, MainImage, Sales FROM Products WHERE IsDeleted 0 AND IsOnSale 1 AND (CategoryId 0 OR CategoryId CategoryId) ORDER BY Sales DESC, ProductId DESC OFFSET Offset ROWS FETCH NEXT PageSize ROWS ONLY;CategoryId 0表示查全部分类这是种偷懒但好用的写法省得在 C# 里拼 WHERE 子句。ORDER BY后面跟了ProductId DESC作为第二排序键保证销量相同时分页结果稳定不会出现第二页重复出现第一页的商品。对应的 DAL 方法// ShopMall.DAL/ProductDal.cs public IListProduct GetPaged(int pageIndex, int pageSize, int categoryId) { const string sql SELECT ... OFFSET Offset ROWS FETCH NEXT PageSize ROWS ONLY; var ps new[] { new SqlParameter(CategoryId, categoryId), new SqlParameter(Offset, (pageIndex - 1) * pageSize), // 从 0 开始的偏移量 new SqlParameter(PageSize, pageSize) }; var list new ListProduct(); using (var reader SqlHelper.ExecuteReader(sql, ps)) { while (reader.Read()) { list.Add(new Product { ProductId Convert.ToInt32(reader[ProductId]), ProductName reader[ProductName].ToString(), Price Convert.ToDecimal(reader[Price]), Stock Convert.ToInt32(reader[Stock]) }); } } return list; }SqlHelper.ExecuteReader返回SqlDataReader调用方using包住连接在 Helper 内部用CommandBehavior.CloseConnection绑定Reader 关闭时连接自动释放。这套写法简单但要注意 Reader 必须在同一线程读完异步场景下要换成ExecuteReaderAsync不然会卡线程池。价格字段统一Convert.ToDecimal。见过有人写成double.Parse的商品列表价格显示 19.900000000000002用户截图来投诉这就是浮点数的锅。3.2 购物车数据结构Session 里到底存了什么这个版本的购物车没落库直接放 Session键名固定为CART_SESSION值是ListCartItem。对中小流量够用也没有「用户没登录不能加购」的门槛。// ShopMall.Model/CartItem.cs [Serializable] // InProc 下不是必须但换 StateServer 或 Redis 就必须 public class CartItem { public int ProductId { get; set; } public string ProductName { get; set; } public decimal UnitPrice { get; set; } // 加购时刻的价格 public int Quantity { get; set; } public string MainImage { get; set; } public decimal Subtotal UnitPrice * Quantity; }// ShopMall.BLL/CartService.cs public class CartService { private const string CartKey CART_SESSION; private const int MaxQuantityPerItem 99; public ListCartItem Current { get { var cart HttpContext.Current.Session[CartKey] as ListCartItem; return cart ?? new ListCartItem(); } } public void Add(CartItem item) { var cart Current; var exist cart.FirstOrDefault(x x.ProductId item.ProductId); if (exist ! null) { // 同一商品累加数量但封顶 99防止前端刷数量 exist.Quantity Math.Min(exist.Quantity item.Quantity, MaxQuantityPerItem); } else { item.Quantity Math.Min(item.Quantity, MaxQuantityPerItem); cart.Add(item); } HttpContext.Current.Session[CartKey] cart; // 值类型集合必须回写 } }Session[CartKey] cart这行不能省。ListT是引用类型理论上改了里面的元素不用回写但一旦 Session 模式切到 StateServer 或者 Redis每次读取都是反序列化出来的新对象不回写就等于没改。我一般养成「改完必回写」的习惯省得将来换 Session 存储时背这个锅。加购时价格取的是加购那一刻的Products.Price但结算时必须重新查一次价格这是后面下单章节要强调的点。3.3 金额计算与前端联动小计、运费、优惠的边界购物车页要显示商品总额、运费、应付总额这三项的计算集中在 BLL 里视图只负责渲染。// ShopMall.BLL/CartService.cs public CartSummary BuildSummary(ListCartItem items) { if (items null || items.Count 0) return CartSummary.Empty; // 商品小计decimal 保证精度绝不用 double decimal goodsAmount items.Sum(x x.UnitPrice * x.Quantity); // 运费规则满 99 免运费否则 8 元这里规则硬编码后续可挪到配置表 decimal freight goodsAmount 99m ? 0m : 8m; // 应付总额四舍五入到分AwayFromZero 与财务口径一致 decimal payable Math.Round(goodsAmount freight, 2, MidpointRounding.AwayFromZero); return new CartSummary { GoodsAmount goodsAmount, Freight freight, Payable payable, TotalQuantity items.Sum(x x.Quantity) }; }三个金额字段分开返回不做「随便给个总数」。购物车页面要显示「还差 X 元免运费」缺了GoodsAmount这个字段就得前端再算一遍前后端两套算法迟早对不上。MidpointRounding.AwayFromZero是必须要写的.NET 默认的银行家舍入会把 0.125 舍成 0.12和收银台习惯不一样差一分钱的事故就是这么来的。前端联动这块数量加减按钮通过 Ajax 调CartController.UpdateQty服务端返回最新的CartSummary的 JSON页面用 jQuery 更新三个数字不整页刷新。// 数量变更后只刷新金额区域避免整页重绘丢失滚动位置 function updateQty(productId, qty) { $.post(/Cart/UpdateQty, { productId: productId, quantity: qty }, function (res) { if (!res.success) { alert(res.message); return; } $(#goodsAmount).text(¥ res.data.goodsAmount.toFixed(2)); $(#freight).text(¥ res.data.freight.toFixed(2)); $(#payable).text(¥ res.data.payable.toFixed(2)); }); }服务端一定要再校验一遍quantity是否在 1 到 99 之间、商品是否上架、库存是否够。前端传什么都得当成不可信输入这条没有例外。4. 下单与库存扣减订单状态机和事务边界4.1 下单主流程从购物车到 Orders 与 OrderItems下单是整个系统里唯一必须开事务的地方。它要同时完成五件事写订单主表、写订单明细、扣库存、加销量、清空购物车。任何一步失败都得整体回滚不然就出现「订单生成了但库存没扣」或者「库存扣了但订单没生成」的对不上账。// ShopMall.BLL/OrderService.cs public OrderResult CreateOrder(int userId, ListCartItem cart, int addressId, string remark) { if (cart null || cart.Count 0) return OrderResult.Fail(购物车是空的); // 1. 服务端重新查价格与库存前端传来的金额一律不采信 var products new ProductDal().GetByIds(cart.Select(x x.ProductId).ToArray()); var details new ListOrderItem(); decimal goodsAmount 0m; foreach (var item in cart) { var p products.FirstOrDefault(x x.ProductId item.ProductId); if (p null) return OrderResult.Fail($商品 {item.ProductName} 不存在); if (!p.IsOnSale) return OrderResult.Fail($商品 {p.ProductName} 已下架); if (p.Stock item.Quantity) return OrderResult.Fail($商品 {p.ProductName} 库存不足); details.Add(new OrderItem { ProductId p.ProductId, ProductName p.ProductName, UnitPrice p.Price, // 快照当前价格 Quantity item.Quantity }); goodsAmount p.Price * item.Quantity; } decimal freight goodsAmount 99m ? 0m : 8m; var order new Order { OrderNo DateTime.Now.ToString(yyyyMMddHHmmss) new Random().Next(1000, 9999), UserId userId, AddressId addressId, TotalAmount Math.Round(goodsAmount freight, 2), Status (int)OrderStatus.WaitPay, Remark remark, CreateTime DateTime.Now }; // 2. 事务写主表 写明细 扣库存三步同生共死 using (var conn new SqlConnection(SqlHelper.ConnString)) { conn.Open(); using (var tran conn.BeginTransaction()) { try { var orderId new OrderDal().Insert(conn, tran, order); new OrderItemDal().InsertBatch(conn, tran, orderId, details); new ProductDal().ReduceStock(conn, tran, details); // 内部做条件更新 tran.Commit(); return OrderResult.Ok(order.OrderNo); } catch (Exception ex) { tran.Rollback(); LogHelper.Error(创建订单失败, ex); return OrderResult.Fail(下单失败请稍后重试); } } } }几个细节值得说。OrderNo用「时间戳 4 位随机数」生成实际生产里更稳的做法是加一列自增序列或者用雪花算法随机数在并发高的时候有碰撞可能虽然加了唯一索引兜底但会抛异常给用户。这里的details是在事务外就组装好的事务内只做写入事务持有时间越短越好连接池不容易被耗尽。ReduceStock传的是conn和tran不是自己新开连接。三层项目里很常见的错误是 DAL 方法内部using (var conn new SqlConnection(...))事务就断了后面的操作根本不在同一个事务里回滚只回滚了主表。下单成功后要清购物车这一步可以放在事务提交之后因为它不影响账务一致性// 事务提交成功后再清空 Session失败时购物车保留用户可以重试 HttpContext.Current.Session.Remove(CART_SESSION);如果把它塞进事务里事务回滚了购物车也空了用户得重新挑一遍商品体验很差。4.2 库存扣减与并发为什么不能先查再减新手写扣库存常见的是先在 C# 里if (p.Stock qty)判断然后UPDATE Products SET Stock Stock - Qty。单线程跑没问题两个人同时下单都读到库存 1都判断通过最后库存变成 -1。正确做法是把判断和扣减压进一条 SQL让数据库来做原子操作-- 条件更新库存不够时影响行数为 0调用方据此判断是否回滚 UPDATE Products SET Stock Stock - Qty, Sales Sales Qty WHERE ProductId Pid AND Stock Qty AND IsOnSale 1;// ShopMall.DAL/ProductDal.cs public void ReduceStock(SqlConnection conn, SqlTransaction tran, ListOrderItem details) { foreach (var d in details) { var ps new[] { new SqlParameter(Pid, d.ProductId), new SqlParameter(Qty, d.Quantity) }; // 返回受影响行数0 表示没扣成功库存不足或已下架 int rows SqlHelper.ExecuteNonQuery(conn, tran, UPDATE Products SET Stock Stock - Qty, Sales Sales Qty WHERE ProductId Pid AND Stock Qty AND IsOnSale 1, ps); if (rows 0) throw new InvalidOperationException($商品 {d.ProductName} 库存不足下单失败); } }抛异常的目的是触发外层事务的Rollback前面已经写进去的订单主表、明细全部撤销库存也不会出现扣了一半的情况。WHERE Stock Qty这一句是整段的核心它把「判断」和「扣减」做成了一次原子操作SQL Server 会在行上加锁第二个请求进来时读到的就是扣完后的值。如果业务上允许超卖比如预售就把这个条件去掉改成允许负库存然后人工补。但只要不是明确要求一律走条件更新。4.3 订单状态流转待付款到已完成订单状态用枚举定义存库时存 int避免改文案时动数据。// ShopMall.Model/OrderStatus.cs public enum OrderStatus { WaitPay 10, // 待付款 Paid 20, // 已付款待发货 Shipped 30, // 已发货 Completed 40, // 已完成 Cancelled 90, // 已取消 Refunded 99 // 已退款 }状态不允许随便改必须按白名单走。加一个CanTransferTo方法做守卫后台点「发货」时先校验当前状态是不是Paid防止把待付款订单直接发出去。// ShopMall.BLL/OrderService.cs private static readonly DictionaryOrderStatus, OrderStatus[] Allowed new() { [OrderStatus.WaitPay] new[] { OrderStatus.Paid, OrderStatus.Cancelled }, [OrderStatus.Paid] new[] { OrderStatus.Shipped, OrderStatus.Refunded }, [OrderStatus.Shipped] new[] { OrderStatus.Completed, OrderStatus.Refunded }, [OrderStatus.Completed] new OrderStatus[0], [OrderStatus.Cancelled] new OrderStatus[0], [OrderStatus.Refunded] new OrderStatus[0] }; public bool CanTransferTo(OrderStatus from, OrderStatus to) Allowed.TryGetValue(from, out var list) list.Contains(to);后台的改状态接口统一调这个方法返回 false 就提示「当前状态不允许该操作」。有了这层守卫测试提的「已取消订单还能发货」这种 bug 基本不会再冒出来。取消订单还要把库存加回去走的是UPDATE Products SET Stock Stock Qty同样放在事务里和状态变更一起提交。5. 跑起来与排查环境、初始化脚本和几个血泪坑5.1 本地环境搭建顺序错一步就得重来环境要求不高但顺序有讲究先建库跑脚本再改配置最后编译运行。反过来做会浪费很多时间在排查「为什么连接不上」上。开发工具Visual Studio 2019 及以上安装「ASP.NET 和 Web 开发」工作负载运行时.NET Framework 4.7.2项目目标框架装错版本会提示找不到引用数据库SQL Server 2016 及以上Express 版够用Web 服务器调试用 IIS Express部署用 IIS 10 集成模式数据库初始化用sqlcmd一条命令就能跑完脚本里包含建库、建表、索引和一批演示数据。# -S 指定实例名Express 版默认是 .\SQLEXPRESS # -i 指向初始化脚本脚本里已经写好 USE ShopMall sqlcmd -S .\SQLEXPRESS -U sa -P 你的密码 -i db/ShopMall_Init.sql脚本跑完SSMS 里刷新一下应该能看到 8 张核心表加若干辅助表。缺表说明脚本中途报错但被忽略了翻一下窗口里Msg开头的行。演示数据里的商品图存放在Uploads/目录用的是相对路径别把目录删了。5.2 常见问题排查五个踩过的坑坑一后台录入的中文变成问号现象是商品名称在后台输入框里打「测试商品」保存后列表里显示???。原因是数据库的默认排序规则是SQL_Latin1_General_CP1_CI_AS表字段用了varchar。改成nvarchar并且把排序规则换成Chinese_PRC_CI_AS已存在的表用ALTER TABLE Products ALTER COLUMN ProductName nvarchar(100)逐列改。参数化查询里SqlParameter会自动带N前缀但如果有人手工拼 SQL那就得自己写N中文。坑二路由全部 404只有静态页面能开现象是首页能显示点任何菜单都报 404。原因八九成是部署到 IIS 时应用程序池用了「经典模式」MVC 的路由模块不工作。改应用程序池为「集成模式」即可实在改不了就在Web.config的system.webServer/modules里加runAllManagedModulesForAllRequeststrue但这是兜底方案会增加所有静态资源的处理开销。坑三商品图上传成功前台却显示裂图上传接口返回成功Uploads/目录里也确实有文件但前台img是空白。两个原因叠在一起一是保存进数据库的是绝对路径D:\...\Uploads\a.jpg换个环境就不对了二是Uploads目录没有给IIS_IUSRS写权限实际写入被重定向到了临时目录。解决方式是存相对路径~/Uploads/xxx.jpg然后在 IIS 里给目录加写权限别用Everyone。坑四订单金额总是差一分钱对账时发现订单总额和明细加总差 0.01。原因是早期某段代码用了double计算运费0.1 0.2结果是0.30000000000000004四舍五入后就偏了。全部换成decimal并把数据库字段从float改成decimal(18,2)所有Math.Round显式指定MidpointRounding.AwayFromZero。坑五两个人同时下单库存变成负数现象是并发压测时出现负库存。原因是 DAL 里先SELECT Stock判断再UPDATE两个请求都读到了旧值。改成 4.2 节那种条件更新把库存判断写进WHERE子句受影响行数为 0 就抛异常回滚事务。改完之后压测 200 并发库存最低停在 0没有出现负数。5.3 日志与错误定位先看黑匣子再看代码排查线上问题最怕的是没有任何线索。这个项目的Common/LogHelper按天写文件落在App_Data/Logs/yyyy-MM-dd.logGlobal.asax里挂了Application_Error所有未捕获异常先记日志再跳错误页。// ShopMall.Web/Global.asax.cs protected void Application_Error(object sender, EventArgs e) { var ex Server.GetLastError(); LogHelper.Error($未处理异常URL{Request.RawUrl}, ex); // 清掉错误避免用户看到黄页 Server.ClearError(); Response.Redirect(~/Home/Error); }LogHelper内部用lock保证并发写不串行错乱日志内容包含时间、线程 ID、URL、异常堆栈。看日志的顺序是先按时间定位请求再看堆栈最内层通常真正的原因在InnerException里外层那个NullReferenceException只是被包装过的表象。6. 二次开发加一个支付回调要动哪几个文件需求来了要接一个第三方支付回调地址接收异步通知。这件事看着吓人实际改动集中在四处我按改过的顺序列出来。改造点涉及文件改动量回调入口Controllers/PayController.cs新增NotifyAction约 60 行状态流转OrderService.UpdateStatus复用已有守卫3 行支付流水新建PayLogs表 一个 DAL 方法约 40 行配置项Web.config加appSettings三个键3 行核心的Notify方法要处理三件事验签、幂等、状态更新。// ShopMall.Web/Controllers/PayController.cs [HttpPost] [AllowAnonymous] // 支付平台回调带的是签名不走登录态 public ActionResult Notify() { // 1. 读原始报文不用 Request.Form避免编码与签名不一致 string body; using (var reader new StreamReader(Request.InputStream)) body reader.ReadToEnd(); // 2. 验签失败直接返回 fail让支付平台稍后重试 if (!PayHelper.VerifySign(body, Request.Headers[X-Sign])) return Content(fail); var notify PayHelper.Parse(body); // 解析出 OrderNo、TradeNo、Amount、TradeStatus var order _orderService.GetByOrderNo(notify.OrderNo); if (order null) return Content(fail); // 3. 幂等已处理过直接返回 success避免重复发货 if (order.Status (int)OrderStatus.Paid || order.Status (int)OrderStatus.Shipped) return Content(success); // 4. 金额必须核对防止篡改报文 if (order.TotalAmount ! notify.Amount) return Content(fail); // 5. 事务内改状态 写流水 var ok _orderService.MarkPaid(order.OrderNo, notify.TradeNo, notify.Amount); return Content(ok ? success : fail); }幂等判断放在最前面因为支付平台的回调会重复推送直到收到success为止。没有这一步同一笔订单会被标记多次触发多次发货或者重复加积分。金额核对也不能省签名只保证报文没被改但有些支付渠道的签名不覆盖金额字段自己再比一次最稳。验证方法不建议直接拿真实支付环境试。我一般的做法是写一个Mock/PayMockController手动构造报文调Notify跑三个用例正常支付、重复推送、金额被改。三个都通过再上联调环境。改造完记得回头确认一件事MarkPaid里改状态必须走 4.3 节那个CanTransferTo守卫别图省事直接UPDATE Orders SET Status 20。我吃过这个亏某次春节前的版本上线一个手工补单的脚本绕过了状态机把已取消的订单改成了已付款第二天对账多出十几笔「幽灵订单」两个同事查了一通宵。从那以后凡是改订单状态我都强制走一遍那个方法哪怕只是一行临时脚本也先调守卫再动手。希望这些能帮你少绕点路。本文还有配套的精品资源点击获取