简介基于C#的微信小程序在线购物商城毕业设计源码包面向计算机专业学生、毕业设计选题者以及微信小程序开发初学者完整呈现从微信小程序前端到ASP.NET后端的商城项目实现过程。围绕用户登录、商品分类展示、购物车、订单处理等典型功能代码按前端交互、后端接口、数据访问分层组织便于理解整个商城业务闭环。压缩包共1930个文件、26.9MB核心类型包含480个.cs后端逻辑类、125个aspx及ashx页面处理文件、140个js交互脚本、24个wxss和23个wxml组成的小程序界面、23个json配置以及sql数据库脚本目录划分明确能够直接反映项目的模块结构。目前已有665人学习适合毕业设计、课程实训或全栈开发入门时对照阅读资料中除了可运行源码还包括数据库脚本、部署配置、图片素材与说明文档既能帮助梳理购物商城的表结构设计、接口调用和界面渲染思路也能作为二次开发、功能扩展或答辩展示的完整样例。1. 拿到这份C#微信小程序商城源码时先搞懂它是什么解压这类“基于C#的微信小程序在线购物商城源码.zip”压缩包很多人第一反应是先找首页文件。但这类项目的核心其实不在前端页面而在后端C#写的那套 HTTP API 接口。小程序端只是把接口返回的数据渲染成商品列表和订单页面真正管库存、算价格、处理支付的是 C# 服务。整套代码适合两类人一是拿它做毕业设计需要快速跑通演示链路二是小团队想省掉从零写后台的时间在现有代码上改改成自己的商城。动手之前先做个心理建设业务代码一般都能跑真正卡你的是登录态和微信支付回调这两条链路后面会专门讲。2. 先把C#后端跑起来工程结构与商品接口2.1 常见的压缩包内工程结构先认路再动手一套典型的C#微信小程序商城源码最常见的组织方式是“两个文件夹一个数据库脚本”。后端文件夹通常是一个 ASP.NET Core WebApi 工程现在绝大多数源码都基于 .NET Core 3.1、.NET 6 或 .NET 8里面按照 Controller、Service、Model 三层拆开也有部分老项目用 ASP.NET Framework 4.x 配合 MVC 模板打开工程文件就能分辨。前端文件夹则是微信小程序原生工程里面有 app.js、app.json 和 pages 目录如果你的压缩包里出现的是 uni-app 工程目录那就是用 uni-app 写的跨端项目本质差别不大只是编译产物不同。数据库脚本通常是 SQL 文件支持 SQL Server 的还是支持 MySQL 的取决于作者原先的部署环境。先从后端动手是铁律因为小程序端所有页面都要靠接口喂数据。先把后端项目用 Visual Studio 或 Rider 打开确认 NuGet 包能否还原成功常见依赖是 Entity Framework Core、SqlConnection、Newtonsoft.Json 或 System.Text.Json。如果还原失败先检查本机 .NET SDK 版本是否等于或高于工程目标框架版本——这是第一个常见卡点现象是编译报一堆“找不到程序集”或“NuGet 还原失败”。2.2 商品列表接口先跑通第一个 C# 数据链路后端的核心业务基本围绕商品、购物车、订单三个模块转。其中商品列表是最适合用来验证“后端是否活着”的接口因为它不涉及登录态也没有支付签名最容易跑通。写一套常见的商品列表接口通常是拆成 Controller Service Repository 三层但也有简化版直接写在 Controller 里。下面这段代码是主流的 Controller 层写法EF Core 直接查库[ApiController] [Route(api/product)] public class ProductController : ControllerBase { private readonly AppDbContext _context; public ProductController(AppDbContext context) { _context context; } [HttpGet(list)] public async TaskActionResultProductListResponse List(int page 1, int pageSize 10) { if (page 1) page 1; if (pageSize 50) pageSize 50; var query _context.Products .Where(p p.Status 1 p.Stock 0) .OrderByDescending(p p.CreateTime); var total await query.CountAsync(); var items await query .Skip((page - 1) * pageSize) .Take(pageSize) .Select(p new ProductDto { Id p.Id, Name p.Name, CoverImage p.CoverImage, Price p.Price, Stock p.Stock, Sales p.Sales }) .ToListAsync(); return Ok(new ProductListResponse { Total total, Items items }); } }这段代码的关键点不在语法而在三点约定第一Status1 过滤了下架商品Stock0 过滤了无货商品如果小程序里看到“有商品但列表为空”先查数据库里这两个字段第二OrderByDescending(p p.CreateTime) 按上架时间倒序这是商城最常见的默认排序如果你想让销量高的排前面改成 OrderByDescending(p p.Sales)第三分页参数做了下限保护page 最少为 1pageSize 最大 50防止有人恶意传超大分页把数据库拖垮。返回结构统一包成 { total, items }小程序端直接用。真实项目里还会加缓存避免频繁查库但这套最小链路不需要。2.3 数据库连接串与初始化数据别在原库上直接跑正式数据数据库连接字符串写在 appsettings.json 里这是 C# 后端跑不起来的第二大高频原因。常见的默认连接串写法如下{ ConnectionStrings: { Default: Serverlocalhost;DatabaseShopDb;User Idsa;Password123456;TrustServerCertificateTrue; }, Logging: { LogLevel: { Default: Information, Microsoft.AspNetCore: Warning } } }连接串有几个字段需要按你的实际环境改Server 如果是本机就用 localhost如果是远程数据库就写 IP 或域名Password 必须改成你数据库的真实密码千万别用压缩包里的默认值直接连生产库TrustServerCertificateTrue 这个参数是给 SQL Server 用的解决本地开发证书不受信任导致的报错如果报“证书链是由不受信任的颁发机构颁发的”就是少了它。EF Core 的初始化通常会在启动时自动建库建表。常见做法是 Program.cs 或 Startup.cs 里调用 db.Database.Migrate()但很多源码为了省事直接把扩展名为 .sql 的脚本放在 database 目录里需要你手动在数据库工具里执行。建议第一次跑通前先执行 SQL 脚本再启动后端因为脚本里往往带有管理员账号和初始商品数据这对后面测试小程序端至关重要。启动后在后端进程的控制台窗口能看到监听地址通常是 http://localhost:5000然后直接用浏览器访问商品接口地址能返回 JSON 就说明 C# 后端已经活了。这里有个容易混淆的点浏览器能访问不代表微信小程序能访问——小程序端对域名有更严格的限制会放到部署章节展开。3. 小程序端对接C#接口登录态、请求封装与商品渲染3.1 原生微信小程序与uni-app在对接方式上的差别压缩包里的小程序端如果是原生微信小程序页面文件是 .wxml 和 .wxss逻辑文件是 .js如果是 uni-app则是 .vue 单文件组件。两类工程在 request 请求、登录方法、跳转页面上API 都有不少差异。先说原生小程序的写法因为它最贴近标题里的“微信小程序”。请求后端时直接在 onLoad 里调用 wx.request 就能工作但正式做商城不能这么裸调因为每个页面都写一遍成功失败回调代码就失控了。常见做法是封装一个 request.js 工具文件统一处理 baseURL、超时时间、登录失效跳转。这个封装文件在同一套代码里只维护一份后续所有页面引它这是小程序端最值得先动手的地方。uni-app 工程则不同它用 uni.request 发请求接口风格和微信原生接近但你要注意 runtim 平台对象是 uni而不是 wx很多人移植代码时把 wx.request 直接搬进 .vue 文件里运行时直接报 “wx is not defined”。拿到源码先确认用的是哪套别把原生小程序代码复制进 uni-app 里硬改。3.2 request 请求封装与登录态标准做法下面这段 request.js 封装是原生微信小程序里最常见的一套做法它解决三个问题自动带上 token、统一处理 HTTP 错误、登录失效时跳回登录页。代码大概长这样const BASE_URL https://api.example.com; // 改成你的后端域名 const TOKEN_KEY mall_token; function request(method, url, data) { return new Promise((resolve, reject) { const token wx.getStorageSync(TOKEN_KEY); wx.request({ url: BASE_URL url, method: method, data: data, header: { Content-Type: application/json, Authorization: token ? Bearer token : }, timeout: 15000, success(res) { if (res.statusCode 401) { wx.removeStorageSync(TOKEN_KEY); wx.navigateTo({ url: /pages/login/login }); reject(new Error(登录已过期)); return; } if (res.statusCode 200 res.statusCode 300) { resolve(res.data); } else { reject(new Error(HTTP res.statusCode)); } }, fail(err) { reject(err); } }); }); } module.exports { request, BASE_URL };这套封装里有几个参数需要认真对待。timeout 设 15000 毫秒是给弱网环境留缓冲如果用户反馈“转圈很久然后失败”先从网络和域名排查而不是盲目加大超时。Authorization 头用的是 Bearer Token 方案这是 C# 后端最常见的鉴权方式后端在 Startup.cs 里配置了 JWT Bearer 认证的话controller 上打 [Authorize] 特性就会校验这个头。401 状态码统一跳登录页是商城类小程序最常用的会话过期处理方案因为微信小程序的体验要求是“静默过别弹框”。BASE_URL 一般不放真域名真实项目里常见做法是把它放进 app.js 的 globalData 里或者用一个 config.js 单独维护方便按环境切换测试地址和正式地址。3.3 微信登录代码换 token两条不同的登录链路微信商城的登录链路是唯一一个必须严格按顺序走的功能。小程序端先调用 wx.login 拿到临时 code再把 code 发给 C# 后端后端拿 code 去微信的接口换 openid 和 session_key然后给你签发一个自定义 token。前面封装里用的 Authroization 头token 就是这一步的产物。核心代码如下[HttpPost(login)] public async TaskActionResultLoginResult Login(LoginRequest request) { var client _httpClientFactory.CreateClient(); var url $https://api.weixin.qq.com/sns/jscode2session?appid{_config[WeChat:AppId]}secret{_config[WeChat:AppSecret]}js_code{request.Code}grant_typeauthorization_code; var response await client.GetAsync(url); var body await response.Content.ReadAsStringAsync(); var session JsonSerializer.DeserializeWeChatSession(body); if (session.openid null) return Unauthorized(new { message code 无效 }); var user await _context.Users.FirstOrDefaultAsync(u u.OpenId session.openid); if (user null) { user new User { OpenId session.openid, CreateTime DateTime.Now }; _context.Users.Add(user); await _context.SaveChangesAsync(); } var token _jwtService.CreateToken(user.Id.ToString()); return Ok(new { token, userId user.Id }); }这段代码里有几个实际项目中会踩到的点。jscode2session 接口的响应体里不一定有 openid如果 code 被重复使用、过期或者 appid/secret 不匹配返回的是 errcode 和 errmsg所以先判断 openid 为空就返回 401 是防呆设计。第一次登录时用户表里没有记录要用 openid 做主键级别的唯一索引避免并发请求下重复插用户压缩包里的旧代码很多没建唯一索引你直接压测登录就会发现用户表多了两条一模一样的记录。token 建议用 JWT过期时间设 7 天左右比较合理太短用户要反复登录体验差太长又有安全风险。你需要把微信小程序的 AppId 和 AppSecret 填到 appsettings.json 的 WeChat 节点里其中 AppSecret 在微信公众平台的“开发管理-开发设置”里获取这个值敏感别提交进 Git 仓库。4. 下单到支付回调C#后端签名与金额校验4.1 订单表设计里的习惯金额用 decimal状态机要留状态商城里最容易改砸的重灾区是订单模块。订单表通常会设计成一个订单主表加一个订单明细表主表存订单号、用户ID、支付金额、状态、支付时间明细表存商品ID、单价、数量、小计。两个表用 OrderId 关联。这里有一个必须沿用的习惯金额字段一律用 decimal不要用 double 或 float。C# 里 double 是浮点数0.10.2 会得到 0.30000000000000004一旦金额算错对账时会对不上。decimal 是定点数专门干这事。数据库里对应字段用 decimal(18,2)保留两位小数。订单状态字段一般用 int 或 tinyint0 待支付、1 已支付、2 已发货、3 已完成、4 已取消这种数字字典几乎成了商城项目的行业默认习惯少有例外。后端做状态流转时每一步都校验当前状态合法待支付状态才能变成已支付已支付才能变成已发货。如果你拿到源码发现状态流转写得很随意比如从待支付直接跳到已发货那说明作者省略了校验逻辑建议自己补上不然订单管理后台会异常混乱。4.2 JSAPI 支付统一下单与生成支付参数小程序支付用的是微信支付的 JSAPI 模式。整个流程是小程序把订单ID发给C#后端后端用自己的商户号向微信支付服务器发起统一下单微信返回预支付交易会话标识 prepay_id后端再用 prepay_id 生成小程序端 wx.requestPayment 需要的支付参数最后小程序拉起支付面板。这个过程中签名的生成规则非常固定写错一个字符就报签名错误。public string BuildPaySign(SortedDictionarystring, string values, string mchKey) { var sb new StringBuilder(); foreach (var kv in values) { if (!string.IsNullOrEmpty(kv.Value)) sb.Append(${kv.Key}{kv.Value}); } sb.Append($key{mchKey}); using var md5 MD5.Create(); var bytes md5.ComputeHash(Encoding.UTF8.GetBytes(sb.ToString())); var sbHex new StringBuilder(); foreach (var b in bytes) sbHex.Append(b.ToString(x2)); return sbHex.ToString().ToUpper(); }这段代码有三个必须注意的细节。第一SortedDictionary 对参数名按字典序排序微信支付要求所有参与签名的参数按 ASCII 码从小到大排序顺序错了签名必失败。第二拼接字符串时 key 你的商户 API 密钥放在最后这是老版 APIv2 的规则很多源码还在用如果项目要求 APIv3签名方式完全不同需要换用 HMAC-SHA256 并加消息证书。第三MD5 生成的字符串全部转大写微信支付对签名的大小写敏感——签名需要转大写但生成签名的原文里字符串参数不转大小写只转 Key 大小写就行这两个“大写”经常被搞混。最终生成的小程序端参数里paySign 的值就是 BuildPaySign 的返回值package 参数是 prepay_idxxx 这种形式。4.3 支付回调验签别只查 order 已付款支付完成后微信服务器会主动向 C# 后端配置的回调地址 POST 一个 XML 通知。你的后端要回复一个成功的字符串给微信微信才会停止重发。很多源码的回调处理写得过于简陋——拿到通知后不管三七二十一直接更新订单状态这就把安全性完全暴露了。正确的回调处理顺序是先验签名再查订单号最后查金额是否一致。[HttpPost(pay/wxnotify)] public async TaskIActionResult WxNotify() { using var reader new StreamReader(Request.Body, Encoding.UTF8); var xml await reader.ReadToEndAsync(); var values WxPayApi.XmlToDictionary(xml); if (!WxPayApi.VerifySign(values, _config[WeChatMch:ApiKey])) { return Content(xmlreturn_code![CDATA[FAIL]]/return_code/xml, text/xml); } var orderNo values[out_trade_no]; var transactionId values[transaction_id]; var paidAmount decimal.Parse(values[total_fee]) / 100m; // 微信金额单位是分 var order await _context.Orders.FirstOrDefaultAsync(o o.OrderNo orderNo); if (order null || order.Status ! 0) return Content(xmlreturn_code![CDATA[SUCCESS]]/return_code/xml, text/xml); if (order.PayAmount ! paidAmount) return Content(xmlreturn_code![CDATA[FAIL]]/return_code/xml, text/xml); order.Status 1; order.TransactionId transactionId; order.PayTime DateTime.Now; await _context.SaveChangesAsync(); return Content(xmlreturn_code![CDATA[SUCCESS]]/return_code/xml, text/xml); }这段代码里藏着支付链路里最深的坑我挑三个最典型的现象说。现象一订单金额和微信回调金额不一致原因是数据库里存的金额单位是元微信回传的 total_fee 单位是分必须除以 100。现象二用户支付成功后订单状态没变原因多半是你没有在回调里正确处理重复通知同一笔订单微信会重发多次代码里如果没判断 Status ! 0第二次回调就会把订单重复覆盖。现象三回调地址被外网扫描机器乱打返回 SUCCESS 但没处理任何逻辑这也是安全风险解决办法是先用 VerifySign 拦住非微信官方来源的请求。微信支付回调地址必须配置在微信商户平台里而且这个地址必须公网可访问生产环境不能用 localhost。这里有一个反直觉的点明明用户微信里已经扣款成功但商城里订单还是待支付第一排查方向永远是回调不是订单查询接口。5. 部署上线前必查的避坑清单域名、证书与兼容性5.1 合法域名与HTTPS开发者工具能跑真机就白屏微信小程序的网络请求有硬性限制这个限制是很多源码跑完本地就卡住的元凶。小程序正式版和体验版都要求wx.request 的 url 必须使用 HTTPS并且域名必须已备案、已在小程序后台配置为 request 合法域名。开发者工具里勾选“不校验合法域名”能绕过检查但真机预览时这个选项不存在用户手机上打开就是一片白或者网络错误。这是上线前最常翻车的地方不是代码问题是配置问题。解决办法分三步走第一步为后端域名申请 SSL 证书并配置到 Nginx 或 IIS 上第二步在微信公众平台的小程序后台“开发管理-开发设置-服务器域名”里把 request 合法域名加上第三步保证域名是备案过的否则即使证书有了也能配但打开就报“域名未备案”。C# 后端如果跑在 IIS 上记得在绑定里启用 HTTPS并强制 HTTP 自动跳转到 HTTPS否则用户从旧链接进来访问的还是明文协议。5.2 图片加载 403防盗链和图片域名没配商城商品图片加载不出来是最常见但最容易被误判为代码 bug 的问题。现象是小程序里商品有名字有价格但图片位置全空或者头像裂开。原因通常是两类一类是商品数据里的图片 URL 指向其他网站比如原来的数据是抓的淘宝图、京东图对方开了防盗链小程序请求图片时被对方服务器拒绝返回 403另一类是小程序端用的图片域名没有配置到 downloadFile 合法域名里微信限制了非白名单域名下的图片加载。解决思路很直接把图片统一迁移到自己的服务器或 OSS 上改成相对路径存储然后在小程序后台的 downloadFile 合法域名里加上你的图片域名。压缩包自带的初始数据往往会混入一些外部占位图链接导完数据库脚本后先执行一条 SQL 查一下 image 字段看到明显以 http 开头的第三方图床地址就替换掉。C# 后端可以做一个简单的图片上传接口用 MultipartFormData 接收文件然后存到 wwwroot 目录但要注意对上传文件做扩展名和大小校验否则会被塞进来一堆服务器木马。5.3 登录态为何总是失效session_key 与 openid 混用的后果很多源码在登录逻辑里把 session_key 直接当成自己签发 token 的内容这种做法在“小程序-后端-C# API”的全链路下必出怪问题。现象是前端登录成功后隔几分钟再调接口就报登录过期。原因是微信的 session_key 有自己的有效期同时也可能因为用户在其他设备重新登录而失效你把 session_key 存进本地当登录凭证等于你的登录态生命周期被微信牵着走完全不受你控制。正确做法是后端拿到微信 session_key 之后用它换取你自有系统签发的 JWT TokenToken 的有效期由你定义跟微信 session_key 无关一个过期一个不过期互不牵连。这个坑在你用这套源码做演示时并不明显因为演示用户少等真正上线有几十个人用登录失效的频率就会让人崩溃。5.4 支付回调地址必须是公网可达域名不能用IP地址如果你把后端部署在本地或内网服务器微信支付回调就是必炸的环节。现象是订单已支付但商城订单状态不变查后端看回调日志发现微信从来没有请求到你的回调接口。原因是回调地址必须能被微信服务器从公网访问到内网 IP 地址哪怕在同一个局域网也收不到回调。注意微信支付回调地址也不能直接用 IP 加端口必须要一个公网域名。这个限制和上面 5.1 是同一套逻辑都是微信平台为了安全强制要求的。本地开发阶段想测支付怎么办常见做法是用内网穿透工具把本地端口映射成一个公网 HTTPS 地址再把这个地址配到微信商户平台的支付回调 URL 里调试。但上线后一定换回正式域名内网穿透工具只适合联调别长期用。5.5 真机与开发者工具表现不一致的玄学问题开发者工具里一切正常真机上页面加载不出来、接口报错、样式错位这类“玄学”问题的定位思路要按下面三步走。第一控制台里看有没有“url not in domain list”有就是合法域名没配好第二看接口请求有没有发出真机上 wx.request 如果没发出检查基础库版本官方新版基础库对 TLS 版本有最低要求服务器上的 SSL 证书如果用的是老版本 TLS 1.0真机会直接拒绝连接第三样式问题检查手机型号和微信版本别急着改代码先用调试工具的机型模拟确认一遍。这类问题的高发期集中在项目刚上线那一周建议你在测试机上完整走一遍“注册-逛商品-加入购物车-下单-支付-查看订单”全流程再发布。6. 把源码改造成自己的项目两个最小改动与一套验证方法拿到这套 C# 微信小程序商城源码后真正决定它值不值得投入的一定是改造成本。改造有个原则先改配置后改代码。第一处必改是数据库连接串上一章已经说过第二处必改是微信配置项包括小程序 AppId、AppSecret、商户号、API 密钥。这四处配置全部集中在 appsettings.json 里你可以建一个 appsettings.Production.json 按环境覆盖避免误改生产配置。改完这两处整套商城基本就是“你的”了。接下来是数据层面的改造。商品表里通常有 CategoryId、IsHot、IsNew 之类的字段你可以按自己的品类调整。改数据库字段之前先检查 C# 后端的商品实体类和数据库表是否一致EF Core 模式下实体类和表字段是一一对应的漏掉一个字段查询就会报错。建议在项目里先给商品加一个测试标记字段走通 C# 后端到小程序的完整链路再决定哪些字段值得保留哪些直接删掉。最后说一套上线前值得做的低成本验证方法。用 Postman 或直接写一段小程序端测试页按顺序请求这些接口登录接口返回 token、商品列表能拿到数据、商品详情有库存、创建订单返回 OrderNo、支付参数生成无报错、回调成功更新状态。这些接口按主流程串起来跑通一遍比什么都靠谱。我自己的习惯是把这套顺序写成一份 Markdown 验证清单每次改完代码走一遍支付回调的问题十有八九能在这一环节被提前抓住而不是等用户付款后才发现订单不更新。希望这份笔记能帮你把整套源码跑起来少踩几个我当年踩过的坑。本文还有配套的精品资源点击获取