简介基于ASP.NET与MVC三层架构打造的商城系统完整源码附带小程序商城端面向需快速搭建或二次开发电商平台的.NET开发人员同样适用于高校毕设与商业项目起步参考。资源包共2000个文件以C#源文件、ASP.NET页面、样式脚本、交互JS及DLL组件为主并包含数据库视图与存储过程资源包约127.65MB。目前已有799人学习下载。系统完整开源覆盖会员等级积分、购物车、订单管理、支付宝担保交易、发货确认与收货好评等主流电商功能采用B/S模式界面友好易操作内置数据合法性校验与事务回滚机制以保障数据安全。对于研究.NET商城架构、理解支付集成或进行功能扩展的开发者这份源码提供了从代码到数据库脚本、存储过程的完整落地实例目录结构清晰便于按模块学习和调试。1. 一套 ASP.NET 商城源码附赠小程序端这条链路到底帮你省了哪些活ASP.NET 商城源码赠送小程序商城这种包在 .NET 开发者圈子里流传很广一套完整的电商后端商品、分类、购物车、订单、会员、后台管理都齐还白送一个微信小程序前端。对独立开发者来说最值钱的不是后台页面数量而是从数据库表设计到接口联调、再到微信支付回调这一整条链路已经有人替你走通。接手后的活从从零写商城降级成部署、改配置、按业务改需求。这篇笔记按我接手这类源码的顺序讲先判断技术栈再跑通数据库和本地环境最后收在小程序对接与上线避坑。适合已经拿到源码包、准备自己部署或二次开发的人。2. 拆包看架构先确认 .NET Framework 还是 asp.net core再决定怎么接手拿到任何一个商城源码包我第一件事不是解压按 F5而是先看 .sln 和 .csproj。标题里统称ASP.NET实际可能是跨了十年的两种技术路线判断错了后面全是血泪经验老项目在 Windows 上能跑你非要往 Linux 上部署新项目命令行一条命令就能起你还在满世界找 IIS 配置。先用三十分钟把架构看清楚比什么都重要。2.1 先看 TargetFramework三种常见形态一眼认出来用记事本打开 .csproj 就能判断。老一代的 .NET Framework 4.x 项目没有 TargetFramework 节点引包靠 packages.config只能在 Windows 加 IIS Express 环境里跑新一代的 asp.net core 项目csproj 顶部会写着 net6.0 或 net8.0能跨平台能直接用dotnet run拉起来。还有第三类更头疼说是 ASP.NET实际是 WebForm一堆 .aspx 页面加服务端控件接口用 ashx 一般处理程序或者干脆把 aspx 当接口输出 JSON二次开发体验最差。判断点.NET Framework 老项目asp.net core 项目csproj 关键特征无 TargetFramework存在 packages.configTargetFramework 写明 net6.0 / net8.0运行方式Windows IIS / IIS Express命令行 dotnet run跨平台常见出现时间2010–2017 年交付2018 年之后交付判断顺序三十秒先看有没有 TargetFramework再看有没有 packages.config最后扫一眼目录里有没有 .aspx 文件。很多号称ASP.NET 商城源码的包其实是 2015 年前后的 MVC 5 项目跑在 .NET Framework 4.5 上依赖 Newtonsoft.Json、Entity Framework 6 这些老版本NuGet 还原时最容易出问题。这一眼确认完后面所有操作路径都不一样了。提示老 Framework 项目不是不能用于新业务但它的依赖还原、证书链、开发工具版本都可能成为坑。先确认技术栈再谈后面的改造方案。2.2 典型商城分层Model、DAL、BLL、Admin 与 Api 各自管什么这类源码的分层高度雷同看懂了就能少走弯路。Model 层放实体类对应数据库表DAL 层是数据访问用 SqlHelper、Dapper 或 EF 实现BLL 层管业务逻辑下单、扣库存、算运费都在这里Web 层是门户商城页面Admin 是后台管理这两个有大量 Razor 或 aspx 视图最后通常会有一个 Api 项目或 Api 区域专门给小程序端提供 JSON 接口。有个细节值得注意小程序接口和数据访问层经常不在一个项目里。有的源码把 Api 做在 Admin 项目下路由写成 /api/xxx和前台上线在同一个站点。这种写法省事但埋了隐患——后台管理员的鉴权策略和小程序接口混在一起改后台登录逻辑时会把小程序接口一起带崩。我一般会先确认 Api 是不是一个独立可发布的项目如果不是二次开发时优先把它拆出去。还要警惕鉴权写得太随意的源码。有的商城源码对小程序的商品、订单接口根本不鉴权拉列表、查订单、甚至看别人收货地址都是裸奔状态这类问题我放在第五章专门讲。另外后台管理页基本都是 Bootstrap 老模板堆出来的样式代码比较乱想换皮可以拿 bootstrap studio 这类可视化工具重新拖界面但核心链路没验证之前别折腾皮肤那不是当前的主要矛盾。2.3 小程序端在包里长什么样为什么它不在解决方案里所谓赠送的小程序商城通常是一个独立文件夹名字叫 wxapp 或 mall-miniapp里面是原生小程序代码pages/index、pages/goods、pages/cart、pages/order、utils/request.js 这一套。它不属于 .sln 里的项目在 VS 里看不到得用微信开发者工具单独打开。打开后第一件事是改接口地址。源码作者通常留的是他自己的测试域名甚至是 http://localhost:5000 这种本地地址你不改的话小程序端一请求就失败。把它改成自己部署好的 Api 地址然后看 utils/request.js 里有没有统一的 baseUrl 配置。小程序端不能直接访问 IP生产环境必须配 HTTPS 域名并且在小程序后台把域名加进 request 合法域名列表这一步是硬性要求。如果包里根本没有小程序端只在文档里提了一句登录接口是 /api/user/login那你拿到的就不是完整包。不用急着找作者扯皮按第四章的方案自己接一个原生小程序端也不复杂毕竟微信端的核心也就登录、商品列表、下单、支付那几条接口后端接口现成的。3. 数据库初始化和本地跑通连接串、SQL 脚本与最小启动清单后端代码写得再漂亮数据库起不来都是零。商城源码的数据库绝大多数是 SQL Server少数改成了 MySQL。数据库相关文件通常在根目录的 db、database 或 sql 文件夹下有的是一个几十 MB 的单文件 .sql有的是按结构、初始数据、存储过程拆成的多个脚本。拿到包先把这个文件夹完整看一遍搞清楚你面对的是哪种形态。3.1 SQL 脚本执行顺序结构、种子数据、存储过程一个文件翻车全链路断先分清单文件还是多文件。单文件脚本理论上一次执行就能建库建表但实际中经常翻车脚本头部的IF DB_ID(MallDB) IS NULL CREATE DATABASE...在低权限账号下执行会直接报错脚本中间如果不带 GO 分隔符建表和插入语句混在同一个批次里SSMS 能过换成程序里的 ADO.NET 执行就报对象名无效这两类问题我都遇到过。多文件脚本就要注意顺序了。常规顺序是先建库建表再插基础字典数据分类、配送方式、支付方式再插测试商品数据最后跑存储过程和视图。最怕的是文件之间存在外键依赖先执行的那批引用了后建的表直接报外键冲突。正确做法是先用文本编辑器打开每个脚本的头几行确认是建库建表的还是 INSERT 数据的分清楚再执行。-- 常见建库脚本开头先查是否存在再建库注意排序规则 IF DB_ID(MallDB) IS NULL BEGIN CREATE DATABASE MallDB COLLATE Chinese_PRC_CI_AS; END GO USE MallDB; GO -- 建表商品表金额用 DECIMAL 不用 float库存用 INT CREATE TABLE dbo.Goods ( Id INT IDENTITY(1,1) PRIMARY KEY, GoodsName NVARCHAR(200) NOT NULL, Price DECIMAL(18,2) NOT NULL, Stock INT NOT NULL DEFAULT 0, ImgUrl NVARCHAR(500) NULL ); GO这段脚本的逻辑是先用IF DB_ID判断避免重复建库报错COLLATE Chinese_PRC_CI_AS指定中文排序规则否则后面中文模糊查询的结果可能不符合预期。Price用DECIMAL(18,2)而不是float是因为浮点类型在累计金额、对账时会有精度误差这在商城业务里不能忍。Stock用INT第五章我会讲为什么扣库存必须带条件更新。注意脚本编码是隐形杀手。UTF-8 无 BOM 的脚本导入到排序规则不对的实例中文数据会变成乱码。SSMS 打开小文件一般没事用命令行批量执行时务必先确认编码。3.2 修改连接串web.config 与 appsettings.json 的差异老项目的连接串在 Web.config 的connectionStrings节点里Core 项目在 appsettings.json 的 ConnectionStrings 配置段。套路一样但有个坑老源码经常把连接串同时写在 web.config 和某个 DBHelper 类的构造函数里改了一处漏了一处跑起来还是连不上。拿到包先全局搜索连接串字符串确认一共有几处需要改。!-- Web.config 老式写法注意 MARS 参数老代码很容易踩 -- connectionStrings add nameMallConn connectionStringServerlocalhost\SQLEXPRESS;DatabaseMallDB;User Idsa;PasswordYourPass123;MultipleActiveResultSetstrue; providerNameSystem.Data.SqlClient / /connectionStrings对应 asp.net core 项目配置长这样{ ConnectionStrings: { MallConn: Serverlocalhost;DatabaseMallDB;User Idsa;PasswordYourPass123;TrustServerCertificatetrue; } }连接串里最常被忽略的参数是MultipleActiveResultSetstrue。老代码经常在同一个连接上先开 DataReader 再执行另一个查询没有这个参数会随机报已有打开的与此连接关联的 DataReader属于那种不报错但时不时抽风的典型问题。本地开发我习惯用 Windows 身份验证Integrated Securitytrue省去密码配置发布到服务器再改成 SQL 账号权限只给这个库的读写别用 sa。3.3 启动顺序与验证先起 Api 再起 Web用浏览器和 curl 确认跑通整个项目有固定顺序先启动 Api 项目确认接口能返回 JSON再启动 Web 门户和 Admin 后台最后才用微信开发者工具打开小程序端。原因很简单小程序端所有页面都依赖接口Api 没起来前端怎么调都是白屏你还会误以为是前端代码有问题。Framework 项目在 VS 里右键 Api 项目设为启动项目F5 用 IIS Express 跑asp.net core 项目可以直接命令行# asp.net core 项目先还原依赖再指定端口启动 cd src/Mall.Api dotnet restore dotnet run --urls http://localhost:5000启动后用 curl 验证一个不需要登录的接口最常见的健康检查是商品列表curl -s http://localhost:5000/api/goods/list | head -c 500如果返回一串 JSON 而不是错误页说明数据库连接、路由、模型绑定都是通的。返回的 JSON 里注意看code字段很多源码的约定是{ code: 0, data: [...] }code非 0 说明业务层有错。这时看控制台输出或 IIS Express 日志多半能定位到是哪条 SQL 报错优先检查表名和字段名跟实体类是否对得上老源码里命名不一致的情况很常见。4. 小程序商城对接wx.login 登录态、请求封装与支付回调验签小程序商城的技术含量集中在三条链路登录、请求鉴权、支付回调。这三条做不对商品页做得再好看也白搭。这一章全部给可抄的代码但有个前提你要先想清楚这套源码的小程序端如果是后来补的接口设计可能跟原生商城前端不一样对接之前先把 Api 项目里的控制器列表过一遍确认有哪些接口可用。4.1 wx.login 换 openid服务端换 token别把 AppSecret 给前端小程序里没有 Cookie 概念唯一的身份锚点是微信的 openid。标准流程是wx.login 拿到临时 code传给服务器服务器拿 code 加上 AppID 和 AppSecret 去微信接口换 openid 和 session_key。AppSecret 是这家商城的命根子一旦泄漏别人能用你的 AppID 做任何事所以这串东西只能存在服务端配置里绝不能写进小程序代码。// 服务端code 换 openid再生成业务 token [Route(api/wx/login)] public async TaskIActionResult Login(string code) { // 微信官方接口js_code 是一次性的两分钟内有效 var url $https://api.weixin.qq.com/sns/jscode2session? $appid{_wxAppId}secret{_wxSecret}js_code{code}grant_typeauthorization_code; var json await _httpClient.GetStringAsync(url); var res JsonConvert.DeserializeObjectWxSession(json); if (string.IsNullOrEmpty(res.OpenId)) { // errcode 40029 表示 code 无效多半是前端用了过期 code return Json(new { code 400, msg res.ErrMsg }); } // 生成自己的 tokenopenid 不要直接下发防止被伪装身份 var token Guid.NewGuid().ToString(N); _cache.Set($mall_token_{token}, res.OpenId, TimeSpan.FromDays(7)); return Json(new { code 0, data new { token } }); }这段代码的关键参数jscode2session的 code 有效期只有五分钟且只能用一次前端重放同一个 code 必然失败所以失败时应该让前端重新走wx.login。token 用 GUID 直拼看起来简陋但对大部分商城够用了想更严谨就把 token 绑到用户表的主键上存 Redis 并设置过期时间后端每次请求查一次缓存验证。缓存过期时间我习惯设 7 天跟微信的 session_key 有效期对齐太短会导致用户频繁重新登录。4.2 请求封装小程序端不认 Cookie用 header 存 token 统一处理 401老商城源码如果是靠 Session 认人的小程序端一接就翻车——因为wx.request不会像浏览器那样自动携带 Cookie更不会帮你记住服务器种下的 Set-Cookie。这是老 ASP.NET 项目对接小程序的经典事故现场我在第五章会再讲一个具体案例。对接老源码的第一件事就是把登录态从 Session 改成 token 模式。// 小程序端 utils/request.js统一 baseUrl、统一带 token、统一处理 401 const BASE_URL https://yourmall.com; function request(path, data, method GET) { return new Promise((resolve, reject) { wx.request({ url: BASE_URL path, method, data, header: { Authorization: Bearer wx.getStorageSync(token) }, success(res) { // 约定code 非 0 是业务失败401 是登录态过期 if (res.statusCode 401 || (res.data res.data.code 401)) { // 先清掉过期 token再重新走一遍 wx.login 并重放当前请求 wx.removeStorageSync(token); reLogin().then(() request(path, data, method).then(resolve, reject)); return; } resolve(res.data); }, fail: reject }); }); } function reLogin() { return new Promise((resolve, reject) { wx.login({ success(res) { request(/api/wx/login, { code: res.code }, POST) .then(r { wx.setStorageSync(token, r.data.token); resolve(); }) .catch(reject); } }); }); }这个封装解决了三个问题token 统一注入避免每个页面写一遍 header401 自动重登用户无感续期所有请求走 Promise页面代码可以放心用 async/await。代价是reLogin里调用了request本身如果登录接口自身返回 401 会死循环所以登录接口的返回约定要单独处理一般把它的 code 定为 0 或 400不要用 401。4.3 微信支付回调先验签、比金额、做幂等再更新订单支付是商城最不能出错的环节。小程序端调wx.requestPayment之前服务器要先调微信统一下单接口拿到 prepay_id 和签名参数。下单那一段各源码实现差异很大但回调验签这一段是通用的直接决定你能不能安全收款。回调里拿到的信息必须跟订单表做交叉验证这才是防篡改的关键。// 支付回调微信用 XML POST 通知先验签再改订单最后必须返回 SUCCESS [Route(api/pay/notify)] public string Notify() { var xml ReadRawBody(); // 拿到微信 POST 过来的原始 XML if (!WxPaySign.Verify(xml, _merchantKey)) return xmlreturn_code![CDATA[FAIL]]/return_codereturn_msg![CDATA[sign error]]/return_msg/xml; var result WxPayResult.FromXml(xml); var order _orderRepo.GetByNo(result.OutTradeNo); if (order null) return FailXml(order not found); // 幂等处理已经支付过的订单直接返回 SUCCESS防止重复通知重复入账 if (order.Status OrderStatus.Paid) return SuccessXml(); // 金额以分为单位必须和订单金额比对防篡改 if (order.AmountInFen ! result.TotalFee) return FailXml(amount mismatch); _orderRepo.MarkPaid(order.Id, result.TransactionId); return SuccessXml(); }回调里有三个必须守住的规矩第一验签不通过直接返回 FAIL让微信重试但千万别在日志里打印完整密钥第二金额必须是整数分而且和订单表逐位比对否则会被构造回调刷订单状态第三幂等判断放在改状态之前微信的支付通知会重试 25 次不幂等就会重复发货或重复加余额。另外回调地址必须是外网 HTTPS 能访问到的 URL本地调试可以先用内网穿透工具把端口映射出去再把回调地址配成穿透域名。5. 避坑Session 失效、脚本中断、支付不回调与并发扣库存这一章是我在这类商城源码上反复踩过的坑全部按现象 → 原因 → 解决来写每一条都值得保存到自己的部署笔记里。这些坑的共同特点是不报编译错误不在日志里留明显痕迹但会在线上悄悄咬你一口等用户投诉了才暴露。5.1 小程序请求一会儿登录失效一会儿正常Cookie 与 Session 的错位现象小程序端登录后能看几分钟商品点进详情页或加购物车就报请先登录刷新又偶尔正常。原因老源码的登录态存在 ASP.NET Session 里靠浏览器 Cookie 维系小程序wx.request不维护 Cookie服务端只能靠前端手动带上来的会话标识认人。如果前端只在登录时把 sessionId 塞进 Storage而后端 Session 有滑动过期时间操作一慢就过期表现就是时好时坏非常玄学。解决把接口鉴权从 Session 改成 token或者在前端请求封装里手动维护ASP.NET_SessionId。我一般直接改 token登录接口返回 token写进utils/request.js的 header后端用过滤器统一校验。改动成本大约半天换来的是不再被 Session 过期折腾。5.2 SQL 脚本执行到一半中断版本、编码与批次问题现象在 SSMS 里打开完整 .sql点执行跑了一百多行后报错停止前面建的表没回滚后面建的表没了。原因一是脚本里混着老版本 SQL Server 语法新实例兼容但某些系统存储过程行为变了二是脚本文件是 GBK 编码而 SSMS 按 UTF-8 读中文注释或数据变成乱码导致语法错误三是文件里包含 GO 批处理指令放在程序里按整段执行就会报错。解决按文件拆分执行先建库建表再插数据最后跑存储过程执行前统一把脚本另存为 UTF-8 with BOM这一步能根治乱码如果是交付给客户我一般会生成一份一键导入小工具用 sqlcmd 按文件顺序执行并输出日志哪一步失败一眼就能看到。5.3 支付成功但订单还是未付款回调地址与 SUCCESS 返回现象用户微信里扣了钱商城后台订单状态还是待付款用户反复投诉开发者查日志发现支付回调根本没到。原因回调地址配置成了 http://localhost:5000/api/pay/notify微信服务器当然访问不到或者回调接口收到通知后处理异常抛了 500没有按协议返回 SUCCESS微信会重试 25 次时间长了就放弃。解决先确认你在微信商户平台配置的 API 回调地址是公网可访问的 HTTPS 地址再在回调入口第一行写日志把原始 XML 落盘没日志一切排查都是猜。本地联调用内网穿透映射到本地端口再把回调 URL 配成穿透域名验证通过后再切正式域名。5.4 并发下单库存变负数条件更新与行锁现象活动预热时用户疯狂抢运营后台的库存变成 -12还有不少订单付款后没法发货。原因扣库存代码通常是三段式查出库存 → 判断大于 0 → 减一。两个请求同时通过判断后写覆盖先写库存就穿底。商城源码里这种写法非常普遍属于最典型的并发翻车不是线上压测根本暴露不出来。解决扣库存的 SQL 必须写成条件更新影响行数为 0 就说明库存不足配合事务把扣库存和创建订单放同一个事务里订单失败就回滚-- 条件更新stock 要扣的数量才扣返回影响行数判断成败 UPDATE dbo.Goods SET Stock Stock - count WHERE Id goodsId AND Stock count;普通商城用上面的条件更新已经足够活动场景再把扣减动作放到 Redis 的 DECR 上做预扣但那是另一个复杂度层级别一上来就上容易把自己绕进去。5.5 API 返回 /Date(1600000000000)/ 时间格式小程序端解析崩溃现象商品详情页的时间字段显示成一串/Date(1600000000000)/订单列表按时间排序全乱。原因老项目用 Newtonsoft.Json 的默认 DateTime 序列化输出的是这种微软私有的 Date 格式小程序端new Date(str)解析不了黑匣子一样看不出原因。解决在 asp.net core 项目里配置 JSON 序列化时换成 ISO 格式// 统一时间格式为 ISO 8601小程序端 new Date(2024-01-01T10:00:00) 可直接解析 services.AddControllers() .AddNewtonsoftJson(opts opts.SerializerSettings.DateFormatHandling DateFormatHandling.IsoDateFormat );顺手把时区也统一了数据库存 UTC接口层转北京时间输出否则不同服务器的时区会导致订单时间对不上。这个问题在 Framework 老项目里更隐蔽因为它只在 JSON 输出那一层有问题页面端 Razor 渲染反而正常所以很多人查半天查不到。6. 上线前用一把 curl 脚本做接口回归和部署自检发布不等于部署完。配置好服务器、小程序端也换了正式域名之后我做的最后一件事是回归验证拿 curl 把商城核心链路按顺序打一遍比任何代码评审都管用。6.1 核心接口逐个打一遍HTTP 200 不等于业务成功#!/bin/bash # 上线前接口回归依次检查核心接口的 HTTP 状态码与业务 code BASEhttps://yourmall.com TOKEN$(curl -s -X POST $BASE/api/wx/login -d codetest_code \ | python3 -c import json,sys;print(json.load(sys.stdin)[data][token])) for item in goods/list goods/detail?id1; do res$(curl -s -o /tmp/r.json -w %{http_code} \ -H Authorization: Bearer $TOKEN $BASE/api/$item) code$(python3 -c import json;print(json.load(open(/tmp/r.json))[code]) 2/dev/null) echo $item - http$res code$code done脚本把 HTTP 状态码和业务 code 分开看HTTP 200 只代表请求送达code 非 0 才是业务层报错。登录里的 test_code 是占位符真实联调时换成 wx.login 拿到的 code。把订单创建、支付回调、订单查询也按这个格式加进去十几秒就能把全站主链路过一遍发布后每天早上跑一次接口挂了比你先知道。回归通过后我会再做一遍冷启动自检换一台干净机器按部署文档从装运行时、还原数据库、改连接串、配 HTTPS、配小程序合法域名完整走一遍把文档缺的步骤补进去。我吃过最大的亏就是没写这台机器已经装过什么结果客户换台服务器直接部署失败。最后说句个人习惯每次发布前支付回调地址、AppSecret、连接串这三样东西单独列一个清单核对一遍。这三个位置出问题都不报明显错误而是用户悄悄流失等你发现已经晚了。希望这篇能帮你接手这套 ASP.NET 商城源码时少绕几个弯把时间留给真正的业务功能。本文还有配套的精品资源点击获取