簡(jiǎn)介一份面向計(jì)算機(jī)相關(guān)專業(yè)畢業(yè)設(shè)計(jì)的微信小程序在線購物商城完整源碼。項(xiàng)目前端采用微信小程序原生框架后端基于C#與ASP.NET實(shí)現(xiàn)演示了商品瀏覽、購物車、訂單支付及后臺(tái)管理流程適合學(xué)習(xí)C#服務(wù)端開發(fā)和小程序聯(lián)調(diào)的開發(fā)者參考。壓縮包共1930個(gè)文件、約26.9MB主要包含480個(gè).cs后端邏輯文件、125個(gè).aspx頁面文件、140個(gè).js腳本、23個(gè).wxml與24個(gè).wxss小程序結(jié)構(gòu)樣式文件并帶有.sql及.mdf/.ldf數(shù)據(jù)庫文件、.config配置文件和.pfx/.pem證書文件目錄結(jié)構(gòu)覆蓋頁面、業(yè)務(wù)邏輯、數(shù)據(jù)訪問與部署配置等層次。已有592人學(xué)習(xí)下載。整體代碼量較大典型頁面、接口和表結(jié)構(gòu)齊全可據(jù)此對(duì)照分析前后端數(shù)據(jù)通信、數(shù)據(jù)庫腳本及發(fā)布配置方法作為畢業(yè)設(shè)計(jì)或電商項(xiàng)目起步模板能明顯縮短搭建時(shí)間。1. 這個(gè)C#微信小程序商城源碼.zip到底值不值得花時(shí)間拆開看“基于C#的微信小程序在線購物商城源碼.zip”在資源站里經(jīng)常出現(xiàn)在“微信小程序項(xiàng)目實(shí)例”“PHP源碼”旁邊下載頁寫著“含完整前后端數(shù)據(jù)庫”。實(shí)際拿到手里面的東西一般就是三塊小程序前端目錄、C#后端工程、數(shù)據(jù)庫腳本。對(duì)正在做畢業(yè)設(shè)計(jì)、課程設(shè)計(jì)或者公司急著要一套可演示的商城Demo的人來說這個(gè)包確實(shí)能省不少事——你不需要從零搭登錄、商品列表、購物車和訂單流程。但我要先潑一盆冷水這份源碼不會(huì)自動(dòng)變成能上線的商業(yè)產(chǎn)品它的價(jià)值在“看得懂、跑得起來、能改造”而不是解壓即用。我拆過好幾份這類資源結(jié)論一致真正讓你翻車的不是C#代碼本身而是數(shù)據(jù)庫連接、支付回調(diào)驗(yàn)簽、域名白名單這些細(xì)節(jié)。這套架構(gòu)的本質(zhì)也很簡(jiǎn)單微信小程序做界面和交互C#常見是ASP.NET Core Web API做后端服務(wù)中間用HTTPS JSON通信。全文的實(shí)戰(zhàn)思路就是圍繞這條鏈路怎么落地說開。2. 拆解源碼前先搞懂這套架構(gòu)C#后端 微信小程序前端的協(xié)作方式2.1 為什么購物商城選 C# Web API 而不是 Node/PHP技術(shù)選型理由我見過不少同學(xué)問“商城這種項(xiàng)目后端用Node不是更輕嗎PHP不是更快嗎”這些說法都有道理但當(dāng)你手里只有這份C#源碼時(shí)選型理由其實(shí)已經(jīng)替你定好了。更重要的原因是從工程角度C# Web API 做商城后端有它的硬優(yōu)點(diǎn)。一是強(qiáng)類型。商品名稱、價(jià)格、庫存這些字段在C#里定義成字符串、decimal、int編譯期就能發(fā)現(xiàn)類型寫錯(cuò)而不是等到小程序端拿到NaN才去排查。二是數(shù)據(jù)庫訪問層成熟。源碼里多用EF Core或SqlSugar商城最常見的CRUD、分頁、事務(wù)都能用很短的代碼寫清楚而且有遷移機(jī)制改完實(shí)體直接生成數(shù)據(jù)庫腳本。三是微信支付官方文檔和社區(qū)示例里C#版的貢獻(xiàn)度一直很高。我遇到支付回調(diào)、退款、賬單對(duì)賬這類偏門接口搜出來的可用代碼段一大半是C#寫的。對(duì)著源碼里的支付模塊改比用其它語言重新翻譯一遍要省力得多。當(dāng)然C# Web API也有煩的地方Windows部署、IIS或系統(tǒng)d守護(hù)進(jìn)程、開發(fā)機(jī)要裝Visual Studio或.NET SDK。如果你最后要部署到便宜的Linux云主機(jī)就得接受ASP.NET Core的跨平臺(tái)發(fā)布方式——先dotnet publish生成獨(dú)立文件再用Nginx反向代理這一套在第6章我會(huì)給出做法。但就商城這種“登錄-下單-支付-查訂單”的常規(guī)形態(tài)C#的穩(wěn)定性和可維護(hù)性絕對(duì)夠撐起你的第一個(gè)正式項(xiàng)目。2.2 源碼包里的三類核心文件小程序端、C#后端、數(shù)據(jù)庫腳本解壓之后別急著雙擊 .sln先看目錄結(jié)構(gòu)。我?guī)丝催^的商城源碼包基本都有一個(gè)固定套路一個(gè)文件夾放小程序前端一個(gè)文件夾放C#后端外加一個(gè) .sql 文件或數(shù)據(jù)庫腳本目錄。下面這張清單適合你對(duì)照自己手里的包做分類分類常見目錄/文件作用小程序前端miniprogram/、app.js、app.json、pages/頁面、路由、全局配置、用戶登錄態(tài)小程序工具層utils/request.js、utils/util.js封裝wx.request、日期格式化C#后端工程Server/、Api/、WebApi/整個(gè)解決方案所在目錄C#核心代碼Controllers/、Models/、Services/接口入口、實(shí)體類、業(yè)務(wù)邏輯配置appsettings.json、launchSettings.json數(shù)據(jù)庫連接、支付參數(shù)、端口數(shù)據(jù)庫腳本db.sql、database.sql、Scripts/建庫、建表、初始化菜單和數(shù)據(jù)找不到.sln也不用慌。很多資源只放了Api工程目錄沒有解決方案文件到時(shí)候用Visual Studio打開文件夾或者用dotnet命令直接指向.csproj文件運(yùn)行就行。我一般拿到包之后第一件事不是讀代碼而是先戰(zhàn)術(shù)后撤一步把里面所有.csproj文件找出來。商城項(xiàng)目常見兩層或三層結(jié)構(gòu)二層的Controllers直接寫業(yè)務(wù)三層的分離了Services和Repositories。你打開Visual Studio的解決方案資源管理器按“Web”和“Application”兩個(gè)關(guān)鍵詞過濾基本就能定位到啟動(dòng)入口。2.3 小程序與C#后端的通信鏈路HTTPS調(diào)用、JSON序列化、鑒權(quán)Header小程序端不能直接連數(shù)據(jù)庫這是常識(shí)。它只能通過 wx.request 發(fā)HTTP請(qǐng)求到C#端的接口。而C#端作為Web API接收請(qǐng)求后從數(shù)據(jù)庫取數(shù)把結(jié)果序列化成JSON通過MessagePack或System.Text.Json返回。整個(gè)過程最容易被新手忽略的就是所有數(shù)據(jù)都要走公共網(wǎng)絡(luò)所以必須用HTTPS并且微信小程序在正式環(huán)境會(huì)強(qiáng)制校驗(yàn)請(qǐng)求域名。先看小程序端最常見的請(qǐng)求封裝通常放在 utils/request.js 里我見過無數(shù)個(gè)版本核心思想都差不多// 小程序端 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 };這段代碼的邏輯不復(fù)雜BASE_URL 是整個(gè)后端接口的公共前綴所有請(qǐng)求共用header 里的 Authorization 帶上登錄后緩存的token這是商城接口鑒權(quán)最通用的做法。參數(shù) path、data、method 分別對(duì)應(yīng)接口路徑、請(qǐng)求體和HTTP方法。注意在 success 回調(diào)里不能直接把 res 返回要判斷 statusCode因?yàn)槲⑿判〕绦虻?wx.request 在HTTP 404、500等情況下也會(huì)走進(jìn) success而不是 fail。C#后端接收請(qǐng)求的入口就是一個(gè)個(gè) Controller。比如商品列表接口常見寫法長(zhǎng)得像下面這樣// 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 }); } }這里值得說的細(xì)節(jié)是 [FromQuery] 和 [FromBody] 的區(qū)別。小程序端如果通過 GET 把查詢參數(shù)拼在URL上C#就用 [FromQuery] 接如果 POST 用JSON體C#默認(rèn)會(huì)自動(dòng)反序列化到模型一般不用顯式聲明 [FromBody]。老源碼里容易混用我看到的一個(gè)高頻報(bào)錯(cuò)就是“參數(shù)綁定失敗”表象是小程序端拿到的返回是400日志提示找不到page參數(shù)十有八九是請(qǐng)求方式和小程序端對(duì)不上。3. 把源碼在本地跑起來從部署C#后端到微信開發(fā)者工具加載小程序的完整命令3.1 環(huán)境準(zhǔn)備清單Visual Studio / .NET SDK / 微信開發(fā)者工具版本匹配動(dòng)手之前先核對(duì)環(huán)境。這套源碼如果目標(biāo)是“本地跑通”你最少需要裝三樣?xùn)|西Visual Studio 2022 或 .NET SDK前者適合打開工程直接按F5后者適合命令行操作。老源碼可能是.NET Framework的那就得用Visual Studio 2019并勾選“.NET桌面開發(fā)”工作負(fù)載。微信開發(fā)者工具官網(wǎng)下載穩(wěn)定版即可用于導(dǎo)入小程序目錄、預(yù)覽頁面。數(shù)據(jù)庫多數(shù)商城包用的是SQL Server也有用MySQL的。你看到 appsettings.json 里有“Server.;DatabaseShopDb;...”就是SQL Server看到“MySqlConnection”或“ProviderMySql”就是MySQL。版本匹配這里我吃過虧。有一份包是.NET Core 3.1寫的我直接用.NET 8的SDK去跑 dotnet restore提示“架構(gòu)不兼容”或“包版本不受支持”。原因是EF Core和運(yùn)行庫的版本對(duì)不上而NuGet還原時(shí)不會(huì)自動(dòng)幫你降級(jí)。更穩(wěn)妥的做法是先看 .csproj 文件里的 TargetFramework 和目標(biāo)框架再?zèng)Q定裝哪個(gè)SDK。如果是 netcoreapp3.1就裝.NET Core 3.1運(yùn)行時(shí)如果是 net6.0裝.NET 6。別為了追新拿.NET 8硬跑老項(xiàng)目不然會(huì)被NuGet依賴折磨到懷疑人生。3.2 還原NuGet包并啟動(dòng)C# Web APIdotnet restore 與 launchSettings 修改環(huán)境確認(rèn)后用命令行啟動(dòng)后端是最可靠的方式。先把當(dāng)前目錄切到 .csproj 所在路徑然后執(zhí)行cd C:\shop-code\Server dotnet restore dotnet rundotnet restore 的作用是根據(jù) .csproj 里聲明的 PackageReference 把NuGet包拉下來。這一步如果報(bào)錯(cuò)先看網(wǎng)絡(luò)是否能訪問 nuget.org內(nèi)網(wǎng)環(huán)境就需要給NuGet換鏡像源常見的做法是修改 NuGet.Config 里的 repository。dotnet run 之后控制臺(tái)會(huì)打印監(jiān)聽地址一般默認(rèn)是 http://localhost:5000 或 https://localhost:5001。這些值來自 Properties/launchSettings.json我建議你先打開這個(gè)文件看一眼{ profiles: { ShopApi: { commandName: Project, launchBrowser: true, applicationUrl: http://localhost:5000;https://localhost:5001, environmentVariables: { ASPNETCORE_ENVIRONMENT: Development } } } }這里最關(guān)鍵的是 applicationUrl。本地聯(lián)調(diào)時(shí)我們只要HTTP端口就夠了不用浪費(fèi)時(shí)間去簽HTTPS證書所以我會(huì)把 https://localhost:5001 直接刪掉只留下 http://localhost:5000。但注意真機(jī)測(cè)試微信小程序時(shí)你沒法用localhost訪問你的電腦必須讓手機(jī)和電腦處在同一網(wǎng)段并監(jiān)聽局域網(wǎng)IP。這個(gè)坑在第5章避坑里我會(huì)專門講。3.3 配置微信小程序appid、合法域名和request基地址三步聯(lián)調(diào)后端服務(wù)起來了現(xiàn)在處理小程序端。打開微信開發(fā)者工具選擇“導(dǎo)入項(xiàng)目”選中源碼包里的小程序目錄一般里面有 app.js 的那個(gè)文件夾就是。導(dǎo)入時(shí)要注意你的登錄身份是否有該小程序的管理權(quán)限。如果沒有正式appid就選“測(cè)試號(hào)”。測(cè)試號(hào)允許你在本地請(qǐng)求任意HTTP或HTTPS域名但真機(jī)預(yù)覽會(huì)受限。接著打開小程序端 app.js 或 config.js 文件找到類似于 globalData 或 constant 里的 baseUrl 配置。我見過很多寫法但統(tǒng)一做法是把后端地址抽出來// 小程序端 app.js App({ globalData: { baseUrl: http://localhost:5000 } })注意這里填的地址必須和C#后端的監(jiān)聽地址一致。如果開發(fā)者工具是在同一臺(tái)電腦上localhost 可以通如果是真機(jī)預(yù)覽這里要改成你電腦在局域網(wǎng)里的IP比如 http://192.168.1.108:5000。最后微信開發(fā)者工具右上角的“詳情—本地設(shè)置”把“不校驗(yàn)合法域名、web-view業(yè)務(wù)域名、TLS版本以及HTTPS證書”打上勾。這是開發(fā)階段的后悔藥幫你繞過正式域名校驗(yàn)。不要把這個(gè)勾選當(dāng)作生產(chǎn)環(huán)境的配置等真機(jī)上線微信團(tuán)隊(duì)會(huì)強(qiáng)制要求HTTPS。3.4 用瀏覽器和Postman驗(yàn)證后端接口Swagger與最小測(cè)試用例后端和前端都準(zhǔn)備好先別急著點(diǎn)小程序頁面。我們先用瀏覽器直接訪問幾個(gè)核心接口驗(yàn)證后端邏輯是否正常。如果源碼里有Swagger啟動(dòng)后訪問 http://localhost:5000/swagger/index.html你會(huì)看到一個(gè)帶UI的接口列表。這是最快確認(rèn)Controller是否注冊(cè)成功的方式。沒有Swagger也沒關(guān)系手動(dòng)在瀏覽器地址欄敲一個(gè)接口試試。商城Demo里最常用的驗(yàn)證接口是商品列表和登錄接口。比如curl http://localhost:5000/api/Product?page1pageSize10如果返回一段JSON里面包含 code 和 data 字段說明C#后端到數(shù)據(jù)庫這條鏈路是通的。如果瀏覽器報(bào)500優(yōu)先去控制臺(tái)看最后幾行日志最常見的錯(cuò)誤是數(shù)據(jù)庫連接字符串寫錯(cuò)。看到“Cannot open database”就是SQL Server連不上看到“Access denied for user”就是MySQL賬號(hào)權(quán)限不對(duì)看到“table doesnt exist”則是數(shù)據(jù)庫腳本沒導(dǎo)入或者表名大小寫映射出問題。用Postman測(cè)的時(shí)候注意一個(gè)小細(xì)節(jié)商城接口把鑒權(quán)放在了Header里測(cè)試登錄接口后會(huì)把返回里的token復(fù)制到Postman的Authorization頭。如果直接調(diào)用下單接口不帶token返回401或403是正常的別慌。4. 購物車、訂單與支付回調(diào)解密核心業(yè)務(wù)模塊的源碼走讀與改造點(diǎn)4.1 商品列表接口的讀取邏輯從數(shù)據(jù)庫到JSON返回的分頁寫法商城頁面打開第一個(gè)請(qǐng)求必然是商品列表。我們讀源碼時(shí)優(yōu)先看這個(gè)接口的實(shí)現(xiàn)。一個(gè)質(zhì)量合格的商城后端商品列表不會(huì)是“一次性查出所有記錄”而是分頁返回。常規(guī)實(shí)現(xiàn)如下// 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的記錄總數(shù)再用 OrderByDescending 排序最后用 Skip 和 Take 截取某一頁。這里隱藏著一個(gè)應(yīng)屆生容易翻車的點(diǎn)如果先Skip再OrderBy有些數(shù)據(jù)庫會(huì)報(bào)錯(cuò)或者得到無序數(shù)據(jù)。務(wù)必保證順序是“Where - OrderBy - Skip - Take”。我在代碼審查里見過有人把 OrderBy 寫在 Skip 后面然后首頁數(shù)據(jù)每次都不一樣排查了半天竟是這一行順序問題。另外ProductDto 是專門給前端返回的模型不要直接把數(shù)據(jù)庫實(shí)體 Product 暴露給小程序。我看到過把內(nèi)部字段 UserId、CreatedAt 全都返回給前端的寫法這不安全。改造點(diǎn)很簡(jiǎn)單建一個(gè) DTO 類只放前端要的字段再用 Select 做映射。源碼里如果沒有 ProductDto建議你加上后面加字段會(huì)省心很多。4.2 購物車數(shù)據(jù)是存本地Storage還是C#服務(wù)端兩種方案的取舍購物車是商城項(xiàng)目的分水嶺。很多Demo為了省事把購物車數(shù)據(jù)存在小程序端的 Storage 里說“反正用戶沒登錄也能加購物車”。這個(gè)方案在真實(shí)商城項(xiàng)目里根本撐不住用戶換手機(jī)、清緩存、小程序崩潰重裝后購物車全沒了而且用戶在一臺(tái)手機(jī)上加入購物車想在另一臺(tái)設(shè)備上繼續(xù)購物做不到。成熟的源碼工程設(shè)計(jì)是把購物車放服務(wù)端。后端用一張 CartItem 表至少包含 Id、UserId、ProductId、Quantity、Selected 這幾個(gè)字段。用戶每次加購小程序調(diào)用接口// Controllers/CartController.cs [HttpPost] public async TaskIActionResult Add([FromBody] CartAddDto dto) { if (dto.Quantity 0) return BadRequest(new { code 1, msg 數(shù)量不合法 }); 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 已加入購物車 }); }這里值得關(guān)注的是 GetUserIdFromToken() 這個(gè)方法。很多商城源碼會(huì)有重復(fù)代碼——在每個(gè)Controller里手寫解析token一長(zhǎng)串邏輯。正確做法是定義公共方法或過濾器。你在改造時(shí)如果發(fā)現(xiàn)每個(gè)接口都重復(fù)貼了一段“payload.Substring(…)”建議把它抽到公共類這是高內(nèi)聚的一個(gè)很實(shí)在的改進(jìn)。另外加入購物車要確認(rèn)用戶選項(xiàng)是否選中的狀態(tài)有些源碼做成加完就把整個(gè)購物車覆蓋返回這會(huì)丟失用戶對(duì)某個(gè)商品勾選的記憶。本地Storage不是完全不能用它適合存那些服務(wù)端不需要持久化的臨時(shí)狀態(tài)比如購物車界面的勾選動(dòng)畫狀態(tài)、結(jié)算單里的備注草稿。核心購物車數(shù)據(jù)一定要走后端。4.3 微信支付統(tǒng)一下單與回調(diào)驗(yàn)簽源碼里最值得復(fù)用的部分支付是整個(gè)商城源碼里最值錢的部分。小程序端調(diào)不起支付接口這只是第一步真正硬核的是后端跟微信支付的對(duì)接。標(biāo)準(zhǔn)流程是小程序把訂單信息發(fā)給C#后端C#后端調(diào)用微信支付的“統(tǒng)一下單API”拿到 prepay_id再生成商戶簽名返回給小程序的 wx.requestPayment用戶確認(rèn)支付后微信服務(wù)器把支付結(jié)果回調(diào)到我們的后端指定接口。這中間驗(yàn)簽最容易被抄錯(cuò)。很多源碼里驗(yàn)簽是這么寫的// Services/PayService.cs —— 回調(diào)驗(yàn)簽核心邏輯 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) { // 驗(yàn)簽通過更新訂單狀態(tài) }這里有三處坑改造的時(shí)候要看著。一是排序規(guī)則。微信支付官方要求參數(shù)按 ASCII 碼升序排列很多源碼用 OrderBy(k k.Key)默認(rèn)語義就是按枚舉器對(duì) string 做字典序排序這點(diǎn)沒問題但如果你為了好看改成“按出現(xiàn)順序”就廢了。二是空值處理。官方文檔明確說參數(shù)為空的不要參與簽名源碼里如果沒有過濾空串要補(bǔ)上Where(k !string.IsNullOrEmpty(k.Value))。三是MD5大小寫。微信支付要求簽名結(jié)果轉(zhuǎn)大寫但如果源碼里先轉(zhuǎn)小寫再比較回調(diào)永遠(yuǎn)通不過。我建議你改動(dòng)后先打印兩邊簽名再比較別盲改密鑰。支付回調(diào)地址是在小程序端調(diào)用 wx.requestPayment 時(shí)通過統(tǒng)一下單傳入的 notify_url 參數(shù)指定的。很多源碼包用的地址是 http://localhost:5000這顯然收不到微信服務(wù)器的回調(diào)。本地調(diào)試時(shí)可以用內(nèi)網(wǎng)穿透工具暴露一個(gè)公網(wǎng)HTTPS地址但正式配置一定要改成你的線上域名且必須是用ICP備案過的。支付回調(diào)里還要做冪等如果同一筆訂單被回調(diào)兩次第二次不能把訂單狀態(tài)從“已支付”改回“待支付”要在校驗(yàn)訂單狀態(tài)處加個(gè)判斷。5. 避坑這5個(gè)問題讓新手部署時(shí)最容易翻車附排查與修復(fù)方法5.1 現(xiàn)象小程序端 request 報(bào) “url not in domain list” 或 “TLS版本過低”這是我被問到最多的問題。開發(fā)環(huán)境一切正常真機(jī)預(yù)覽或體驗(yàn)版時(shí)所有請(qǐng)求全部失敗控制臺(tái)提示 “url not in domain list”或者 “安信TLS版本過低”。原因很簡(jiǎn)單微信小程序的正式環(huán)境綁定了 request 合法域名且要求該域名已備案、必須HTTPS、TLS版本不能低于1.2。解決登錄微信公眾平臺(tái)在小程序管理后臺(tái)的“開發(fā)管理—開發(fā)設(shè)置—服務(wù)器域名”里把后端接口的HTTPS域名加進(jìn) request 合法域名。域名不能帶 http:// 前綴也不能是IP或localhost。如果提示TLS版本過低檢查服務(wù)器上的SSL證書配置Nginx里把 ssl_protocols 設(shè)置成 TLSv1.2 TLSv1.3并重啟Nginx。本地開發(fā)用測(cè)試號(hào)可以暫時(shí)忽略域名校驗(yàn)但看不到線上真實(shí)表現(xiàn)。我的習(xí)慣是盡量早配一個(gè)正式的HTTPS域名越晚配越被動(dòng)。5.2 現(xiàn)象C#后端啟動(dòng)后接口500查看日志發(fā)現(xiàn)是數(shù)據(jù)庫連接字符串問題現(xiàn)象是瀏覽器訪問接口返回500而不是404或JSON?？刂婆_(tái)日志往往寫著 “Cannot open database” 或者 “Login failed for user sa”。原因是源碼包里自帶的連接字符串是針對(duì)作者本機(jī)數(shù)據(jù)庫寫的你本地如果沒有同名數(shù)據(jù)庫和賬號(hào)自然連不上。解決打開 appsettings.json找到 ConnectionStrings 節(jié)點(diǎn)改成你自己的數(shù)據(jù)庫。比如原來是Server.;DatabaseShopDb;Usersa;Password123456如果用的是Windows認(rèn)證就改成Server.;DatabaseShopDb;Trusted_ConnectionTrue;。如果SQL Server服務(wù)叫SQLEXPRESS需要寫成Server.\\SQLEXPRESS;...。改完重啟 dotnet run。這里我有一個(gè)習(xí)慣先把數(shù)據(jù)庫腳本導(dǎo)入成功再用 SQL Server Management Studio 的連接字符串填到配置里盡量從 Studio 的“連接屬性”復(fù)制完整連接串避免少寫一個(gè)分號(hào)或選項(xiàng)。5.3 現(xiàn)象局域網(wǎng)真機(jī)預(yù)覽時(shí)連不上后端開發(fā)者工具卻正常開發(fā)者工具在小程序端模擬器里請(qǐng)求本機(jī)后端沒問題但用手機(jī)掃碼真機(jī)預(yù)覽后所有請(qǐng)求都失敗。原因有兩個(gè)一是手機(jī)和電腦不在同一個(gè)局域網(wǎng)二是電腦防火墻攔了5000端口。解決用命令ipconfig找出你電腦的IPv4地址比如192.168.1.108把小程序里 baseUrl 改成http://192.168.1.108:5000。然后在Windows防火墻的“高級(jí)設(shè)置—入站規(guī)則”中放行5000端口或者干脆在啟動(dòng)時(shí)用dotnet run --urls http://0.0.0.0:5000強(qiáng)制監(jiān)聽所有網(wǎng)卡。很多源碼默認(rèn)只監(jiān)聽 localhost所以即使你改對(duì)了IP也白搭。注意真實(shí)項(xiàng)目里微信的登錄要在微信公眾平臺(tái)配置業(yè)務(wù)域名或下載校驗(yàn)文件測(cè)試環(huán)境用 IP 訪問很容易踩這個(gè)雷建議早點(diǎn)上正式域名。5.4 現(xiàn)象Newtonsoft.Json 與 System.Text.Json 混用導(dǎo)致字段大小寫對(duì)不上源碼里有些接口返回字段是駝峰如 productName有些返回的是帕斯卡如 ProductName小程序端拿到的數(shù)據(jù)總有幾個(gè)字段是 undefined。原因是老版本用 Newtonsoft.Json默認(rèn)把它序列化成與屬性名一致新版本用 System.Text.Json默認(rèn)序列化會(huì)把C#的帕斯卡名字轉(zhuǎn)換成小寫開頭。如果兩種情況混用前后端對(duì)不上就是必然。解決統(tǒng)一JSON序列化配置。在 Program.cs 或 Startup.cs 里加上下面的代碼builder.Services.AddControllers() .AddJsonOptions(options { options.JsonSerializerOptions.PropertyNamingPolicy null; options.JsonSerializerOptions.PropertyNameCaseInsensitive true; });這里把 PropertyNamingPolicy 設(shè)為 null表示保持C#屬性的原始大小寫不變PropertyNameCaseInsensitive 設(shè)為 true表示反序列化時(shí)忽略大小寫小程序端用大寫或小寫都能綁上。如果源碼里還在用 Newtonsoft那你就在 AddNewtonsoftJson() 里把 ContractResolver 設(shè)成 CamelCasePropertyNamesContractResolver兩邊選擇一個(gè)統(tǒng)一策略。我最煩這個(gè)坑因?yàn)閳?bào)錯(cuò)不是500而是靜默地返回undefined排查時(shí)間很長(zhǎng)。5.5 現(xiàn)象IIS發(fā)布后上傳圖片404虛擬目錄配置錯(cuò)位本地開發(fā)時(shí)圖片上傳讀取一切正常發(fā)布到Windows服務(wù)器的IIS后商品圖片全部404提示找不到文件。原因通常是源碼里圖片的物理路徑寫死了相對(duì)路徑比如wwwroot\uploads而 IIS 的工作目錄并非項(xiàng)目發(fā)布目錄或者發(fā)布時(shí)未包含 uploads 文件夾。解決先把發(fā)布目錄里有沒有 uploads 文件夾確認(rèn)一遍沒有就手動(dòng)建一個(gè)并給 IIS 站點(diǎn)的應(yīng)用程序池用戶設(shè)置寫入權(quán)限。然后檢查源碼中圖片保存路徑的寫法。推薦改成基于 IWebHostEnvironment 的路徑var uploadsDir Path.Combine(_env.WebRootPath, uploads); if (!Directory.Exists(uploadsDir)) Directory.CreateDirectory(uploadsDir);不要在代碼里寫死C:\inetpub\...。另外小程序訪問圖片的URL要直接映射到https://你的域名/uploads/xxx.jpg不要走代理還把虛擬目錄路徑漏掉。我見過最離譜的錯(cuò)誤是IIS里添加的虛擬目錄叫 files代碼里卻寫/upload名字不對(duì)應(yīng)圖片自然就404了。建議在瀏覽器里打開圖片地址看具體報(bào)錯(cuò)是404還是403逐層排查。6. 讓商城源碼變成能上線的產(chǎn)品從Demo到生產(chǎn)的三步加固與一個(gè)關(guān)鍵技巧6.1 先刪掉源碼里的默認(rèn)賬號(hào)和弱口令這類源碼包為了演示方便通常會(huì)在數(shù)據(jù)庫初始化腳本里塞進(jìn)一個(gè) admin / 123456 的管理員賬號(hào)甚至有的在 C# 代碼里硬編碼了一個(gè)萬能token。上線前你必須刪掉這些并在用戶表里確認(rèn)沒有“上帝賬號(hào)”。我的做法是直接重跑數(shù)據(jù)庫腳本把 Seed 部分的管理員密碼字段改成隨機(jī)字符串或者換成自己通過 BCrypt 生成的新密碼。同時(shí)檢查 Controllers/ManagerController 之類的后臺(tái)接口有沒有缺少鑒權(quán)。Demo源碼里后臺(tái)接口裸奔的情況非常常見不補(bǔ)就上線等于裸奔。6.2 用 dotnet publish 發(fā)布并配合 Nginx 反向代理生產(chǎn)環(huán)境我推薦先dotnet publish -c Release -o ./publish再把 publish 目錄整體拷貝到服務(wù)器。如果服務(wù)器是 Linux用 Nginx 做反向代理監(jiān)聽443端口并轉(zhuǎn)發(fā)到本地的5000端口如果是 Windows用 IIS 建站點(diǎn)應(yīng)用程序池選“無托管代碼”。發(fā)布完成后一定要把 appsettings.json 里 ConnectionStrings 和 Pay 相關(guān)密鑰換成正式環(huán)境的值并確保服務(wù)器的時(shí)間是網(wǎng)絡(luò)同步的微信支付回調(diào)對(duì)時(shí)間偏移很敏感。6.3 關(guān)鍵技巧給后端接口加一個(gè)請(qǐng)求日志中間件開發(fā)時(shí)我們可以依賴控制臺(tái)日志但上了生產(chǎn)接口出錯(cuò)經(jīng)常是“黑匣子”我們既不知道請(qǐng)求參數(shù)也不知道返回內(nèi)容。所以我每次接手商城源碼第一件事就是加一個(gè)最簡(jiǎn)請(qǐng)求日志中間件把路徑、耗時(shí)、狀態(tài)碼和關(guān)鍵入?yún)⒂涗浵聛韕ublic 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); } }這個(gè)中間件不復(fù)雜但它能幫你快速區(qū)分一件事報(bào)錯(cuò)到底發(fā)生在前端還是后端。我經(jīng)歷過一次線上特價(jià)商品超賣頁面提示“請(qǐng)求失敗”但看日志發(fā)現(xiàn)接口全部200說明是前端數(shù)據(jù)渲染邏輯出錯(cuò)后來又在另一單查不到訂單時(shí)發(fā)現(xiàn)日志顯示401才知道是登錄態(tài)過期沒做自動(dòng)刷新。日志不會(huì)說話但它能告訴你往哪個(gè)方向查。把這個(gè)中間件加在 Program.cs 里用app.UseMiddlewareRequestLogMiddleware();注冊(cè)即可。這些加固做完你的商城就比原始的Demo包往前邁了一大步。我拆過很多源碼包最后能真正上線的人往往不是技術(shù)最炫的而是那些愿意把默認(rèn)密碼刪掉、把日志加上、把數(shù)據(jù)庫連接串搞清楚的人。這套組合拳打下來至少能避免上線后第一個(gè)晚上就被用戶碰到404、500和支付掉單。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取