简介一份面向计算机相关专业毕业设计的微信小程序在线购物商城完整源码。项目前端采用微信小程序原生框架后端基于C#与ASP.NET实现演示了商品浏览、购物车、订单支付及后台管理流程适合学习C#服务端开发和小程序联调的开发者参考。压缩包共1930个文件、约26.9MB主要包含480个.cs后端逻辑文件、125个.aspx页面文件、140个.js脚本、23个.wxml与24个.wxss小程序结构样式文件并带有.sql及.mdf/.ldf数据库文件、.config配置文件和.pfx/.pem证书文件目录结构覆盖页面、业务逻辑、数据访问与部署配置等层次。已有592人学习下载。整体代码量较大典型页面、接口和表结构齐全可据此对照分析前后端数据通信、数据库脚本及发布配置方法作为毕业设计或电商项目起步模板能明显缩短搭建时间。1. 这个C#微信小程序商城源码.zip到底值不值得花时间拆开看“基于C#的微信小程序在线购物商城源码.zip”在资源站里经常出现在“微信小程序项目实例”“PHP源码”旁边下载页写着“含完整前后端数据库”。实际拿到手里面的东西一般就是三块小程序前端目录、C#后端工程、数据库脚本。对正在做毕业设计、课程设计或者公司急着要一套可演示的商城Demo的人来说这个包确实能省不少事——你不需要从零搭登录、商品列表、购物车和订单流程。但我要先泼一盆冷水这份源码不会自动变成能上线的商业产品它的价值在“看得懂、跑得起来、能改造”而不是解压即用。我拆过好几份这类资源结论一致真正让你翻车的不是C#代码本身而是数据库连接、支付回调验签、域名白名单这些细节。这套架构的本质也很简单微信小程序做界面和交互C#常见是ASP.NET Core Web API做后端服务中间用HTTPS JSON通信。全文的实战思路就是围绕这条链路怎么落地说开。2. 拆解源码前先搞懂这套架构C#后端 微信小程序前端的协作方式2.1 为什么购物商城选 C# Web API 而不是 Node/PHP技术选型理由我见过不少同学问“商城这种项目后端用Node不是更轻吗PHP不是更快吗”这些说法都有道理但当你手里只有这份C#源码时选型理由其实已经替你定好了。更重要的原因是从工程角度C# Web API 做商城后端有它的硬优点。一是强类型。商品名称、价格、库存这些字段在C#里定义成字符串、decimal、int编译期就能发现类型写错而不是等到小程序端拿到NaN才去排查。二是数据库访问层成熟。源码里多用EF Core或SqlSugar商城最常见的CRUD、分页、事务都能用很短的代码写清楚而且有迁移机制改完实体直接生成数据库脚本。三是微信支付官方文档和社区示例里C#版的贡献度一直很高。我遇到支付回调、退款、账单对账这类偏门接口搜出来的可用代码段一大半是C#写的。对着源码里的支付模块改比用其它语言重新翻译一遍要省力得多。当然C# Web API也有烦的地方Windows部署、IIS或系统d守护进程、开发机要装Visual Studio或.NET SDK。如果你最后要部署到便宜的Linux云主机就得接受ASP.NET Core的跨平台发布方式——先dotnet publish生成独立文件再用Nginx反向代理这一套在第6章我会给出做法。但就商城这种“登录-下单-支付-查订单”的常规形态C#的稳定性和可维护性绝对够撑起你的第一个正式项目。2.2 源码包里的三类核心文件小程序端、C#后端、数据库脚本解压之后别急着双击 .sln先看目录结构。我带人看过的商城源码包基本都有一个固定套路一个文件夹放小程序前端一个文件夹放C#后端外加一个 .sql 文件或数据库脚本目录。下面这张清单适合你对照自己手里的包做分类分类常见目录/文件作用小程序前端miniprogram/、app.js、app.json、pages/页面、路由、全局配置、用户登录态小程序工具层utils/request.js、utils/util.js封装wx.request、日期格式化C#后端工程Server/、Api/、WebApi/整个解决方案所在目录C#核心代码Controllers/、Models/、Services/接口入口、实体类、业务逻辑配置appsettings.json、launchSettings.json数据库连接、支付参数、端口数据库脚本db.sql、database.sql、Scripts/建库、建表、初始化菜单和数据找不到.sln也不用慌。很多资源只放了Api工程目录没有解决方案文件到时候用Visual Studio打开文件夹或者用dotnet命令直接指向.csproj文件运行就行。我一般拿到包之后第一件事不是读代码而是先战术后撤一步把里面所有.csproj文件找出来。商城项目常见两层或三层结构二层的Controllers直接写业务三层的分离了Services和Repositories。你打开Visual Studio的解决方案资源管理器按“Web”和“Application”两个关键词过滤基本就能定位到启动入口。2.3 小程序与C#后端的通信链路HTTPS调用、JSON序列化、鉴权Header小程序端不能直接连数据库这是常识。它只能通过 wx.request 发HTTP请求到C#端的接口。而C#端作为Web API接收请求后从数据库取数把结果序列化成JSON通过MessagePack或System.Text.Json返回。整个过程最容易被新手忽略的就是所有数据都要走公共网络所以必须用HTTPS并且微信小程序在正式环境会强制校验请求域名。先看小程序端最常见的请求封装通常放在 utils/request.js 里我见过无数个版本核心思想都差不多// 小程序端 utils/request.js const BASE_URL https://yourdomain.com/api; function request(path, data {}, method GET) { return new Promise((resolve, reject) { wx.request({ url: BASE_URL path, method, data, header: { Content-Type: application/json, Authorization: wx.getStorageSync(token) ? Bearer wx.getStorageSync(token) : }, success: (res) { if (res.statusCode 200 res.statusCode 300) { resolve(res.data); } else { reject(res); } }, fail: reject }); }); } module.exports { request };这段代码的逻辑不复杂BASE_URL 是整个后端接口的公共前缀所有请求共用header 里的 Authorization 带上登录后缓存的token这是商城接口鉴权最通用的做法。参数 path、data、method 分别对应接口路径、请求体和HTTP方法。注意在 success 回调里不能直接把 res 返回要判断 statusCode因为微信小程序的 wx.request 在HTTP 404、500等情况下也会走进 success而不是 fail。C#后端接收请求的入口就是一个个 Controller。比如商品列表接口常见写法长得像下面这样// C# 后端 Controllers/ProductController.cs [ApiController] [Route(api/[controller])] public class ProductController : ControllerBase { private readonly IProductService _productService; public ProductController(IProductService productService) { _productService productService; } [HttpGet] public async TaskIActionResult GetList([FromQuery] int page 1, [FromQuery] int pageSize 10) { var result await _productService.GetPageAsync(page, pageSize); return Ok(new { code 0, data result }); } }这里值得说的细节是 [FromQuery] 和 [FromBody] 的区别。小程序端如果通过 GET 把查询参数拼在URL上C#就用 [FromQuery] 接如果 POST 用JSON体C#默认会自动反序列化到模型一般不用显式声明 [FromBody]。老源码里容易混用我看到的一个高频报错就是“参数绑定失败”表象是小程序端拿到的返回是400日志提示找不到page参数十有八九是请求方式和小程序端对不上。3. 把源码在本地跑起来从部署C#后端到微信开发者工具加载小程序的完整命令3.1 环境准备清单Visual Studio / .NET SDK / 微信开发者工具版本匹配动手之前先核对环境。这套源码如果目标是“本地跑通”你最少需要装三样东西Visual Studio 2022 或 .NET SDK前者适合打开工程直接按F5后者适合命令行操作。老源码可能是.NET Framework的那就得用Visual Studio 2019并勾选“.NET桌面开发”工作负载。微信开发者工具官网下载稳定版即可用于导入小程序目录、预览页面。数据库多数商城包用的是SQL Server也有用MySQL的。你看到 appsettings.json 里有“Server.;DatabaseShopDb;...”就是SQL Server看到“MySqlConnection”或“ProviderMySql”就是MySQL。版本匹配这里我吃过亏。有一份包是.NET Core 3.1写的我直接用.NET 8的SDK去跑 dotnet restore提示“架构不兼容”或“包版本不受支持”。原因是EF Core和运行库的版本对不上而NuGet还原时不会自动帮你降级。更稳妥的做法是先看 .csproj 文件里的 TargetFramework 和目标框架再决定装哪个SDK。如果是 netcoreapp3.1就装.NET Core 3.1运行时如果是 net6.0装.NET 6。别为了追新拿.NET 8硬跑老项目不然会被NuGet依赖折磨到怀疑人生。3.2 还原NuGet包并启动C# Web APIdotnet restore 与 launchSettings 修改环境确认后用命令行启动后端是最可靠的方式。先把当前目录切到 .csproj 所在路径然后执行cd C:\shop-code\Server dotnet restore dotnet rundotnet restore 的作用是根据 .csproj 里声明的 PackageReference 把NuGet包拉下来。这一步如果报错先看网络是否能访问 nuget.org内网环境就需要给NuGet换镜像源常见的做法是修改 NuGet.Config 里的 repository。dotnet run 之后控制台会打印监听地址一般默认是 http://localhost:5000 或 https://localhost:5001。这些值来自 Properties/launchSettings.json我建议你先打开这个文件看一眼{ profiles: { ShopApi: { commandName: Project, launchBrowser: true, applicationUrl: http://localhost:5000;https://localhost:5001, environmentVariables: { ASPNETCORE_ENVIRONMENT: Development } } } }这里最关键的是 applicationUrl。本地联调时我们只要HTTP端口就够了不用浪费时间去签HTTPS证书所以我会把 https://localhost:5001 直接删掉只留下 http://localhost:5000。但注意真机测试微信小程序时你没法用localhost访问你的电脑必须让手机和电脑处在同一网段并监听局域网IP。这个坑在第5章避坑里我会专门讲。3.3 配置微信小程序appid、合法域名和request基地址三步联调后端服务起来了现在处理小程序端。打开微信开发者工具选择“导入项目”选中源码包里的小程序目录一般里面有 app.js 的那个文件夹就是。导入时要注意你的登录身份是否有该小程序的管理权限。如果没有正式appid就选“测试号”。测试号允许你在本地请求任意HTTP或HTTPS域名但真机预览会受限。接着打开小程序端 app.js 或 config.js 文件找到类似于 globalData 或 constant 里的 baseUrl 配置。我见过很多写法但统一做法是把后端地址抽出来// 小程序端 app.js App({ globalData: { baseUrl: http://localhost:5000 } })注意这里填的地址必须和C#后端的监听地址一致。如果开发者工具是在同一台电脑上localhost 可以通如果是真机预览这里要改成你电脑在局域网里的IP比如 http://192.168.1.108:5000。最后微信开发者工具右上角的“详情—本地设置”把“不校验合法域名、web-view业务域名、TLS版本以及HTTPS证书”打上勾。这是开发阶段的后悔药帮你绕过正式域名校验。不要把这个勾选当作生产环境的配置等真机上线微信团队会强制要求HTTPS。3.4 用浏览器和Postman验证后端接口Swagger与最小测试用例后端和前端都准备好先别急着点小程序页面。我们先用浏览器直接访问几个核心接口验证后端逻辑是否正常。如果源码里有Swagger启动后访问 http://localhost:5000/swagger/index.html你会看到一个带UI的接口列表。这是最快确认Controller是否注册成功的方式。没有Swagger也没关系手动在浏览器地址栏敲一个接口试试。商城Demo里最常用的验证接口是商品列表和登录接口。比如curl http://localhost:5000/api/Product?page1pageSize10如果返回一段JSON里面包含 code 和 data 字段说明C#后端到数据库这条链路是通的。如果浏览器报500优先去控制台看最后几行日志最常见的错误是数据库连接字符串写错。看到“Cannot open database”就是SQL Server连不上看到“Access denied for user”就是MySQL账号权限不对看到“table doesnt exist”则是数据库脚本没导入或者表名大小写映射出问题。用Postman测的时候注意一个小细节商城接口把鉴权放在了Header里测试登录接口后会把返回里的token复制到Postman的Authorization头。如果直接调用下单接口不带token返回401或403是正常的别慌。4. 购物车、订单与支付回调解密核心业务模块的源码走读与改造点4.1 商品列表接口的读取逻辑从数据库到JSON返回的分页写法商城页面打开第一个请求必然是商品列表。我们读源码时优先看这个接口的实现。一个质量合格的商城后端商品列表不会是“一次性查出所有记录”而是分页返回。常规实现如下// Services/ProductService.cs public async TaskPageResultProductDto GetPageAsync(int page, int pageSize) { var query _db.Products.Where(p p.Status 1); var total await query.CountAsync(); var items await query .OrderByDescending(p p.Id) .Skip((page - 1) * pageSize) .Take(pageSize) .Select(p new ProductDto { Id p.Id, Name p.Name, Price p.Price, CoverImage p.CoverImage }) .ToListAsync(); return new PageResultProductDto { Total total, Items items }; }这段代码的核心逻辑是先用 CountAsync 拿到符合条件Status1的记录总数再用 OrderByDescending 排序最后用 Skip 和 Take 截取某一页。这里隐藏着一个应届生容易翻车的点如果先Skip再OrderBy有些数据库会报错或者得到无序数据。务必保证顺序是“Where - OrderBy - Skip - Take”。我在代码审查里见过有人把 OrderBy 写在 Skip 后面然后首页数据每次都不一样排查了半天竟是这一行顺序问题。另外ProductDto 是专门给前端返回的模型不要直接把数据库实体 Product 暴露给小程序。我看到过把内部字段 UserId、CreatedAt 全都返回给前端的写法这不安全。改造点很简单建一个 DTO 类只放前端要的字段再用 Select 做映射。源码里如果没有 ProductDto建议你加上后面加字段会省心很多。4.2 购物车数据是存本地Storage还是C#服务端两种方案的取舍购物车是商城项目的分水岭。很多Demo为了省事把购物车数据存在小程序端的 Storage 里说“反正用户没登录也能加购物车”。这个方案在真实商城项目里根本撑不住用户换手机、清缓存、小程序崩溃重装后购物车全没了而且用户在一台手机上加入购物车想在另一台设备上继续购物做不到。成熟的源码工程设计是把购物车放服务端。后端用一张 CartItem 表至少包含 Id、UserId、ProductId、Quantity、Selected 这几个字段。用户每次加购小程序调用接口// Controllers/CartController.cs [HttpPost] public async TaskIActionResult Add([FromBody] CartAddDto dto) { if (dto.Quantity 0) return BadRequest(new { code 1, msg 数量不合法 }); var userId GetUserIdFromToken(); // 从JWT中解析 var cartItem await _db.CartItems .FirstOrDefaultAsync(c c.UserId userId c.ProductId dto.ProductId); if (cartItem null) { cartItem new CartItem { UserId userId, ProductId dto.ProductId, Quantity dto.Quantity, Selected true }; _db.CartItems.Add(cartItem); } else { cartItem.Quantity dto.Quantity; } await _db.SaveChangesAsync(); return Ok(new { code 0, msg 已加入购物车 }); }这里值得关注的是 GetUserIdFromToken() 这个方法。很多商城源码会有重复代码——在每个Controller里手写解析token一长串逻辑。正确做法是定义公共方法或过滤器。你在改造时如果发现每个接口都重复贴了一段“payload.Substring(…)”建议把它抽到公共类这是高内聚的一个很实在的改进。另外加入购物车要确认用户选项是否选中的状态有些源码做成加完就把整个购物车覆盖返回这会丢失用户对某个商品勾选的记忆。本地Storage不是完全不能用它适合存那些服务端不需要持久化的临时状态比如购物车界面的勾选动画状态、结算单里的备注草稿。核心购物车数据一定要走后端。4.3 微信支付统一下单与回调验签源码里最值得复用的部分支付是整个商城源码里最值钱的部分。小程序端调不起支付接口这只是第一步真正硬核的是后端跟微信支付的对接。标准流程是小程序把订单信息发给C#后端C#后端调用微信支付的“统一下单API”拿到 prepay_id再生成商户签名返回给小程序的 wx.requestPayment用户确认支付后微信服务器把支付结果回调到我们的后端指定接口。这中间验签最容易被抄错。很多源码里验签是这么写的// Services/PayService.cs —— 回调验签核心逻辑 var sign reqData[sign]; var sortedParams reqData .Where(k k.Key ! sign) .OrderBy(k k.Key) .Select(k ${k.Key}{k.Value}) .ToList(); var stringA string.Join(, sortedParams); var stringSignTemp stringA key payOptions.ApiKey; var calcSign Md5(stringSignTemp).ToUpper(); if (calcSign sign) { // 验签通过更新订单状态 }这里有三处坑改造的时候要看着。一是排序规则。微信支付官方要求参数按 ASCII 码升序排列很多源码用 OrderBy(k k.Key)默认语义就是按枚举器对 string 做字典序排序这点没问题但如果你为了好看改成“按出现顺序”就废了。二是空值处理。官方文档明确说参数为空的不要参与签名源码里如果没有过滤空串要补上Where(k !string.IsNullOrEmpty(k.Value))。三是MD5大小写。微信支付要求签名结果转大写但如果源码里先转小写再比较回调永远通不过。我建议你改动后先打印两边签名再比较别盲改密钥。支付回调地址是在小程序端调用 wx.requestPayment 时通过统一下单传入的 notify_url 参数指定的。很多源码包用的地址是 http://localhost:5000这显然收不到微信服务器的回调。本地调试时可以用内网穿透工具暴露一个公网HTTPS地址但正式配置一定要改成你的线上域名且必须是用ICP备案过的。支付回调里还要做幂等如果同一笔订单被回调两次第二次不能把订单状态从“已支付”改回“待支付”要在校验订单状态处加个判断。5. 避坑这5个问题让新手部署时最容易翻车附排查与修复方法5.1 现象小程序端 request 报 “url not in domain list” 或 “TLS版本过低”这是我被问到最多的问题。开发环境一切正常真机预览或体验版时所有请求全部失败控制台提示 “url not in domain list”或者 “安信TLS版本过低”。原因很简单微信小程序的正式环境绑定了 request 合法域名且要求该域名已备案、必须HTTPS、TLS版本不能低于1.2。解决登录微信公众平台在小程序管理后台的“开发管理—开发设置—服务器域名”里把后端接口的HTTPS域名加进 request 合法域名。域名不能带 http:// 前缀也不能是IP或localhost。如果提示TLS版本过低检查服务器上的SSL证书配置Nginx里把 ssl_protocols 设置成 TLSv1.2 TLSv1.3并重启Nginx。本地开发用测试号可以暂时忽略域名校验但看不到线上真实表现。我的习惯是尽量早配一个正式的HTTPS域名越晚配越被动。5.2 现象C#后端启动后接口500查看日志发现是数据库连接字符串问题现象是浏览器访问接口返回500而不是404或JSON。控制台日志往往写着 “Cannot open database” 或者 “Login failed for user sa”。原因是源码包里自带的连接字符串是针对作者本机数据库写的你本地如果没有同名数据库和账号自然连不上。解决打开 appsettings.json找到 ConnectionStrings 节点改成你自己的数据库。比如原来是Server.;DatabaseShopDb;Usersa;Password123456如果用的是Windows认证就改成Server.;DatabaseShopDb;Trusted_ConnectionTrue;。如果SQL Server服务叫SQLEXPRESS需要写成Server.\\SQLEXPRESS;...。改完重启 dotnet run。这里我有一个习惯先把数据库脚本导入成功再用 SQL Server Management Studio 的连接字符串填到配置里尽量从 Studio 的“连接属性”复制完整连接串避免少写一个分号或选项。5.3 现象局域网真机预览时连不上后端开发者工具却正常开发者工具在小程序端模拟器里请求本机后端没问题但用手机扫码真机预览后所有请求都失败。原因有两个一是手机和电脑不在同一个局域网二是电脑防火墙拦了5000端口。解决用命令ipconfig找出你电脑的IPv4地址比如192.168.1.108把小程序里 baseUrl 改成http://192.168.1.108:5000。然后在Windows防火墙的“高级设置—入站规则”中放行5000端口或者干脆在启动时用dotnet run --urls http://0.0.0.0:5000强制监听所有网卡。很多源码默认只监听 localhost所以即使你改对了IP也白搭。注意真实项目里微信的登录要在微信公众平台配置业务域名或下载校验文件测试环境用 IP 访问很容易踩这个雷建议早点上正式域名。5.4 现象Newtonsoft.Json 与 System.Text.Json 混用导致字段大小写对不上源码里有些接口返回字段是驼峰如 productName有些返回的是帕斯卡如 ProductName小程序端拿到的数据总有几个字段是 undefined。原因是老版本用 Newtonsoft.Json默认把它序列化成与属性名一致新版本用 System.Text.Json默认序列化会把C#的帕斯卡名字转换成小写开头。如果两种情况混用前后端对不上就是必然。解决统一JSON序列化配置。在 Program.cs 或 Startup.cs 里加上下面的代码builder.Services.AddControllers() .AddJsonOptions(options { options.JsonSerializerOptions.PropertyNamingPolicy null; options.JsonSerializerOptions.PropertyNameCaseInsensitive true; });这里把 PropertyNamingPolicy 设为 null表示保持C#属性的原始大小写不变PropertyNameCaseInsensitive 设为 true表示反序列化时忽略大小写小程序端用大写或小写都能绑上。如果源码里还在用 Newtonsoft那你就在 AddNewtonsoftJson() 里把 ContractResolver 设成 CamelCasePropertyNamesContractResolver两边选择一个统一策略。我最烦这个坑因为报错不是500而是静默地返回undefined排查时间很长。5.5 现象IIS发布后上传图片404虚拟目录配置错位本地开发时图片上传读取一切正常发布到Windows服务器的IIS后商品图片全部404提示找不到文件。原因通常是源码里图片的物理路径写死了相对路径比如wwwroot\uploads而 IIS 的工作目录并非项目发布目录或者发布时未包含 uploads 文件夹。解决先把发布目录里有没有 uploads 文件夹确认一遍没有就手动建一个并给 IIS 站点的应用程序池用户设置写入权限。然后检查源码中图片保存路径的写法。推荐改成基于 IWebHostEnvironment 的路径var uploadsDir Path.Combine(_env.WebRootPath, uploads); if (!Directory.Exists(uploadsDir)) Directory.CreateDirectory(uploadsDir);不要在代码里写死C:\inetpub\...。另外小程序访问图片的URL要直接映射到https://你的域名/uploads/xxx.jpg不要走代理还把虚拟目录路径漏掉。我见过最离谱的错误是IIS里添加的虚拟目录叫 files代码里却写/upload名字不对应图片自然就404了。建议在浏览器里打开图片地址看具体报错是404还是403逐层排查。6. 让商城源码变成能上线的产品从Demo到生产的三步加固与一个关键技巧6.1 先删掉源码里的默认账号和弱口令这类源码包为了演示方便通常会在数据库初始化脚本里塞进一个 admin / 123456 的管理员账号甚至有的在 C# 代码里硬编码了一个万能token。上线前你必须删掉这些并在用户表里确认没有“上帝账号”。我的做法是直接重跑数据库脚本把 Seed 部分的管理员密码字段改成随机字符串或者换成自己通过 BCrypt 生成的新密码。同时检查 Controllers/ManagerController 之类的后台接口有没有缺少鉴权。Demo源码里后台接口裸奔的情况非常常见不补就上线等于裸奔。6.2 用 dotnet publish 发布并配合 Nginx 反向代理生产环境我推荐先dotnet publish -c Release -o ./publish再把 publish 目录整体拷贝到服务器。如果服务器是 Linux用 Nginx 做反向代理监听443端口并转发到本地的5000端口如果是 Windows用 IIS 建站点应用程序池选“无托管代码”。发布完成后一定要把 appsettings.json 里 ConnectionStrings 和 Pay 相关密钥换成正式环境的值并确保服务器的时间是网络同步的微信支付回调对时间偏移很敏感。6.3 关键技巧给后端接口加一个请求日志中间件开发时我们可以依赖控制台日志但上了生产接口出错经常是“黑匣子”我们既不知道请求参数也不知道返回内容。所以我每次接手商城源码第一件事就是加一个最简请求日志中间件把路径、耗时、状态码和关键入参记录下来public class RequestLogMiddleware { private readonly RequestDelegate _next; private readonly ILoggerRequestLogMiddleware _logger; public RequestLogMiddleware(RequestDelegate next, ILoggerRequestLogMiddleware logger) { _next next; _logger logger; } public async Task InvokeAsync(HttpContext context) { var stopwatch Stopwatch.StartNew(); await _next(context); stopwatch.Stop(); _logger.LogInformation( {Method} {Path} - {StatusCode} in {Elapsed:F2}ms, context.Request.Method, context.Request.Path.Value, context.Response.StatusCode, stopwatch.Elapsed.TotalMilliseconds); } }这个中间件不复杂但它能帮你快速区分一件事报错到底发生在前端还是后端。我经历过一次线上特价商品超卖页面提示“请求失败”但看日志发现接口全部200说明是前端数据渲染逻辑出错后来又在另一单查不到订单时发现日志显示401才知道是登录态过期没做自动刷新。日志不会说话但它能告诉你往哪个方向查。把这个中间件加在 Program.cs 里用app.UseMiddlewareRequestLogMiddleware();注册即可。这些加固做完你的商城就比原始的Demo包往前迈了一大步。我拆过很多源码包最后能真正上线的人往往不是技术最炫的而是那些愿意把默认密码删掉、把日志加上、把数据库连接串搞清楚的人。这套组合拳打下来至少能避免上线后第一个晚上就被用户碰到404、500和支付掉单。希望帮到你。本文还有配套的精品资源点击获取
