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