簡介這套畢業(yè)設(shè)計(jì)資源基于微信小程序打造完整商城項(xiàng)目適合計(jì)算機(jī)相關(guān)專業(yè)學(xué)生完成畢業(yè)設(shè)計(jì)或課程設(shè)計(jì)也適合剛?cè)腴T小程序開發(fā)的新手對(duì)照學(xué)習(xí)。項(xiàng)目包含前端小程序頁面與后端服務(wù)代碼覆蓋商城、商品詳情、發(fā)現(xiàn)、我的、支付、消息等核心功能模塊從商品瀏覽到下單支付流程完整并配有商品分類、活動(dòng)專題、個(gè)人中心等多類頁面界面整潔、操作流暢代碼注釋清晰便于理解與二次開發(fā)。壓縮包共68個(gè)文件以png界面截圖、js邏輯腳本、wxml/wxss頁面結(jié)構(gòu)及樣式、json頁面配置為主并附帶數(shù)據(jù)庫腳本與使用說明文檔整體包體僅3.31MB學(xué)習(xí)與部署門檻較低。目前已有1240人學(xué)習(xí)下載配合源碼、數(shù)據(jù)庫、部署說明可快速理解前后端交互流程直接用于畢業(yè)答辯或課程項(xiàng)目演示也可作為后續(xù)二次開發(fā)的功能底版。1. 這套微信小程序商城畢設(shè)到底值不值得下載就跑每年畢業(yè)設(shè)計(jì)季都會(huì)有一批人下載到類似「微信小程序商城畢業(yè)設(shè)計(jì)附源碼」的壓縮包里面有前端小程序、后端代碼、數(shù)據(jù)庫腳本和一個(gè)教程文檔。聽起來挺齊全但真正打開后多數(shù)人被卡在第一步——不知道先點(diǎn)哪個(gè)文件更不知道數(shù)據(jù)庫腳本導(dǎo)進(jìn)去之后為什么報(bào)錯(cuò)。這個(gè)標(biāo)題背后其實(shí)是一套完整的電商閉環(huán)用戶端在小程序里瀏覽商品、加購物車、下單支付管理端在后臺(tái)上架商品、處理訂單中間靠后端接口和 MySQL 數(shù)據(jù)庫把數(shù)據(jù)串起來。所以這篇筆記要解決的不是「這是什么」而是「怎么把它變成你自己的畢設(shè)」。我會(huì)按技術(shù)選型、數(shù)據(jù)庫設(shè)計(jì)、本地運(yùn)行、踩坑排查、二次開發(fā)這條線把從解壓到答辯的完整路徑講清楚。適合兩類人一類是自己下載了這個(gè)包想跑通的新手另一類是準(zhǔn)備拿小程序商城當(dāng)課題、但還沒想清楚工作量怎么分的同學(xué)。先說結(jié)論這個(gè)方向值得做但值不值取決于你能不能把包里的代碼拆開講明白。2. 先看懂項(xiàng)目再動(dòng)手微信小程序商城的技術(shù)棧與目錄結(jié)構(gòu)2.1 為什么這套畢設(shè)選「小程序前端 Spring Boot 后端 MySQL」一個(gè)商城類畢設(shè)最常見的搭配就是微信小程序做用戶端、Spring Boot 寫接口、MySQL 存數(shù)據(jù)。你下載到的包里大概率也是這套組合原因很簡單它覆蓋了畢業(yè)設(shè)計(jì)要求的全部知識(shí)點(diǎn)——小程序端有頁面渲染和交互后端有接口設(shè)計(jì)和業(yè)務(wù)邏輯數(shù)據(jù)庫有表結(jié)構(gòu)和增刪改查。而且這三樣?xùn)|西分開學(xué)都有大量資料組合起來就是一條完整的電商業(yè)務(wù)鏈路。后端用 Spring Boot 而不是別的框架是因?yàn)樗鼘?duì)新手最友好內(nèi)嵌 Tomcat不用單獨(dú)部署容器一個(gè)main方法就能啟動(dòng)。配合 MyBatis 或 MyBatis-Plus 操作數(shù)據(jù)庫寫 SQL 比 JPA 直觀得多。你答辯時(shí)被問到「為什么選這個(gè)技術(shù)?！够卮稹窼pring Boot 簡化配置、MyBatis 方便控制 SQL、小程序天然貼近用戶終端」基本就能站住腳。小程序端不用原生語言而是用 WXML WXSS JS 這一套是因?yàn)槲⑿判〕绦蛏坛潜仨氄{(diào)用微信提供的登錄、支付、收貨地址等能力這些 API 只有在小程序環(huán)境里才能調(diào)通。你看到的pages/index/index、pages/cart/cart這類目錄結(jié)構(gòu)就是小程序的頁面路由。整個(gè)項(xiàng)目本質(zhì)上是一個(gè)「前端展示層 接口層 數(shù)據(jù)層」的三層結(jié)構(gòu)這也是你論文架構(gòu)圖里要畫的那張圖。2.2 解壓后你手里到底有什么源碼目錄與文件約定拿到壓縮包先不要急著導(dǎo)入 IDE。先在文件管理器里解壓然后看一眼總目錄。雖然不同作者放的文件名不一樣但常規(guī)的畢設(shè)包里一定包含這幾樣?xùn)|西你可以對(duì)照著找xxx.sql后綴的數(shù)據(jù)庫腳本通常是mall.sql、shop.sql或db.sql一個(gè)小程序前端目錄特征是有app.js、app.json、pages/文件夾一個(gè)后端工程目錄特征是有pom.xmlMaven 工程或src/main/java結(jié)構(gòu)一個(gè)教程文檔可能是README.md、使用說明.txt或 Word 文檔我一般會(huì)習(xí)慣性地先把目錄結(jié)構(gòu)做一個(gè)標(biāo)記下面這個(gè)樹狀圖可以幫你建立心理預(yù)期wechat-shop/ ├── miniprogram/ # 小程序前端代碼 │ ├── app.js # 小程序全局邏輯 │ ├── app.json # 頁面路由與窗口配置 │ ├── pages/ # 頁面文件首頁/分類/購物車/我的/訂單 │ ├── utils/ # 封裝好的請求工具 │ └── project.config.json ├── backend/ # Spring Boot 后端工程 │ ├── pom.xml │ └── src/main/ │ ├── java/ # controller / service / mapper 分層 │ └── resources/ # application.yml、mapper XML 文件 ├── sql/ │ └── mall.sql # 建庫建表腳本和初始化數(shù)據(jù) └── 運(yùn)行教程.md這個(gè)結(jié)構(gòu)能幫你快速判斷包的質(zhì)量有沒有sql目錄、后端是不是標(biāo)準(zhǔn) Maven 工程、小程序端有沒有project.config.json。如果這三樣都在說明打包的人把運(yùn)行路徑理清楚了大概率能跑通如果只有一堆頁面文件沒有后端和數(shù)據(jù)庫腳本那它只是一個(gè)前端模板不算完整的畢業(yè)設(shè)計(jì)?？茨夸浀臅r(shí)間大概三分鐘但能幫你避開后續(xù)兩個(gè)小時(shí)的踩坑。2.3 三端聯(lián)調(diào)的關(guān)系小程序、后端接口、數(shù)據(jù)庫各自負(fù)責(zé)什么整個(gè)商城的業(yè)務(wù)流轉(zhuǎn)是這樣的小程序端發(fā)起請求——比如用戶點(diǎn)擊「加入購物車」前端把商品 ID 和數(shù)量發(fā)送給后端接口后端收到請求后調(diào)用 Service 層的業(yè)務(wù)方法再通過 Mapper 層執(zhí)行 SQL 寫入數(shù)據(jù)庫。也就是說小程序只負(fù)責(zé)展示和交互所有業(yè)務(wù)規(guī)則都在后端數(shù)據(jù)持久化全靠 MySQL。你要理解一個(gè)關(guān)鍵點(diǎn)小程序不能直連數(shù)據(jù)庫。有的同學(xué)下載的包里寫了前端怎么連 MySQL這是錯(cuò)誤的設(shè)計(jì)小程序跑在微信的沙箱環(huán)境里網(wǎng)絡(luò)請求只能走wx.request訪問 HTTPS 或本地 HTTP 接口數(shù)據(jù)庫連接串根本不可能出現(xiàn)在前端代碼里。所以你在小程序端看到的wx.request({ url: http://localhost:8080/product/list })這類代碼那才是正常路徑——localhost指向你的后端服務(wù)后端再去訪問數(shù)據(jù)庫。后端工程里重點(diǎn)看application.yml或application.properties這個(gè)文件它是整個(gè)后端能不能連上數(shù)據(jù)庫的命門。你需要在這里配置數(shù)據(jù)庫地址、用戶名、密碼配置錯(cuò)了后端啟動(dòng)時(shí)就會(huì)報(bào)數(shù)據(jù)庫連接失敗。這個(gè)文件要改成你自己的本地 MySQL 賬號(hào)我在第 4 章會(huì)專門拆解具體的配置項(xiàng)?，F(xiàn)在你只需要記住小程序、后端、數(shù)據(jù)庫三者之間是串聯(lián)關(guān)系排查問題的時(shí)候按照「前端請求不到 → 看后端接口通不通 → 看數(shù)據(jù)庫連沒連上」這個(gè)順序來。3. 把數(shù)據(jù)庫設(shè)計(jì)講明白答辯才有硬貨3.1 一個(gè)商城最少需要幾張表核心表拆解商城的數(shù)據(jù)庫設(shè)計(jì)是畢業(yè)設(shè)計(jì)答辯時(shí)老師最可能追問的地方所以不能只會(huì)導(dǎo)腳本要能說清楚每張表是干什么的。一套完整的商城系統(tǒng)核心表至少包括這幾張用戶表、商品表、商品分類表、購物車表、訂單表、訂單詳情表。有的項(xiàng)目會(huì)加輪播圖表、收貨地址表、管理員表這些屬于加分項(xiàng)。你下載的 SQL 腳本里建表的順序是有講究的先建沒有外鍵依賴的表用戶、分類、商品再建有外鍵依賴的表購物車、訂單。因?yàn)?MySQL 在創(chuàng)建表時(shí)如果引用了不存在的表會(huì)直接報(bào)錯(cuò)。典型的核心表結(jié)構(gòu)大致長這樣-- 用戶表存儲(chǔ)小程序用戶的唯一標(biāo)識(shí) openid CREATE TABLE t_user ( id INT NOT NULL AUTO_INCREMENT COMMENT 用戶ID, openid VARCHAR(64) NOT NULL COMMENT 微信openid小程序登錄唯一標(biāo)識(shí), nickname VARCHAR(50) DEFAULT 微信用戶 COMMENT 昵稱, avatar VARCHAR(255) DEFAULT NULL COMMENT 頭像地址, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 注冊時(shí)間, PRIMARY KEY (id), UNIQUE KEY uk_openid (openid) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用戶表;商品表是信息量最大的表字段一般包含商品名稱、主圖、輪播圖、價(jià)格、庫存、銷量、上下架狀態(tài)、所屬分類。這里有兩個(gè)容易踩坑的字段類型問題價(jià)格一定要用DECIMAL(10,2)而不是FLOAT因?yàn)楦↑c(diǎn)數(shù)在金額計(jì)算時(shí)會(huì)產(chǎn)生精度丟失庫存字段用INT就行但要注意并發(fā)扣減的問題這個(gè)我在后面講訂單時(shí)會(huì)提到。商品和分類之間是一對(duì)多關(guān)系商品表里用一個(gè)category_id外鍵指向分類表的主鍵。訂單相關(guān)的表最好拆成兩張訂單主表和訂單詳情表。主表存訂單號(hào)、用戶ID、總金額、訂單狀態(tài)、創(chuàng)建時(shí)間詳情表存每個(gè)商品項(xiàng)的 ID、購買數(shù)量、單價(jià)。拆成兩張表的原因很實(shí)際同一個(gè)訂單里可能有多件不同商品如果只建一張表要么重復(fù)存儲(chǔ)訂單信息要么沒法表達(dá)多商品。這個(gè)拆表思路你答辯時(shí)一定要主動(dòng)講這是亮點(diǎn)。3.2 商城數(shù)據(jù)庫初始化腳本從導(dǎo)入到驗(yàn)證拿到mall.sql腳本后在 Navicat 或者命令行里執(zhí)行導(dǎo)入。常見做法是先創(chuàng)建一個(gè)數(shù)據(jù)庫再導(dǎo)入腳本也可以在腳本里寫了CREATE DATABASE IF NOT EXISTS。導(dǎo)入完成后你要有驗(yàn)證表是否齊全的意識(shí)不能導(dǎo)完就關(guān)掉。用下面這條 SQL 查看所有表-- 查看當(dāng)前數(shù)據(jù)庫下所有表確認(rèn)導(dǎo)入是否完整 SHOW TABLES;導(dǎo)入后建議主動(dòng)查幾個(gè)關(guān)鍵表的數(shù)據(jù)量確認(rèn)初始化數(shù)據(jù)真正進(jìn)去了-- 商品表應(yīng)該有多條測試商品 SELECT id, name, price, stock FROM t_product LIMIT 5;說說初始化數(shù)據(jù)的作用腳本里除了建表還會(huì)插入測試商品、測試分類、默認(rèn)管理員賬號(hào)。這些數(shù)據(jù)不是擺設(shè)是給你演示用的——小程序首頁展示的商品列表就是從這些數(shù)據(jù)查出來的。如果你導(dǎo)入腳本后小程序首頁空白優(yōu)先檢查商品表里有沒有數(shù)據(jù)而不是去改前端代碼。參數(shù)說明ENGINEInnoDB是必須的它支持事務(wù)訂單創(chuàng)建時(shí)多表寫入需要事務(wù)保證一致性CHARSETutf8mb4比utf8多了對(duì) emoji 表情的支持商城用戶昵稱里經(jīng)常會(huì)有表情符號(hào)用utf8建表存 emoji 會(huì)報(bào)錯(cuò)或變成問號(hào)。如果你手里的腳本建表語句用的是utf8建議自己手動(dòng)改成utf8mb4。3.3 訂單狀態(tài)與庫存扣減數(shù)據(jù)庫層面的業(yè)務(wù)邏輯商城數(shù)據(jù)庫不只是建表存數(shù)據(jù)還隱含了業(yè)務(wù)規(guī)則。最典型的就是訂單狀態(tài)流轉(zhuǎn)待付款、待發(fā)貨、待收貨、已完成、已取消。這些狀態(tài)通常用一個(gè)INT或VARCHAR字段存儲(chǔ)后端代碼里通過常量或枚舉來控制狀態(tài)變更。下單的流程涉及兩張表的聯(lián)動(dòng)創(chuàng)建訂單記錄 扣減商品庫存。這兩步必須在一個(gè)事務(wù)里完成否則會(huì)出現(xiàn)「訂單建好了但庫存沒扣」或者「庫存扣了但訂單沒建成功」的臟數(shù)據(jù)。后端代碼里一般是這樣寫的Override Transactional(rollbackFor Exception.class) public void createOrder(OrderCreateRequest req) { // 1. 創(chuàng)建訂單主表記錄 Order order new Order(); order.setUserId(req.getUserId()); order.setOrderNo(generateOrderNo()); order.setStatus(0); // 0待付款 orderMapper.insert(order); // 2. 扣減商品庫存SQL 層面判斷庫存充足 int rows productMapper.deductStock(req.getProductId(), req.getQuantity()); if (rows 0) { throw new RuntimeException(庫存不足下單失敗); } // 3. 寫入訂單詳情 orderItemMapper.insert(orderItem); }這段代碼的邏輯是先插入訂單主表拿到自增 ID再扣庫存時(shí)用受影響行數(shù)判斷庫存是否夠——如果夠deductStock返回 1繼續(xù)寫入訂單詳情如果不夠返回 0拋出異常觸發(fā)事務(wù)回滾訂單主表那條記錄也不會(huì)留下。Transactional注解是關(guān)鍵它保證方法里所有數(shù)據(jù)庫操作要么全部成功、要么全部回滾。這個(gè)設(shè)計(jì)是你答辯時(shí)能拿出來講的亮點(diǎn)比單純說「我的項(xiàng)目有增刪改查」有說服力得多。需要特別注意的是deductStock對(duì)應(yīng)的 SQL 寫法一定要用條件更新的方式而不是先查再改。UPDATE t_product SET stock stock - #{quantity} WHERE id #{productId} AND stock #{quantity}這種寫法能在一條 SQL 里完成「檢查 扣減」避免并發(fā)下超賣。如果包里的代碼用的是「先 SELECT 再 UPDATE」的寫法建議你改成條件更新這也是一個(gè)主動(dòng)優(yōu)化點(diǎn)。4. 把源碼跑起來環(huán)境配置與本地聯(lián)調(diào)的全過程4.1 環(huán)境準(zhǔn)備清單JDK、MySQL、微信開發(fā)者工具一個(gè)都不能少跑這套商城畢設(shè)你得把環(huán)境先補(bǔ)齊。必要的工具包括JDK 1.8 或更高版本、Maven 3.6、MySQL 5.7 或 8.0、微信開發(fā)者工具、一個(gè)用于后端的 IDEIDEA 或 Eclipse。這些環(huán)境變量配置屬于基礎(chǔ)操作但容易出問題的地方在于版本匹配后端如果用的是較老的 Spring Boot 版本用 JDK 17 啟動(dòng)大概率會(huì)報(bào)錯(cuò)建議優(yōu)先用 JDK 1.8 跑通再說。微信開發(fā)者工具需要去微信官方下載安裝后要用微信掃碼登錄才能創(chuàng)建和導(dǎo)入項(xiàng)目。打開工具后選擇「導(dǎo)入項(xiàng)目」目錄選到小程序前端所在的文件夾有project.config.json的那一層AppID 可以先用測試號(hào)等真機(jī)調(diào)試時(shí)再換自己的小程序 AppID。這里先給出一條檢查命令確認(rèn) Java 和 Maven 就位# 檢查 JDK 版本1.8 會(huì)輸出 java version 1.8.0_xxx java -version # 檢查 Maven 版本確保 mvn 命令可用 mvn -v如果java -version報(bào)錯(cuò)說明 JDK 沒裝或JAVA_HOME環(huán)境變量沒配如果mvn -v報(bào)錯(cuò)說明 Maven 沒裝或沒配MAVEN_HOME。這兩個(gè)命令是后續(xù)所有步驟的前提跑不通就先把環(huán)境修好。4.2 后端啟動(dòng)修改數(shù)據(jù)庫密碼、導(dǎo)入 Maven 依賴、啟動(dòng)服務(wù)后端工程導(dǎo)入 IDEA 后第一步改配置。找到src/main/resources/application.yml里面會(huì)有數(shù)據(jù)庫連接信息把它改成你自己的 MySQL 賬號(hào)密碼和數(shù)據(jù)庫名server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/mall_db?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: 你自己數(shù)據(jù)庫的密碼 driver-class-name: com.mysql.cj.jdbc.Driver mybatis: mapper-locations: classpath:mapper/*.xml configuration: map-underscore-to-camel-case: true這段配置里最常見的坑是serverTimezone。如果你的 MySQL 是 8.0 而沒加這個(gè)參數(shù)啟動(dòng)時(shí)通常會(huì)報(bào)The server time zone value的異常加上Asia/Shanghai才能正確識(shí)別時(shí)區(qū)。map-underscore-to-camel-case是讓數(shù)據(jù)庫的user_name字段自動(dòng)映射到 Java 的userName如果你發(fā)現(xiàn)查出來的數(shù)據(jù)某些字段是 null多半是這個(gè)配置沒開。配置改完后打開 IDEA 的 Maven 面板點(diǎn)刷新讓依賴下載完成。然后啟動(dòng)類上有個(gè)main方法直接右鍵運(yùn)行。注意觀察控制臺(tái)日志看到Tomcat started on port(s): 8080就代表啟動(dòng)成功。之后在瀏覽器里訪問以下地址驗(yàn)證接口是否通# 請求商品列表接口返回 JSON 數(shù)據(jù)即成功 curl http://localhost:8080/api/product/list如果返回了帶商品信息的 JSON說明后端和數(shù)據(jù)庫已經(jīng)聯(lián)通了。這一步是整個(gè)項(xiàng)目跑通的分水嶺后端接口通了小程序端只需要把請求地址指過來就能出數(shù)據(jù)。4.3 小程序端聯(lián)調(diào)修改請求地址和合法域名后端跑通后最后一個(gè)環(huán)節(jié)是小程序前端連到后端接口。打開小程序項(xiàng)目找到封裝請求的文件通常在utils/request.js或config.js里里面定義了一個(gè)baseURL把它改成你的后端地址// utils/request.js const BASE_URL http://localhost:8080; // 本地調(diào)試用真機(jī)調(diào)試要改局域網(wǎng) IP function request(url, method GET, data {}) { return new Promise((resolve, reject) { wx.request({ url: BASE_URL url, method: method, data: data, header: { Content-Type: application/json }, success: (res) resolve(res.data), fail: (err) reject(err) }); }); } module.exports request;這里解釋幾個(gè)參數(shù)url是接口路徑比如/api/product/listmethod是 HTTP 方法商城接口以 GET 和 POST 為主header里聲明Content-Type是為了讓后端正確解析 POST 請求的 JSON 體。對(duì)新手來說最容易發(fā)現(xiàn)的現(xiàn)象是本地調(diào)試時(shí)小程序能請求到數(shù)據(jù)但手機(jī)預(yù)覽時(shí)白屏。原因是在微信開發(fā)者工具里勾選了「不校驗(yàn)合法域名」可以訪問localhost手機(jī)上卻必須走 HTTPS 或局域網(wǎng) IP。本地先跑通真機(jī)調(diào)試的坑我在下一章的避坑清單里專門寫。改完baseURL后在開發(fā)者工具里點(diǎn)擊編譯首頁如果顯示出商品列表恭喜你這套畢設(shè)已經(jīng)在本地完整跑通了。接下來你要做的事就是對(duì)照教程文檔把每個(gè)功能頁面點(diǎn)一遍確認(rèn)購物車、下單、訂單列表這些鏈路都能走通再考慮二次開發(fā)的事。5. 避坑指南微信小程序商城跑不起來的 5 個(gè)高頻問題5.1 小程序編譯報(bào)「ES6 轉(zhuǎn) ES5」錯(cuò)誤或頁面白屏現(xiàn)象導(dǎo)入小程序項(xiàng)目后點(diǎn)擊編譯工具提示某些目錄下存在語法錯(cuò)誤或者頁面直接白屏Console 報(bào)錯(cuò)指向Promise或箭頭函數(shù)。原因是微信開發(fā)者工具默認(rèn)對(duì) ES6 語法的轉(zhuǎn)換規(guī)則和你本機(jī)的「基礎(chǔ)庫版本」不完全兼容。解決方法是在工具欄點(diǎn)擊「詳情」—「本地設(shè)置」勾選「ES6 轉(zhuǎn) ES5」同時(shí)把調(diào)試基礎(chǔ)庫版本切換到 2.x 左右不要用最新的 3.x 測試版。這類問題在舊項(xiàng)目上尤其常見老源碼用了async/await的寫法基礎(chǔ)庫版本太老反而識(shí)別不了。5.2 后端啟動(dòng)報(bào)「Access denied for user root」現(xiàn)象后端運(yùn)行后控制臺(tái)拋出Access denied for user rootlocalhost提示密碼錯(cuò)誤。原因通常是你把a(bǔ)pplication.yml里的密碼改錯(cuò)了或者 MySQL 8.0 默認(rèn)的加密插件是caching_sha2_password而項(xiàng)目里的 MySQL 驅(qū)動(dòng)版本過舊兩者握手失敗。解決方法是先確認(rèn)密碼沒錯(cuò)然后去 MySQL 執(zhí)行ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY 你的密碼;把認(rèn)證插件改成舊的mysql_native_password模式。如果你用的是 MySQL 5.7這條問題基本不會(huì)出現(xiàn)。5.3 首頁有數(shù)據(jù)但點(diǎn)進(jìn)商品詳情是空白現(xiàn)象小程序首頁列表能正常顯示商品點(diǎn)擊某個(gè)商品跳轉(zhuǎn)到詳情頁后頁面沒有內(nèi)容。原因大概率不是頁面代碼壞了而是詳情頁請求的接口參數(shù)傳的是「商品 ID」而后端接口要求的是「商品編碼」兩個(gè)字段對(duì)不上導(dǎo)致查不到數(shù)據(jù)。解決方法是打開詳情頁 JS 文件查看onLoad(options)里取到的參數(shù)名和后端 Controller 方法的PathVariable或RequestParam對(duì)比一下改成一致。這類問題排查起來很快在 Console 里看到請求返回的 JSON 里data是null基本就實(shí)錘了。5.4 真機(jī)預(yù)覽請求不到數(shù)據(jù)但模擬器正?，F(xiàn)象在開發(fā)者工具里一切正常點(diǎn)「真機(jī)預(yù)覽」后手機(jī)打開小程序所有列表都是空的網(wǎng)絡(luò)請求全部報(bào)fail。原因很明確手機(jī)端不認(rèn)localhost。你電腦上的localhost:8080只能指向本機(jī)手機(jī)訪問時(shí)必須用電腦在局域網(wǎng)內(nèi)的 IP比如192.168.1.101:8080。解決方法是先把電腦防火墻對(duì) 8080 端口放行然后把BASE_URL改成局域網(wǎng) IP手機(jī)和電腦連同一個(gè) Wi-Fi重新編譯預(yù)覽。如果手機(jī)還是請求失敗用電腦開個(gè)熱點(diǎn)讓手機(jī)連再換對(duì)應(yīng)的熱點(diǎn) IP這類問題基本都能解決。5.5 查詢訂單時(shí)間比實(shí)際時(shí)間早或晚 8 小時(shí)現(xiàn)象訂單創(chuàng)建時(shí)間和實(shí)際時(shí)間差了整 8 個(gè)小時(shí)。原因是 MySQL 連接串里沒有加serverTimezoneAsia/Shanghai數(shù)據(jù)庫默認(rèn)按服務(wù)器的 UTC 時(shí)區(qū)處理東八區(qū)的時(shí)間被當(dāng)成了標(biāo)準(zhǔn)時(shí)間存儲(chǔ)。解決方法很簡單在application.yml里給 JDBC 連接串后面加上serverTimezoneAsia/Shanghai重啟后端。這個(gè)問題不影響功能跑通但影響觀感答辯演示時(shí)被老師看到時(shí)間對(duì)不上多少會(huì)減印象分。6. 進(jìn)階一步給商城加「列表分頁加載」和「訂單搜索」的改造示范跑通源碼只是起點(diǎn)要想拿高分你要讓項(xiàng)目看起來像「你的作品」而不是「下載的模板」。最容易出效果的改造方向是給商品列表加上分頁加載——這也是實(shí)際商城必備的交互熱搜里的「微信小程序頁面列表加載更多」就是指這個(gè)功能。代碼邏輯不復(fù)雜后端加兩個(gè)參數(shù)、小程序端改一段觸底函數(shù)就能講出「我優(yōu)化了列表性能」的故事。先看后端改造。大多數(shù)畢設(shè)源碼中的商品列表接口是一次性返回全部數(shù)據(jù)數(shù)據(jù)量少看不出來但你答辯時(shí)可以主動(dòng)說「這個(gè)接口在高數(shù)據(jù)量下會(huì)變慢所以我加了分頁」。修改ProductController中的查詢方法接收page和size兩個(gè)參數(shù)返回固定條數(shù)和總數(shù)GetMapping(/api/product/list) public Result getProductList(RequestParam(defaultValue 1) Integer page, RequestParam(defaultValue 10) Integer size) { int offset (page - 1) * size; ListProduct list productMapper.selectPage(offset, size); int total productMapper.countAll(); return Result.ok(list, total); }這段代碼的邏輯是page從 1 開始o(jì)ffset根據(jù)頁碼算出 SQL 的LIMIT起始位置size控制每頁條數(shù)。對(duì)應(yīng)的 Mapper 里用兩條 SQL一條查當(dāng)前頁數(shù)據(jù)一條查總條數(shù)前端拿總數(shù)來算有沒有下一頁。參數(shù)說明默認(rèn)值設(shè)為1和10是為了兼容舊請求——不傳參數(shù)時(shí)也能正常返回第一頁不會(huì)影響已有調(diào)用。前端小程序端在商品列表頁監(jiān)聽滾動(dòng)到底部事件觸底時(shí)把page加一再請求下一頁把新數(shù)據(jù)追加到數(shù)組末尾。判斷是否還能加載用后端返回的總條數(shù)和當(dāng)前已加載條數(shù)對(duì)比// 商品列表頁 JS let currentPage 1; const pageSize 10; onReachBottom() { const total this.data.total; const loaded this.data.productList.length; if (loaded total) { this.setData({ hasMore: false }); // 全部加載完不再請求 return; } currentPage; this.loadProducts(currentPage); } loadProducts(page) { const baseUrl http://localhost:8080; wx.request({ url: baseUrl /api/product/list, data: { page: page, size: pageSize }, success: (res) { const newList this.data.productList.concat(res.data.data.list); this.setData({ productList: newList, total: res.data.data.total }); } }); }這里有一個(gè)容易出錯(cuò)的細(xì)節(jié)concat是新數(shù)組賦值不能直接用push后再setData因?yàn)樾〕绦虻臄?shù)據(jù)綁定需要你傳入一個(gè)全新的數(shù)組才能觸發(fā)視圖更新。hasMore是一個(gè)控制變量數(shù)據(jù)加載完時(shí)置為false避免觸底后重復(fù)發(fā)無效請求。這個(gè)改造只要兩個(gè)小時(shí)但答辯時(shí)你能講出「列表性能優(yōu)化」「按需加載」這些關(guān)鍵詞效果完全不一樣。第二個(gè)低成本改造是給訂單列表加上按訂單號(hào)模糊搜索。后端接口加一個(gè)可選的關(guān)鍵詞參數(shù)Mapper XML 里寫動(dòng)態(tài) SQL。需要注意 SQL 里L(fēng)IKE的寫法CONCAT(%, #{keyword}, %)很多新手直接寫%${keyword}%那會(huì)產(chǎn)生 SQL 注入風(fēng)險(xiǎn)。這里順便說句血淚經(jīng)驗(yàn)我當(dāng)年答辯前就是因?yàn)轫樖钟昧?{}拼參數(shù)被老師當(dāng)場問了 SQL 注入怎么防答得磕磕絆絆差點(diǎn)翻車。后來養(yǎng)成的習(xí)慣是寫 SQL 一律用#{}涉及 LIKE 模糊查詢就用CONCAT拼接這個(gè)習(xí)慣也建議你帶進(jìn)后面的工作里。做完這兩個(gè)改造建議你重新從用戶注冊到下單走一遍全流程確認(rèn)分頁加載沒有影響數(shù)據(jù)正確性。這個(gè)驗(yàn)證過程本身就是你論文里「系統(tǒng)測試」章節(jié)的素材截圖保存好。最后說一句我的個(gè)人習(xí)慣不管是下載的源碼還是自己寫的代碼拿到手我都會(huì)先通讀一遍核心接口再?zèng)Q定改哪里而不是邊改邊看——這個(gè)習(xí)慣幫我躲過了不少「改了半天發(fā)現(xiàn)源頭是另一個(gè)文件」的坑。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取