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