很多準(zhǔn)備畢業(yè)設(shè)計(jì)的同學(xué)看到“微信小程序 管理系統(tǒng)”這類題目第一反應(yīng)往往是這個(gè)方向是不是太普通了會(huì)不會(huì)和別人撞題但真正動(dòng)手之后才會(huì)意識到這類題目能成為畢業(yè)設(shè)計(jì)里的常青樹恰恰是因?yàn)樗岩苿?dòng)端、服務(wù)端、數(shù)據(jù)庫、權(quán)限控制、訂單流程和論文撰寫全部串在了一條完整的鏈路上任何一個(gè)環(huán)節(jié)偷懶都會(huì)在答辯時(shí)暴露。水果店管理系統(tǒng)就是這個(gè)方向里非常有代表性的一個(gè)業(yè)務(wù)規(guī)則清楚、角色劃分明確、數(shù)據(jù)流完整既不會(huì)難到做不出來又足夠撐起一篇內(nèi)容扎實(shí)的論文。這篇文章不會(huì)只貼代碼而是會(huì)從選題價(jià)值、系統(tǒng)架構(gòu)、數(shù)據(jù)庫設(shè)計(jì)、前后端實(shí)現(xiàn)、聯(lián)調(diào)驗(yàn)證、論文寫作到答辯準(zhǔn)備把這套“微信小程序水果店管理系統(tǒng)”完整拆開講清楚。無論你是正在選畢業(yè)設(shè)計(jì)題目還是已經(jīng)在做同類管理系統(tǒng)這篇文章都可以作為一個(gè)可以直接復(fù)用的實(shí)戰(zhàn)模板。1. 這類畢業(yè)設(shè)計(jì)項(xiàng)目為什么值得做很多同學(xué)選畢業(yè)設(shè)計(jì)題目時(shí)會(huì)在“太簡單怕過不了”和“太難怕完不成”之間反復(fù)糾結(jié)。信息管理系統(tǒng)方向之所以常年被推薦是因?yàn)樗幵谝粋€(gè)很合適的位置開發(fā)難度適中但工程鏈路完整。以水果店管理系統(tǒng)為例它天然具備幾個(gè)非常適合畢業(yè)設(shè)計(jì)的特征。第一業(yè)務(wù)場景足夠生活化水果店是大家熟悉的零售場景需求不需要額外解釋評審老師一眼就能看懂第二業(yè)務(wù)鏈條完整從用戶注冊登錄、瀏覽商品、加入購物車、下單支付到管理員管理商品、處理訂單、發(fā)布公告整個(gè)流程覆蓋了典型的電商業(yè)務(wù)閉環(huán)第三技術(shù)棧選擇空間大前端可以用微信小程序原生開發(fā)也可以使用 uni-app后端可以用 Spring Boot、SSM 甚至 Node.js數(shù)據(jù)庫可以用 MySQL每一種選擇都有大量的社區(qū)資料可以參考。這個(gè)選題還有一個(gè)容易被忽略的優(yōu)勢它非常適合展示“從需求到交付”的完整過程。畢業(yè)設(shè)計(jì)評分的核心不只是代碼能不能跑而是你有沒有把需求分析、數(shù)據(jù)庫設(shè)計(jì)、接口定義、前后端聯(lián)調(diào)、系統(tǒng)測試這些環(huán)節(jié)說清楚。水果店管理系統(tǒng)的業(yè)務(wù)規(guī)模不大不小剛好可以把這些環(huán)節(jié)全部走一遍不會(huì)因?yàn)闃I(yè)務(wù)過于復(fù)雜導(dǎo)致說不清楚也不會(huì)因?yàn)闃I(yè)務(wù)太簡單導(dǎo)致無話可寫。如果你正在糾結(jié)選題這套系統(tǒng)的價(jià)值在于它既能讓你在開發(fā)過程中學(xué)到完整的工程實(shí)踐又能在論文寫作時(shí)有足夠的內(nèi)容支撐屬于那種“做著不痛苦、寫論文有素材、答辯不心虛”的題目。2. 系統(tǒng)整體架構(gòu)與技術(shù)選型2.1 三層架構(gòu)設(shè)計(jì)這套水果店管理系統(tǒng)從物理結(jié)構(gòu)上分為三個(gè)部分微信小程序客戶端、后端服務(wù)、管理后臺。三者之間通過 HTTP 接口通信數(shù)據(jù)統(tǒng)一存儲在 MySQL 中。用戶端是微信小程序消費(fèi)者通過微信掃碼或搜索進(jìn)入小程序完成注冊登錄、瀏覽商品、加入購物車、提交訂單、訂單支付、查看個(gè)人訂單等操作。管理端是給水果店老板或店員使用的后臺頁面負(fù)責(zé)商品上下架、庫存管理、訂單處理、公告發(fā)布、用戶管理等操作。后端服務(wù)是整個(gè)系統(tǒng)的中樞既要為小程序提供用戶相關(guān)的接口也要為管理后臺提供運(yùn)營相關(guān)的接口同時(shí)還要處理登錄鑒權(quán)、訂單狀態(tài)流轉(zhuǎn)、數(shù)據(jù)統(tǒng)計(jì)等核心業(yè)務(wù)邏輯。這種架構(gòu)在畢業(yè)設(shè)計(jì)中是性價(jià)比最高的選擇。它比單純的“網(wǎng)頁 數(shù)據(jù)庫”更貼近真實(shí)的移動(dòng)互聯(lián)網(wǎng)應(yīng)用形態(tài)又不像大型分布式系統(tǒng)那樣難以駕馭。2.2 技術(shù)棧選擇與理由這套系統(tǒng)在技術(shù)選型上有一個(gè)清晰的原則每一項(xiàng)技術(shù)都選擇資料最豐富、問題排查最容易的方案。層次技術(shù)選型選擇理由小程序端微信小程序原生框架組件和 API 官方文檔完善無需額外構(gòu)建工具調(diào)試方便管理端Vue Element UI 或 Thymeleaf如果是前后端分離Vue 更靈活如果想控制工作量服務(wù)端渲染更簡單后端Spring Boot自動(dòng)配置減少大量 XML 配置內(nèi)置 Tomcat適合快速開發(fā)數(shù)據(jù)庫MySQL開源穩(wěn)定主流教程多支持事務(wù)適合訂單類業(yè)務(wù)ORMMyBatis 或 MyBatis-Plus手寫 SQL 可控性強(qiáng)MyBatis-Plus 能減少重復(fù)代碼鑒權(quán)方案JWT 或微信登錄態(tài) session小程序場景下微信登錄是標(biāo)配JWT 適合管理端接口鑒權(quán)從實(shí)際開發(fā)的角度看Spring Boot MyBatis MySQL 微信小程序原生這套組合是資料最全、踩坑最少的方案。網(wǎng)上關(guān)于這套技術(shù)棧的教程數(shù)量巨大遇到問題幾乎都能搜到對應(yīng)的解決方案對于時(shí)間有限的畢業(yè)生來說這本身就是巨大的優(yōu)勢。2.3 為什么不用更復(fù)雜的技術(shù)有些同學(xué)為了讓選題顯得“高級”會(huì)在系統(tǒng)里引入 Redis 緩存、消息隊(duì)列、微服務(wù)等組件。這里給一個(gè)比較直接的建議如果這是畢業(yè)設(shè)計(jì)而不是大廠生產(chǎn)項(xiàng)目不要為了堆技術(shù)而堆技術(shù)。水果店管理系統(tǒng)的并發(fā)量和使用規(guī)模用 Spring Boot 單機(jī)部署完全足夠。技術(shù)選型好不好不是看用了多少新技術(shù)而是看每一項(xiàng)技術(shù)是否解決了實(shí)際問題。如果論文里寫了 Redis 緩存那么答辯老師問你緩存穿透、緩存雪崩怎么處理你需要答得上來如果寫了消息隊(duì)列那么你要能說清楚削峰填谷在這個(gè)系統(tǒng)里到底解決了什么具體問題。這些追問如果答不上來反而會(huì)變成扣分點(diǎn)。當(dāng)然如果你確實(shí)熟悉這些技術(shù)在論文里作為“擴(kuò)展與優(yōu)化方向”提一下會(huì)是加分項(xiàng)。3. 核心功能設(shè)計(jì)與角色劃分3.1 用戶角色與需求分析水果店管理系統(tǒng)涉及兩類使用者需求截然不同。普通用戶消費(fèi)者關(guān)注的是購買體驗(yàn)?zāi)懿荒芸焖僬业较胭I的水果能不能看到清晰的圖片和價(jià)格購物車好不好用下單流程是否順暢能不能查到自己的歷史訂單。在小程序端需要實(shí)現(xiàn)的用戶功能包括微信登錄和手機(jī)號綁定、水果分類瀏覽與商品搜索、商品詳情查看、加入購物車、購物車數(shù)量修改、提交訂單、訂單支付或模擬支付、訂單狀態(tài)查詢、個(gè)人中心信息管理。管理員關(guān)注的是運(yùn)營效率哪些商品賣得好需要補(bǔ)貨哪些商品庫存不足訂單處理到哪一步了今天營業(yè)額是多少。在管理端需要實(shí)現(xiàn)的功能包括管理員登錄與權(quán)限校驗(yàn)、商品分類管理、商品信息管理新增、編輯、上下架、庫存調(diào)整、訂單管理訂單查詢、發(fā)貨、完成、取消、公告管理、用戶管理、基礎(chǔ)數(shù)據(jù)統(tǒng)計(jì)。從需求分析的角度這兩類角色已經(jīng)覆蓋了“用戶端 管理端”的完整業(yè)務(wù)閉環(huán)論文里寫“系統(tǒng)分析”章節(jié)時(shí)用例圖和用例說明都有充足素材。3.2 功能模塊劃分整個(gè)系統(tǒng)的功能模塊可以做如下劃分模塊所屬端核心功能用戶模塊小程序端微信登錄、用戶信息維護(hù)商品模塊小程序端 管理端商品分類、商品列表、商品詳情、商品管理購物車模塊小程序端加入購物車、修改數(shù)量、刪除、清空訂單模塊小程序端 管理端提交訂單、訂單狀態(tài)流轉(zhuǎn)、訂單管理公告模塊小程序端 管理端公告列表、公告詳情、公告發(fā)布統(tǒng)計(jì)模塊管理端商品銷量統(tǒng)計(jì)、訂單金額統(tǒng)計(jì)這種模塊劃分在論文寫作時(shí)非常友好每個(gè)模塊都可以寫一段功能描述對應(yīng)一張界面截圖或接口說明工作量清晰可見。3.3 訂單狀態(tài)設(shè)計(jì)訂單是整個(gè)管理系統(tǒng)的核心狀態(tài)設(shè)計(jì)是否合理會(huì)直接影響開發(fā)的復(fù)雜度和論文的深度。建議把訂單狀態(tài)設(shè)計(jì)為以下幾個(gè)階段待付款用戶提交訂單但尚未支付待發(fā)貨用戶完成支付商家需要準(zhǔn)備水果待收貨商家確認(rèn)發(fā)貨水果在配送路上已完成用戶確認(rèn)收貨訂單正常結(jié)束已取消用戶或管理員取消訂單在數(shù)據(jù)庫里訂單狀態(tài)字段可以用int類型存儲如 0、1、2、3、4也可以使用varchar存儲狀態(tài)名稱。從可讀性考慮建議使用數(shù)字枚舉在代碼和論文中定義好狀態(tài)常量前端再根據(jù)數(shù)字映射中文提示。這一點(diǎn)在后端接口設(shè)計(jì)部分會(huì)給出代碼示例。4. 數(shù)據(jù)庫表結(jié)構(gòu)設(shè)計(jì)4.1 設(shè)計(jì)原則數(shù)據(jù)庫設(shè)計(jì)是畢業(yè)設(shè)計(jì)論文里最容易拿分也最容易出錯(cuò)的部分。水果店管理系統(tǒng)的核心表可以控制在 8 張以內(nèi)每張表的字段命名要規(guī)范類型選擇要合理外鍵關(guān)系要在 ER 圖中體現(xiàn)清楚。一個(gè)比較穩(wěn)妥的設(shè)計(jì)是包含以下數(shù)據(jù)表user用戶表存儲小程序用戶信息category商品分類表product商品表存儲水果的名稱、圖片、價(jià)格、庫存、描述等cart購物車表orders訂單表存儲用戶下單信息order_item訂單明細(xì)表存儲訂單中包含的商品明細(xì)announcement公告表admin管理員表4.2 核心表結(jié)構(gòu)示例下面給出三張核心表的建表 SQL可以直接在 MySQL 中執(zhí)行。表名字段使用下劃線命名主鍵統(tǒng)一使用id時(shí)間字段統(tǒng)一使用datetime金額字段使用decimal(10, 2)這些細(xì)節(jié)在論文中都會(huì)被評審老師注意到。-- 用戶表 CREATE TABLE user ( id bigint(20) NOT NULL AUTO_INCREMENT, openid varchar(64) NOT NULL COMMENT 微信openid唯一標(biāo)識, nickname varchar(64) DEFAULT NULL COMMENT 用戶昵稱, avatar varchar(255) DEFAULT NULL COMMENT 用戶頭像, phone varchar(20) DEFAULT NULL COMMENT 手機(jī)號, create_time datetime DEFAULT CURRENT_TIMESTAMP COMMENT 注冊時(shí)間, PRIMARY KEY (id), UNIQUE KEY uk_openid (openid) ) ENGINEInnoDB AUTO_INCREMENT1 DEFAULT CHARSETutf8mb4 COMMENT用戶表;-- 商品表 CREATE TABLE product ( id bigint(20) NOT NULL AUTO_INCREMENT, category_id bigint(20) NOT NULL COMMENT 所屬分類id, name varchar(128) NOT NULL COMMENT 商品名稱, main_image varchar(255) DEFAULT NULL COMMENT 商品主圖, price decimal(10, 2) NOT NULL COMMENT 銷售價(jià)格, original_price decimal(10, 2) DEFAULT NULL COMMENT 原價(jià)用于展示劃線價(jià), stock int(11) NOT NULL DEFAULT 0 COMMENT 庫存數(shù)量, sales int(11) NOT NULL DEFAULT 0 COMMENT 銷量, description text COMMENT 商品描述, status tinyint(4) NOT NULL DEFAULT 1 COMMENT 狀態(tài)1上架 0下架, create_time datetime DEFAULT CURRENT_TIMESTAMP COMMENT 創(chuàng)建時(shí)間, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新時(shí)間, PRIMARY KEY (id), KEY idx_category_id (category_id) ) ENGINEInnoDB AUTO_INCREMENT1 DEFAULT CHARSETutf8mb4 COMMENT商品表;-- 訂單表 CREATE TABLE orders ( id bigint(20) NOT NULL AUTO_INCREMENT, order_no varchar(64) NOT NULL COMMENT 訂單編號, user_id bigint(20) NOT NULL COMMENT 下單用戶id, total_amount decimal(10, 2) NOT NULL COMMENT 訂單總金額, status int(2) NOT NULL DEFAULT 0 COMMENT 訂單狀態(tài)0待付款 1待發(fā)貨 2待收貨 3已完成 4已取消, receiver_name varchar(64) DEFAULT NULL COMMENT 收貨人姓名, receiver_phone varchar(20) DEFAULT NULL COMMENT 收貨人電話, receiver_address varchar(255) DEFAULT NULL COMMENT 收貨地址, remark varchar(255) DEFAULT NULL COMMENT 訂單備注, pay_time datetime DEFAULT NULL COMMENT 支付時(shí)間, deliver_time datetime DEFAULT NULL COMMENT 發(fā)貨時(shí)間, finish_time datetime DEFAULT NULL COMMENT 完成時(shí)間, create_time datetime DEFAULT CURRENT_TIMESTAMP COMMENT 下單時(shí)間, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_user_id (user_id), KEY idx_status (status) ) ENGINEInnoDB AUTO_INCREMENT1 DEFAULT CHARSETutf8mb4 COMMENT訂單表;訂單明細(xì)表的重點(diǎn)是記錄下單那一刻的商品快照包括商品名稱、下單價(jià)格、數(shù)量。不要只存商品 id否則商品價(jià)格或名稱后續(xù)發(fā)生變化歷史訂單里的信息就會(huì)對不上。4.3 表關(guān)系說明這些表之間的關(guān)系是user與orders是一對多一個(gè)用戶可以有多個(gè)訂單orders與order_item是一對多一個(gè)訂單包含多個(gè)商品明細(xì)category與product是一對多一個(gè)分類下包含多個(gè)商品product與cart是一對多購物車?yán)锩總€(gè)商品對應(yīng)一個(gè)記錄。在論文里畫 ER 圖時(shí)把這些關(guān)系標(biāo)清楚即可。需要特別注意的是cart表的唯一鍵要設(shè)置為user_id product_id避免同一個(gè)用戶把同一個(gè)商品多次加進(jìn)購物車產(chǎn)生重復(fù)數(shù)據(jù)。5. 后端接口設(shè)計(jì)與核心代碼實(shí)現(xiàn)5.1 接口設(shè)計(jì)規(guī)范這套系統(tǒng)的后端接口按照 RESTful 風(fēng)格設(shè)計(jì)所有接口統(tǒng)一以/api開頭。小程序端接口以/api/user、/api/product、/api/cart、/api/order作為前綴管理端接口以/api/admin作為前綴便于區(qū)分和鑒權(quán)。統(tǒng)一返回結(jié)構(gòu)是后端接口設(shè)計(jì)中最容易被忽略、但實(shí)際非常重要的細(xì)節(jié)。建議定義一個(gè)統(tǒng)一的 JSON 返回體包含狀態(tài)碼、消息和數(shù)據(jù)三個(gè)字段例如{ code: 200, message: success, data: {} }前端拿到這個(gè)結(jié)構(gòu)后只需要判斷code是否等于 200 就能知道請求是否成功不需要在每個(gè)頁面各自處理異常結(jié)構(gòu)。在論文里也可以把統(tǒng)一返回結(jié)構(gòu)作為“接口設(shè)計(jì)規(guī)范”的一節(jié)來寫體現(xiàn)工程化思維。5.2 小程序端用戶登錄接口用戶登錄微信小程序端是第一個(gè)需要完成的接口。登錄流程是小程序端調(diào)用wx.login獲取臨時(shí)code把code發(fā)送給后端后端拿著code請求微信接口換取openid然后根據(jù)openid判斷用戶是否已經(jīng)存在不存在則自動(dòng)注冊最后把用戶信息返回給小程序端。// 文件路徑miniprogram/pages/login/login.js wx.login({ success: (res) { if (res.code) { wx.request({ url: http://localhost:8080/api/user/login, method: POST, data: { code: res.code }, success: (response) { const { code, data } response.data; if (code 200) { wx.setStorageSync(userInfo, data.userInfo); wx.setStorageSync(token, data.token); wx.switchTab({ url: /pages/index/index }); } } }); } } });在后端code換取openid這一步需要調(diào)用微信接口這一步通常放在 Service 層處理。Controller 層只需要接收code調(diào)用 Service返回結(jié)果即可。// 文件路徑src/main/java/com/fruit/controller/UserController.java RestController RequestMapping(/api/user) public class UserController { Autowired private UserService userService; PostMapping(/login) public Result login(RequestBody MapString, String params) { String code params.get(code); UserVO userVO userService.login(code); return Result.success(userVO); } }登錄接口完成后小程序端就可以拿到用戶信息和 token后續(xù)所有需要登錄的請求都可以在 header 中攜帶 token后端通過攔截器校驗(yàn)登錄狀態(tài)。5.3 商品列表與商品詳情接口商品模塊是小程序端的核心展示模塊。商品列表接口需要支持按分類查詢、按關(guān)鍵詞搜索、按價(jià)格排序等能力商品詳情接口返回指定商品的完整信息。// 文件路徑src/main/java/com/fruit/controller/ProductController.java RestController RequestMapping(/api/product) public class ProductController { Autowired private ProductService productService; GetMapping(/list) public Result list( RequestParam(required false) Long categoryId, RequestParam(required false) String keyword, RequestParam(defaultValue 1) Integer pageNum, RequestParam(defaultValue 10) Integer pageSize) { PageResultProductVO page productService.getProductList(categoryId, keyword, pageNum, pageSize); return Result.success(page); } GetMapping(/detail/{id}) public Result detail(PathVariable Long id) { ProductVO product productService.getProductDetail(id); return Result.success(product); } }這里比較建議使用分頁查詢而不是一次性返回所有商品。小程序首頁的商品列表數(shù)據(jù)會(huì)隨著后臺不斷添加商品而增加如果一次性全量返回首屏加載會(huì)越來越慢。分頁參數(shù)pageNum和pageSize是最常規(guī)的設(shè)計(jì)配合小程序端的onReachBottom觸底加載可以實(shí)現(xiàn)滾動(dòng)分頁效果。5.4 購物車接口與下單流程購物車接口通常包含加入購物車、查看購物車、修改數(shù)量、刪除商品四個(gè)操作。加入購物車時(shí)要判斷該用戶是否已經(jīng)加過同一商品如果已存在則把數(shù)量累加否則新增記錄。下單流程是整套系統(tǒng)邏輯最復(fù)雜的部分建議按下述步驟實(shí)現(xiàn)用戶從購物車選擇商品提交訂單后端接收商品 id 列表和收貨信息校驗(yàn)商品是否存在、是否上架、庫存是否充足計(jì)算訂單總金額生成訂單主表記錄和訂單明細(xì)記錄扣減商品庫存清空購物車中已下單的商品這里有兩個(gè)容易出錯(cuò)的地方。第一庫存扣減和訂單創(chuàng)建必須在同一個(gè)數(shù)據(jù)庫事務(wù)中完成否則會(huì)出現(xiàn)“訂單創(chuàng)建成功但庫存沒有扣減”或“庫存扣減了但訂單沒創(chuàng)建成功”的不一致問題第二計(jì)算商品價(jià)格時(shí)必須以服務(wù)端查詢到的數(shù)據(jù)庫價(jià)格為準(zhǔn)不能直接信任前端傳過來的價(jià)格否則用戶可以篡改請求數(shù)據(jù)把價(jià)格改成 0 分錢下單。// 文件路徑src/main/java/com/fruit/service/impl/OrderServiceImpl.java Override Transactional(rollbackFor Exception.class) public OrderVO createOrder(Long userId, CreateOrderRequest request) { ListLong cartIds request.getCartIds(); ListCartItem cartItems cartMapper.selectBatchIds(cartIds); if (CollectionUtils.isEmpty(cartItems)) { throw new BizException(購物車中沒有選中商品); } BigDecimal totalAmount BigDecimal.ZERO; ListOrderItem orderItems new ArrayList(); for (CartItem item : cartItems) { Product product productMapper.selectById(item.getProductId()); if (product null || product.getStatus() ! 1) { throw new BizException(商品已下架 item.getProductName()); } if (product.getStock() item.getQuantity()) { throw new BizException(庫存不足 product.getName()); } OrderItem orderItem new OrderItem(); orderItem.setProductId(product.getId()); orderItem.setProductName(product.getName()); orderItem.setProductImage(product.getMainImage()); orderItem.setPrice(product.getPrice()); orderItem.setQuantity(item.getQuantity()); orderItems.add(orderItem); totalAmount totalAmount.add(product.getPrice().multiply(new BigDecimal(item.getQuantity()))); // 扣減庫存 productMapper.decreaseStock(product.getId(), item.getQuantity()); } // 創(chuàng)建訂單主記錄 Order order new Order(); order.setOrderNo(generateOrderNo()); order.setUserId(userId); order.setTotalAmount(totalAmount); order.setStatus(0); order.setReceiverName(request.getReceiverName()); order.setReceiverPhone(request.getReceiverPhone()); order.setReceiverAddress(request.getReceiverAddress()); orderMapper.insert(order); // 插入訂單明細(xì) orderItems.forEach(item - item.setOrderId(order.getId())); orderItemMapper.insertBatch(orderItems); // 清空購物車中已下單的商品 cartMapper.deleteBatchIds(cartIds); OrderVO vo new OrderVO(); vo.setOrderNo(order.getOrderNo()); vo.setTotalAmount(totalAmount); return vo; }這段代碼里的Transactional注解是整個(gè)方法的保護(hù)傘。一旦任何一步拋出異常前面已經(jīng)執(zhí)行的數(shù)據(jù)庫操作都會(huì)回滾不會(huì)留下臟數(shù)據(jù)。5.5 管理端訂單管理接口管理端的功能主要是對數(shù)據(jù)的增刪改查。以訂單管理為例接口包括分頁查詢訂單列表、查看訂單詳情、訂單發(fā)貨、取消訂單。管理端的鑒權(quán)方式建議使用 JWT。管理員登錄成功后后端生成一個(gè)帶有效期的 token后續(xù)管理端請求在 header 中攜帶 token后端攔截器校驗(yàn) token 有效才放行。// 文件路徑src/main/java/com/fruit/interceptor/AdminAuthInterceptor.java public class AdminAuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (!StringUtils.hasText(token)) { response.setStatus(401); return false; } // 校驗(yàn) JWT token 有效性 try { Long adminId JwtUtil.parseToken(token); request.setAttribute(adminId, adminId); return true; } catch (Exception e) { response.setStatus(401); return false; } } }在 WebMvcConfig 中注冊攔截器時(shí)只需要攔截/api/admin/**路徑小程序端接口另做登錄態(tài)校驗(yàn)避免兩套鑒權(quán)邏輯互相干擾。6. 微信小程序前端實(shí)現(xiàn)要點(diǎn)6.1 小程序項(xiàng)目結(jié)構(gòu)與頁面劃分微信小程序原生開發(fā)的項(xiàng)目結(jié)構(gòu)相對固定核心是pages目錄下的頁面文件夾、app.json全局配置和app.js全局邏輯。水果店管理系統(tǒng)的前端頁面可以劃分為pages/index/index首頁展示分類導(dǎo)航和商品列表pages/category/category分類頁按水果分類瀏覽商品pages/cart/cart購物車頁pages/order/order訂單列表頁pages/order/orderDetail訂單詳情頁pages/pay/pay確認(rèn)訂單和支付頁pages/user/user個(gè)人中心在app.json中可以配置底部 TabBar把首頁、分類、購物車、個(gè)人中心四個(gè)核心頁面放在底部導(dǎo)航。TabBar 是微信小程序里比較能提升“系統(tǒng)感”的功能能讓界面看起來更像完整的應(yīng)用。6.2 小程序調(diào)用后端接口的封裝小程序端請求后端接口時(shí)建議不要在每個(gè)頁面直接寫wx.request而是封裝一個(gè)統(tǒng)一的請求工具。這樣可以統(tǒng)一處理 baseURL、token 注入、錯(cuò)誤提示和登錄過期跳轉(zhuǎn)。// 文件路徑miniprogram/utils/request.js const BASE_URL http://localhost:8080; function request(url, method GET, data {}) { return new Promise((resolve, reject) { const token wx.getStorageSync(token); wx.request({ url: BASE_URL url, method: method, data: data, header: { Content-Type: application/json, Authorization: token ? Bearer ${token} : }, success: (res) { if (res.data.code 200) { resolve(res.data.data); } else if (res.data.code 401) { wx.showToast({ title: 登錄已過期, icon: none }); wx.navigateTo({ url: /pages/login/login }); } else { wx.showToast({ title: res.data.message || 請求失敗, icon: none }); reject(res.data); } }, fail: (err) { wx.showToast({ title: 網(wǎng)絡(luò)異常, icon: none }); reject(err); } }); }); } module.exports { request };封裝完成后頁面里調(diào)用接口就很簡單const { request } require(../../utils/request); request(/api/product/list?pageNum1pageSize10).then((data) { this.setData({ productList: data.list }); });這種封裝的好處是如果后端的 baseURL 變了只需要改request.js一個(gè)文件如果未來要接入登錄鑒權(quán)也只需要在request.js里統(tǒng)一處理 header。6.3 購物車頁面注意事項(xiàng)購物車頁面是小程序端交互邏輯最重的頁面。它需要支持勾選商品、修改數(shù)量、實(shí)時(shí)計(jì)算總價(jià)、刪除商品還要在左下角展示“合計(jì)xx 元”并在右下角提供“結(jié)算”按鈕。這里需要特別注意兩點(diǎn)。第一小程序的數(shù)據(jù)綁定是單向的修改數(shù)量之后必須手動(dòng)調(diào)用this.setData重新渲染頁面同時(shí)重新計(jì)算總價(jià)。第二購物車勾選狀態(tài)要使用商品 id 做標(biāo)識不要簡單地用數(shù)組索引否則刪除中間項(xiàng)后勾選狀態(tài)會(huì)錯(cuò)亂。購物車的數(shù)據(jù)建議在onShow生命周期中重新拉取而不是在onLoad中只加載一次。因?yàn)橛脩艨赡軓纳唐吩斍轫撛俅渭尤肷唐泛蠓祷刭徫镘嚧藭r(shí)需要展示最新的購物車數(shù)據(jù)onShow每次進(jìn)入頁面都會(huì)觸發(fā)能保證數(shù)據(jù)的一致性。6.4 訂單列表下拉刷新與觸底加載訂單列表頁建議使用enablePullDownRefresh開啟下拉刷新配合onReachBottom實(shí)現(xiàn)觸底分頁加載。這兩個(gè)能力是微信小程序內(nèi)置的頁面事件只需要在頁面的.json配置文件中設(shè)置{ enablePullDownRefresh: true, backgroundTextStyle: dark }然后在頁面的 js 中對應(yīng)實(shí)現(xiàn)onPullDownRefresh和onReachBottom方法。下拉刷新時(shí)重置pageNum為 1重新加載第一頁數(shù)據(jù)并替換列表觸底時(shí)pageNum加 1把新數(shù)據(jù)追加到列表末尾同時(shí)判斷返回的total是否大于當(dāng)前已加載條數(shù)決定是否還有下一頁。7. 運(yùn)行驗(yàn)證與聯(lián)調(diào)排錯(cuò)7.1 本地啟動(dòng)完整流程這套系統(tǒng)在本地開發(fā)時(shí)建議按以下順序啟動(dòng)啟動(dòng) MySQL執(zhí)行數(shù)據(jù)庫初始化腳本創(chuàng)建數(shù)據(jù)庫和表結(jié)構(gòu)修改后端application.yml中的數(shù)據(jù)庫賬號密碼啟動(dòng) Spring Boot 服務(wù)使用微信開發(fā)者工具導(dǎo)入小程序項(xiàng)目目錄修改request.js中的 baseURL 為http://localhost:8080在微信開發(fā)者工具的“詳情 - 本地設(shè)置”中勾選“不校驗(yàn)合法域名…”編譯運(yùn)行小程序完成注冊登錄、商品瀏覽、下單全流程這一步最常見的坑是端口被占用或數(shù)據(jù)庫連接失敗?？梢栽诤蠖藛?dòng)信息中查看是否打印Tomcat started on port(s): 8080如果端口被占用修改server.port即可如果數(shù)據(jù)庫連接失敗優(yōu)先檢查 MySQL 服務(wù)是否啟動(dòng)、賬號密碼是否正確、spring.datasource.url中的庫名是否存在。7.2 使用 Postman 驗(yàn)證后端接口小程序端調(diào)試不太方便時(shí)可以用 Postman 或 Apifox 直接調(diào)用后端接口。驗(yàn)證商品列表接口GET http://localhost:8080/api/product/list?pageNum1pageSize10驗(yàn)證管理員登錄接口在 Body 中傳 JSON{ username: admin, password: 123456 }登錄成功后返回 token在后續(xù)管理端請求的 header 中加上Authorization: Bearer 剛才返回的token即可訪問需要管理員權(quán)限的接口。先用 Postman 把接口調(diào)通再去小程序端聯(lián)調(diào)可以顯著減少排查問題的范圍。7.3 聯(lián)調(diào)失敗排查順序聯(lián)調(diào)最典型的問題是小程序端請求后端不成功。這里給一個(gè)固定的排查順序先看后端控制臺有沒有收到請求日志再看數(shù)據(jù)庫有沒有對應(yīng)的數(shù)據(jù)最后看小程序控制臺報(bào)什么錯(cuò)誤。如果后端沒有收到請求大概率是 baseURL 配錯(cuò)或真機(jī)調(diào)試時(shí)填了 localhost真機(jī)上 localhost 指向手機(jī)本身不是電腦應(yīng)該改為電腦的局域網(wǎng) IP如果后端收到了請求但數(shù)據(jù)庫沒有數(shù)據(jù)優(yōu)先檢查 SQL 是否執(zhí)行成功、事務(wù)是否回滾如果小程序端報(bào)錯(cuò)把錯(cuò)誤信息完整貼出來搜索基本都能找到答案。8. 常見問題與避坑清單問題現(xiàn)象可能原因排查方式解決方案小程序請求后端超時(shí)baseURL 使用 localhost 或端口錯(cuò)誤查看后端控制臺有無請求日志開發(fā)者工具改用 127.0.0.1真機(jī)調(diào)試改用局域網(wǎng) IP登錄后用戶信息為空微信登錄 code 換取 openid 失敗查看后端日志中微信接口響應(yīng)確認(rèn)小程序 AppID 是否填寫正確后端 appid/secret 是否匹配提交訂單時(shí)庫存沒有變化下單邏輯沒有開啟事務(wù)檢查方法上是否有 Transactional添加上事務(wù)注解并開啟事務(wù)管理商品列表無法觸底加載沒有正確處理分頁參數(shù)查看網(wǎng)絡(luò)請求中的 pageNum 是否遞增在 onReachBottom 中 pageNum 自增并追加數(shù)據(jù)管理端接口提示 401token 未攜帶或已過期檢查請求 header 是否帶 Authorization在請求工具中統(tǒng)一注入 token中文亂碼數(shù)據(jù)庫連接 URL 缺少編碼參數(shù)查看數(shù)據(jù)庫字符集在 JDBC URL 后添加 useUnicodetruecharacterEncodingutf88.1 事務(wù)回滾不生效Spring Boot 中使用Transactional注解時(shí)有一個(gè)比較隱蔽的坑如果方法內(nèi)部直接 catch 住異常并且沒有重新拋出事務(wù)就會(huì)正常提交而不是回滾。在寫下單邏輯時(shí)不要在方法里統(tǒng)一 catch 所有異常然后返回錯(cuò)誤信息而是拋出業(yè)務(wù)異常讓事務(wù)管理器統(tǒng)一處理回滾在 Controller 層再做異常捕獲。8.2 價(jià)格計(jì)算用浮點(diǎn)類型Java 中float和double在做金額運(yùn)算時(shí)會(huì)出現(xiàn)精度丟失問題。例如0.1 0.2在二進(jìn)制浮點(diǎn)數(shù)中并不等于0.3。訂單金額相關(guān)字段一定要使用BigDecimal數(shù)據(jù)庫使用decimal(10,2)。在代碼示例中沒有直接演示金額累加但實(shí)際開發(fā)時(shí)所有金額計(jì)算都要用BigDecimal千萬不要用double做加法。8.3 上線部署與合法域名如果這套系統(tǒng)要部署到真實(shí)環(huán)境微信小程序上線有一個(gè)關(guān)鍵要求所有請求的域名必須是 HTTPS 且已經(jīng)在微信公眾平臺配置為合法的 request 合法域名。個(gè)人開發(fā)者在本地測試時(shí)可以使用“不校驗(yàn)合法域名”開關(guān)但正式發(fā)布前必須準(zhǔn)備 HTTPS 域名并完成 ICP 備案。這一點(diǎn)在論文的“系統(tǒng)部署”章節(jié)中可以如實(shí)說明但實(shí)際操作時(shí)要留足時(shí)間。9. 畢業(yè)設(shè)計(jì)論文結(jié)構(gòu)與答辯準(zhǔn)備9.1 論文章節(jié)建議畢業(yè)設(shè)計(jì)論文的結(jié)構(gòu)各校要求不同但核心章節(jié)大同小異。以這套水果店管理系統(tǒng)為例論文目錄可以按下述結(jié)構(gòu)組織緒論研究背景與意義、國內(nèi)外研究現(xiàn)狀、論文組織結(jié)構(gòu)相關(guān)技術(shù)介紹微信小程序、Spring Boot、MySQL、MyBatis系統(tǒng)分析可行性分析、需求分析功能性需求和非功能性需求、用例分析系統(tǒng)設(shè)計(jì)總體架構(gòu)設(shè)計(jì)、功能模塊設(shè)計(jì)、數(shù)據(jù)庫設(shè)計(jì)、接口設(shè)計(jì)系統(tǒng)實(shí)現(xiàn)按功能模塊分別描述實(shí)現(xiàn)過程配合核心代碼和運(yùn)行截圖系統(tǒng)測試測試環(huán)境、功能測試用例、測試結(jié)果分析總結(jié)與展望每一章的寫作邏輯是“先把場景和問題描述清楚再說明采用了什么方案最后貼出結(jié)果證明有效”。代碼不要大段整段地貼只摘錄關(guān)鍵方法并附簡短說明更有論文感。9.2 答辯常見追問答辯老師一般不會(huì)為難學(xué)生但很可能會(huì)圍繞系統(tǒng)實(shí)際實(shí)現(xiàn)細(xì)節(jié)展開提問。以下幾個(gè)問題是水果店管理系統(tǒng)最高頻的追問方向購物車加同一商品時(shí)是新增記錄還是數(shù)量累加為什么提交訂單時(shí)如何保證庫存不會(huì)超賣代碼中是怎么實(shí)現(xiàn)的微信登錄的完整流程是什么code 換 openid 這一步發(fā)生在哪里用戶和管理員是否共用同一套登錄邏輯權(quán)限是如何隔離的如果用戶同時(shí)下單導(dǎo)致庫存扣減沖突系統(tǒng)會(huì)怎樣處理對于最后一個(gè)問題如果項(xiàng)目只做了基本的庫存校驗(yàn)可以回答當(dāng)前的實(shí)現(xiàn)方案是“查詢庫存 - 判斷充足 - 扣減庫存”在單機(jī)低并發(fā)場景下可以正常工作然后補(bǔ)充一句如果要應(yīng)對更高并發(fā)可以使用數(shù)據(jù)庫行鎖或樂觀鎖機(jī)制這是后續(xù)優(yōu)化方向。這樣既如實(shí)說明了當(dāng)前實(shí)現(xiàn)又展示了對擴(kuò)展性的思考是一個(gè)比較穩(wěn)妥的回答策略。9.3 演示時(shí)注意演示節(jié)奏答辯演示環(huán)節(jié)建議提前準(zhǔn)備一份“演示腳本”按順序展示核心功能管理員登錄后先添加一個(gè)水果商品然后在用戶端小程序刷新查看新商品加入購物車提交訂單再回到管理端看到訂單并執(zhí)行發(fā)貨操作。這個(gè)流程約 3 到 5 分鐘覆蓋了系統(tǒng)的全部核心鏈路比零散地點(diǎn)擊各個(gè)頁面更能在短時(shí)間內(nèi)讓評審老師建立完整印象。演示前確認(rèn)網(wǎng)絡(luò)通暢、后端服務(wù)和數(shù)據(jù)庫均已啟動(dòng)這是最基礎(chǔ)但也是最容易被忽略的準(zhǔn)備。10. 總結(jié)與后續(xù)優(yōu)化方向微信小程序水果店管理系統(tǒng)這個(gè)題目看起來并不炫酷但它的工程完整度和可擴(kuò)展性恰恰是畢業(yè)設(shè)計(jì)最看重的。從用戶端到管理端從購物車到訂單事務(wù)從數(shù)據(jù)庫設(shè)計(jì)到接口鑒權(quán)每一個(gè)環(huán)節(jié)都是真實(shí)業(yè)務(wù)系統(tǒng)的縮影。做好這套系統(tǒng)你掌握的并不是某一段代碼而是“把一個(gè)實(shí)際業(yè)務(wù)拆解成需求、設(shè)計(jì)、編碼、測試、文檔”的完整方法這種能力在后續(xù)的工作和項(xiàng)目實(shí)踐中會(huì)持續(xù)復(fù)用。如果做完基礎(chǔ)功能后還有余力可以從三個(gè)方向繼續(xù)深化。第一接入微信支付把模擬支付替換為真實(shí)支付鏈路但這需要企業(yè)主體的小程序賬號個(gè)人開發(fā)者只能作為論文中的理論設(shè)計(jì)。第二加入數(shù)據(jù)可視化圖表在后端定時(shí)統(tǒng)計(jì)每日銷售額和熱銷商品用 ECharts 在管理端展示趨勢圖這是一個(gè)明顯的加分項(xiàng)。第三在訂單模塊引入樂觀鎖或 Redis 預(yù)扣庫存方案驗(yàn)證高并發(fā)場景下的庫存一致性把系統(tǒng)從“能跑”推向“抗打”。如果你是正在做這道題的學(xué)生建議先把這篇文中的核心流程逐個(gè)跑通再結(jié)合自己的理解去擴(kuò)展。代碼可以復(fù)用但數(shù)據(jù)庫字段是否合理、接口是否健壯、論文中的技術(shù)表述是否準(zhǔn)確需要你親自檢查。把這些事情做扎實(shí)畢業(yè)設(shè)計(jì)不僅是一份作業(yè)也會(huì)成為你簡歷上可以坦然寫出的一項(xiàng)完整項(xiàng)目經(jīng)歷。