简介：基于C#的微信小程序在线购物商城源码是一份面向毕业设计场景的完整前后端项目，适合正在准备毕设或学习C#服务端与微信小程序开发的读者。前端包含wxml、wxss、js及json等文件，覆盖商品展示、购物车、订单提交等交互；后端以cs、aspx、ashx文件为主，实现登录、商品管理、支付回调等业务逻辑，并配套sql、mdf、ldf数据库文件和config配置，便于本地还原与发布部署。整个压缩包共1930个文件，约26.9MB，其中480个cs文件对应C#业务逻辑，451个gif、162个png、108个jpg构成图片与动图素材，140个js负责前端交互，125个aspx和23个wxml/wxss提供Web与小程序页面，另含dll、pdb依赖库及数据库、配置等文件。目前已有772人学习下载。从工程结构看，该源码将小程序前端、C#后端、数据库与部署资源整合在一起，可作为可运行的参考工程，也能帮助读者梳理从数据库设计、服务端接口到前端渲染的完整开发链路，对理解商城类项目很有价值。
1. 基于C#的微信小程序在线购物商城源码：先弄懂它再决定要不要下
做毕业设计时，导出一个“基于C#的微信小程序在线购物商城源码.zip”，里面是Global.asax、upload_ajax.ashx、GetMsg.ashx、file_manager_json.ashx、admin_ajax.ashx、payinfo.ashx这些文件，第一反应是“这怎么跟前端拼起来”。我最初也以为C#只能做桌面程序，直到把这个包解开才发现，微信小程序商城的核心后台完全可以由C#写成一组轻量HTTP接口，小程序端只负责发请求、渲染列表和购物车。对于需要用C#交毕业设计的人，或者想快速搭一个完整前后端分离商城做技术验证的人，这份源码能解决“用什么思路把下单、上传、积分编辑串起来”的问题。它适合有一点ASP.NET基础、但不熟悉小程序后端设计的开发者，今天我就按自己的拆包经验把它一层层讲清楚。
2. C#后端核心：从.ashx处理器看服务端逻辑
2.1 为什么毕设项目会选.ashx而不是MVC
看到这一堆.ashx文件，很多人第一反应是“这技术是不是过时了”。实际上在微信小程序这种轻后端场景里，.ashx比MVC更合适。因为小程序后端不关心页面渲染，只需要返回JSON数据，而.ashx作为一个HTTP处理程序，能直接接收请求、操作数据库、输出字符串，没有任何视图层的开销。
传统ASP.NET Web Forms里每个页面有.aspx和.cs，而.ashx是纯处理器，只有一个文件，代码路径短，适合做接口。比如项目中出现的upload_ajax.ashx负责接收上传请求，payinfo.ashx返回支付信息，这些职责单一的处理文件对于毕业设计来说，维护成本远低于一个完整MVC项目。选型上还有一个隐性原因：很多高校的C#课程还停在Web Forms阶段，.ashx是过渡到接口开发最自然的台阶。
我一般会这么判断一个后端文件该不该拆成.ashx：只要前端通过URL直接调用并拿字符串返回值，就用它；如果涉及表单提交和跳转页面，就用.aspx。这个商城源码明显是按前者设计的。
2.2 逐个拆核心文件：Global.asax / upload_ajax.ashx / payinfo.ashx
先看Global.asax，它是整个应用的全局入口。常见写法里Application_Start负责初始化一些通用配置，比如定时任务或缓存；Application_Error统一捕获异常并写日志。下面这段代码是在商城项目里最常见的全局错误处理逻辑：
protected void Application_Error(object sender, EventArgs e) { Exception ex = Server.GetLastError(); // 把异常写入文本日志，方便排查线上问题 System.IO.File.AppendAllText( Server.MapPath("~/logs/error_" + DateTime.Now.ToString("yyyyMMdd") + ".log"), DateTime.Now + " " + ex.Message + "\r\n"); Server.ClearError(); Response.Write("{\"code\":500,\"msg\":\"server error\"}"); }这段逻辑不难理解，异常发生时它会把错误信息追加到当天的日志文件，同时返回一个固定结构的JSON，避免微信小程序收到乱码或超时。参数方面，Server.MapPath用于定位日志目录，Response.Write直接向客户端输出，code字段用来让前端判断请求状态。
再看upload_ajax.ashx，这是商城上传商品图片或用户头像的接口。我拆过类似项目，一般它会先读Request.Files里的文件，保存到指定目录，再把访问路径返回给前端。下面是一个简化的实现：
public void ProcessRequest(HttpContext context) { context.Response.ContentType = "text/plain"; HttpPostedFile file = context.Request.Files["file"]; string saveDir = context.Server.MapPath("~/uploads/"); string fileName = DateTime.Now.ToString("yyyyMMddHHmmss") + "_" + file.FileName; file.SaveAs(saveDir + fileName); context.Response.Write("{\"url\":\"/uploads/" + fileName + "\"}"); }参数说明：Request.Files["file"]对应前端上传时的字段名，SaveAs把文件存到服务器物理路径，返回的url是相对路径，小程序端用这个拼接完整图片地址。注意这里没有校验文件类型和大小，实际项目里必须加，否则就是后面要说的坑。
payinfo.ashx处理支付信息。微信小程序支付需要后端生成预支付单并返回参数，这个接口一般接收前端传来的订单号，拼好签名后返回给小程序。它里面最常见的代码是计算签名，我挑关键片段：
SortedDictionary<string, string> dict = new SortedDictionary<string, string>(); dict.Add("appid", appid); dict.Add("mch_id", mchId); dict.Add("out_trade_no", orderNo); dict.Add("total_fee", totalFee); string sign = SignatureHelper.Sign(dict, apiKey);命名表不复杂，关键是SortedDictionary保证参数按字典序排序，然后用商户API密钥做MD5签名。这就是微信支付要求的规则，前端拿到这个签名才能发起支付弹窗。GetMsg.ashx和admin_ajax.ashx类似，一个负责返回商品留言或系统消息，另一个处理后台管理员的增删改请求，结构上都是接收参数、调用数据库、返回JSON，没有太大差异。
2.3 数据库连接与配置方式
源码包里的web.config肯定配置了数据库连接字符串。常见做法是用ConnectionString标记，比如：
<connectionStrings> <add name="ShopDB" connectionString="Data Source=localhost;Initial Catalog=ShopDB;User ID=sa;Password=123456;" providerName="System.Data.SqlClient"/> </connectionStrings>代码里读取时一般这样写：
string connStr = ConfigurationManager.ConnectionStrings["ShopDB"].ConnectionString; using (SqlConnection conn = new SqlConnection(connStr)) { // 打开连接，执行查询 }参数说明：Data Source是你的SQL Server地址，本地开发用localhost或. ，生产环境换成公网IP；User ID和Password对应SQL Server登录凭据。我遇到过不少人在这一步翻车，数据库实体名不对，或者密码里有特殊字符没做转义，导致后台所有接口都报510错误，后面避坑章节会细说。
3. 微信小程序前端对接C#接口：登录、商品、下单全流程复现
3.1 wx.request请求地址拼接与参数规范
小程序端发HTTP请求用的API是wx.request，后端这些.ashx就是它的目标。在开发阶段，后端跑在本地电脑，小程序开发者工具里的URL必须填局域网IP或者本地回环地址。我在实际项目中会单独写一个config.js，把所有接口地址集中管理：
const BASE_URL = 'http://localhost:8080'; module.exports = { loginUrl: `${BASE_URL}/GetMsg.ashx?action=login`, uploadUrl: `${BASE_URL}/upload_ajax.ashx`, getGoodsUrl: `${BASE_URL}/GetMsg.ashx?action=goodslist`, createOrderUrl: `${BASE_URL}/payinfo.ashx?action=createOrder` }参数说明：BASE_URL对应IIS Express的监听地址，微信开发者工具必须要开启“不校验合法域名”才能访问非HTTPS接口，我一般会在开发阶段直接勾选这个选项，否则请求会被拦截。每个接口通过action参数区分行为，这在.ashx文件里是一个固定套路，代码里用Request["action"]判断进入哪个分支。
3.2 登录态与Session处理
微信小程序没有Cookie，但C#后端可以用Session来保存用户状态。首次登录时前端调用wx.login拿到code，传给后端，后端再调用微信官方接口换取openid。整个流程在小程序端看起来是这样：
wx.login({ success: res => { console.log('获取微信登录code成功', res.code); wx.request({ url: `${BASE_URL}/GetMsg.ashx?action=login`, method: 'POST', data: { code: res.code }, success: response => { const data = response.data; if (data.code === 0) { wx.setStorageSync('sessionKey', data.sessionKey); wx.setStorageSync('userId', data.userId); } } }); } });代码逻辑不复杂，wx.login只负责拿临时code，真正的身份交换在后端完成。后端拿到code后调用微信的api.weixin.qq.com/sns/jscode2session接口，用appid和secret换openid，再把openid存到数据库同时生成一个sessionKey返回给小程序。这里参数顺序不能乱，appid、secret、js_code、grant_type，少一个都会报400错误。我平时调试这个接口时，习惯先在浏览器里直接访问微信那个URL，确认返回结果再回头查C#代码。
3.3 商品列表与图片上传接口对接
商品列表是典型的GET接口，前端请求后拿到JSON数组，再用setData渲染到页面上。比如请求商品列表：
wx.request({ url: `${BASE_URL}/GetMsg.ashx?action=goodslist`, method: 'GET', success: res => { const goods = res.data.data || []; this.setData({ goodsList: goods }); } });这里的data字段是数组，每项包含id、name、price、imagePath等属性，对应数据库商品表。imagePath是后端返回的相对路径，前端要在渲染前拼接完整的URL：
const baseImage = 'http://localhost:8080'; goods.forEach(item => { item.imageUrl = baseImage + item.imagePath; });上传图片的场景在小程序端会稍微复杂一点，wx.uploadFile专门负责这种multipart上传：
wx.uploadFile({ url: `${BASE_URL}/upload_ajax.ashx`, filePath: tempFilePath, name: 'file', success: res => { const data = JSON.parse(res.data); this.setData({ avatarUrl: data.url }); } });参数说明：name字段必须和后端代码里Request.Files["file"]的键名一致，否则后端取不到文件。filePath是你的图片临时路径，可以通过wx.chooseImage获得。后端返回的url同样是个相对路径，需要拼接host才能显示。
3.4 Postman调试C#接口的实用设置
小程序端调试不如Postman直观，我会先把所有.ashx地址放到Postman里跑。启动项目后，用Postman打开，选择POST方法，填URL，在Body里选x-www-form-urlencoded，把action参数和code参数填进去。发送后看返回结果，如果返回了JSON说明接口是通的，如果返回HTML错误页说明后端抛异常了。
具体到调试上传接口时，Postman的做法是Body里选form-data，然后把key设为file，类型从Text改成File，再选择一个图片文件。这个操作逻辑和小程序端wx.uploadFile完全一样，后端拿到文件后返回路径，整个过程就验证通过。我在实际调试中发现，很多接口报错是因为参数名写错了，比如后端取的是action，前端传的是type，Postman正好能帮你快速定位这种低级问题。
4. 踩坑记录：C#商城源码从下载到能跑的四个典型坑
4.1 坑一：数据库连接失败，提示用户登录失败
现象：小程序里点击登录，后端返回code为500，日志里出现“Cannot open database ShopDB requested by the login. The login failed.”。
原因：数据库实体没有创建，或者connectionStrings里的数据库名和实际库名不一致。我碰到过一次，源码包自带SQL脚本，但是很多人只执行了表结构脚本，没有创建数据库本身。
解决：先在SQL Server Management Studio里手动创建数据库ShopDB，再执行源码包里的SQL脚本。如果还是失败，检查web.config里的User ID和Password是否和SQL Server实例的登录名一致。我一般会在项目启动前先说清楚，连接字符串里的Password如果包含特殊字符，比如@符号，必须用双引号包裹或者转义。
4.2 坑二：图片上传成功但小程序页面里不显示
现象：上传接口返回了正常路径，图片文件也确实保存在服务器uploads目录里，但小程序端img标签一片空白。
原因：开发阶段我们用的URL是http://localhost:8080，但在真机预览时，手机不能访问PC的localhost，而且请求域名如果是HTTP，会触发微信的域名白名单校验。更深一层是上传保存时文件名带了中文，导致URL编码后访问不到。
解决：把BASE_URL改成电脑局域网IP，比如192.168.1.100:8080，同时关闭开发者工具的“不校验合法域名”选项，仅限开发阶段。文件名处理方面，我习惯在后端代码里统一用时间戳加随机数重命名文件，从根本上避免中文和空格带来的坑。从那以后我每次看上传代码，第一件事就是检查文件名是否包含非ASCII字符。
4.3 坑三：支付接口返回签名错误
现象：payinfo.ashx返回给小程序端的sign参数在拉起支付时提示“签名错误”。
原因：签名算法和微信支付要求的规则不一致。常见错误是参数名没有按字母排序，或者参与签名的参数里包含了空值，又或者apiKey用的是测试key而不是商户平台上的正式key。
解决：严格按微信官方文档里的规则来，SortedDictionary自动排序后拼接成key=value&...&key=某个值，最后MD5。我排查时会在C#代码里把要参与签名的字符串用Content.Write输出到接口响应里对比一眼。还有一个隐蔽点，签名的字符串里不能包含transfer里的空格，必须直接用原始字符串。
4.4 坑四：微信开发者工具真机预览时接口全部无响应
现象：在开发者工具里跑得好好的，一到真机预览，所有接口都返回超时或网络错误。
原因：真机不能访问PC的localhost，这是最直接的。第二个原因是Windows防火墙挡住了小程序发出的入站请求，IIS Express默认只在localhost端口监听。
解决：先查PC的局域网IP，把BASE_URL改成这个IP。如果还是不通，打开Windows防火墙的高级设置，为对应端口添加一条入站规则。端口号在IIS Express的applicationhost.config里，默认是8080或44300，我一般会把项目属性里的“使用IIS Express”改成固定端口，方便防火墙配置。这个问题我遇到过不止一次，后来习惯在启动项目前先ping一下电脑IP，确认网络畅通再调试。
5. 部署验证：把C#商城源码跑通并自查接口
5.1 本地IIS Express接上SQL Server
解压源码后，用Visual Studio打开解决方案，先确认引用里有System.Web和System.Configuration。在web.config里把连接字符串改成你本机的SQL Server信息，然后右键项目选择“属性”，把“开始执行时”改为“Web服务器”而不是“调试代码”。按F5启动后，浏览器会自动打开一个URL，类似http://localhost:8080，这个地址就是小程序的BASE_URL。
如果你跑起来发现页面报HTTP 500，先检查该项目对应的应用程序池是否启用32位模式，这个设置在IIS Express的applicationhost.config里，一般设置为true就OK。整个过程我建议在命令行跑一次IIS Express.exe确认端口占用情况，用下面这种方式启动：
"C:\Program Files\IIS Express\iisexpress.exe" /path:C:\你的项目路径 /port:8080参数说明，/path指向源码目录，/port指定监听端口。如果之前跑了好几个项目，端口冲突概率很大，这个命令能强制指定端口，避免Windows提示端口被占用。
5.2 接口自查清单和curl快速验证
启动项目后，我一般会用一组简短命令快速验证关键接口是否正常。比如登录接口返回JSON，商品列表接口能拉到数据，上传接口能处理文件。在命令行里用curl来测试是最快的：
curl -X GET "http://localhost:8080/GetMsg.ashx?action=goodslist" curl -X POST "http://localhost:8080/upload_ajax.ashx" -F "file=@C:\test.jpg" curl -X POST "http://localhost:8080/GetMsg.ashx?action=login" -d "code=testcode123"这里参数没变，只是换了个前端。第一个命令用GET拉商品列表，看到data数组就说明接口通；第二个命令用-F参数模拟表单上传，注意文件路径必须加引号防止空格分割；第三个命令模拟小程序登录，code字段可以先填一个假值，只要后端不报异常就说明参数名对得上。
5.3 验证时多留意数据库操作日志
我在验证时还会打开SQL Server Management Studio，执行SQL Server Profiler跟踪数据库查询。因为有些接口返回200但数据没变化，这时候需要看SQL语句是不是真的执行了。如果发现查询超时或者锁冲突，多半是事务没提交，检查.ashx里有没有显式调用transaction.Commit()。这是我在调试这个商城源码时踩得最多也最不容易发现的点，接口不报错但数据就是写不进去。
把那以后的习惯分享给你：每拿到一份C#后端源码，第一先把连接字符串改成环境变量加载而不是写死在web.config里，第二用开关控制全局错误日志的详细程度，第三所有接口统一返回{code:0,data:...}格式，方便小程序端统一处理。这份基于C#的微信小程序在线购物商城源码，如果能按上面步骤跑通，后端处理和前端对接的基本思路你就能完整掌握一遍，以后换任何语言写小程序接口都心里有数。希望帮到你。
本文还有配套的精品资源，点击获取
