很多準(zhǔn)備畢業(yè)設(shè)計的同學(xué)看到“微信小程序 管理系統(tǒng)”這類題目第一反應(yīng)往往是這個方向是不是太普通了會不會和別人撞題但真正動手之后才會意識到這類題目能成為畢業(yè)設(shè)計里的常青樹恰恰是因為它把移動端、服務(wù)端、數(shù)據(jù)庫、權(quán)限控制、訂單流程和論文撰寫全部串在了一條完整的鏈路上任何一個環(huán)節(jié)偷懶都會在答辯時暴露。水果店管理系統(tǒng)就是這個方向里非常有代表性的一個業(yè)務(wù)規(guī)則清楚、角色劃分明確、數(shù)據(jù)流完整既不會難到做不出來又足夠撐起一篇內(nèi)容扎實的論文。這篇文章不會只貼代碼而是會從選題價值、系統(tǒng)架構(gòu)、數(shù)據(jù)庫設(shè)計、前后端實現(xiàn)、聯(lián)調(diào)驗證、論文寫作到答辯準(zhǔn)備把這套“微信小程序水果店管理系統(tǒng)”完整拆開講清楚。無論你是正在選畢業(yè)設(shè)計題目還是已經(jīng)在做同類管理系統(tǒng)這篇文章都可以作為一個可以直接復(fù)用的實戰(zhàn)模板。1. 這類畢業(yè)設(shè)計項目為什么值得做很多同學(xué)選畢業(yè)設(shè)計題目時會在“太簡單怕過不了”和“太難怕完不成”之間反復(fù)糾結(jié)。信息管理系統(tǒng)方向之所以常年被推薦是因為它處在一個很合適的位置開發(fā)難度適中但工程鏈路完整。以水果店管理系統(tǒng)為例它天然具備幾個非常適合畢業(yè)設(shè)計的特征。第一業(yè)務(wù)場景足夠生活化水果店是大家熟悉的零售場景需求不需要額外解釋評審老師一眼就能看懂第二業(yè)務(wù)鏈條完整從用戶注冊登錄、瀏覽商品、加入購物車、下單支付到管理員管理商品、處理訂單、發(fā)布公告整個流程覆蓋了典型的電商業(yè)務(wù)閉環(huán)第三技術(shù)棧選擇空間大前端可以用微信小程序原生開發(fā)也可以使用 uni-app后端可以用 Spring Boot、SSM 甚至 Node.js數(shù)據(jù)庫可以用 MySQL每一種選擇都有大量的社區(qū)資料可以參考。這個選題還有一個容易被忽略的優(yōu)勢它非常適合展示“從需求到交付”的完整過程。畢業(yè)設(shè)計評分的核心不只是代碼能不能跑而是你有沒有把需求分析、數(shù)據(jù)庫設(shè)計、接口定義、前后端聯(lián)調(diào)、系統(tǒng)測試這些環(huán)節(jié)說清楚。水果店管理系統(tǒng)的業(yè)務(wù)規(guī)模不大不小剛好可以把這些環(huán)節(jié)全部走一遍不會因為業(yè)務(wù)過于復(fù)雜導(dǎo)致說不清楚也不會因為業(yè)務(wù)太簡單導(dǎo)致無話可寫。如果你正在糾結(jié)選題這套系統(tǒng)的價值在于它既能讓你在開發(fā)過程中學(xué)到完整的工程實踐又能在論文寫作時有足夠的內(nèi)容支撐屬于那種“做著不痛苦、寫論文有素材、答辯不心虛”的題目。2. 系統(tǒng)整體架構(gòu)與技術(shù)選型2.1 三層架構(gòu)設(shè)計這套水果店管理系統(tǒng)從物理結(jié)構(gòu)上分為三個部分微信小程序客戶端、后端服務(wù)、管理后臺。三者之間通過 HTTP 接口通信數(shù)據(jù)統(tǒng)一存儲在 MySQL 中。用戶端是微信小程序消費者通過微信掃碼或搜索進入小程序完成注冊登錄、瀏覽商品、加入購物車、提交訂單、訂單支付、查看個人訂單等操作。管理端是給水果店老板或店員使用的后臺頁面負責(zé)商品上下架、庫存管理、訂單處理、公告發(fā)布、用戶管理等操作。后端服務(wù)是整個系統(tǒng)的中樞既要為小程序提供用戶相關(guān)的接口也要為管理后臺提供運營相關(guān)的接口同時還要處理登錄鑒權(quán)、訂單狀態(tài)流轉(zhuǎn)、數(shù)據(jù)統(tǒng)計等核心業(yè)務(wù)邏輯。這種架構(gòu)在畢業(yè)設(shè)計中是性價比最高的選擇。它比單純的“網(wǎng)頁 數(shù)據(jù)庫”更貼近真實的移動互聯(lián)網(wǎng)應(yīng)用形態(tài)又不像大型分布式系統(tǒng)那樣難以駕馭。2.2 技術(shù)棧選擇與理由這套系統(tǒng)在技術(shù)選型上有一個清晰的原則每一項技術(shù)都選擇資料最豐富、問題排查最容易的方案。層次技術(shù)選型選擇理由小程序端微信小程序原生框架組件和 API 官方文檔完善無需額外構(gòu)建工具調(diào)試方便管理端Vue Element UI 或 Thymeleaf如果是前后端分離Vue 更靈活如果想控制工作量服務(wù)端渲染更簡單后端Spring Boot自動配置減少大量 XML 配置內(nèi)置 Tomcat適合快速開發(fā)數(shù)據(jù)庫MySQL開源穩(wěn)定主流教程多支持事務(wù)適合訂單類業(yè)務(wù)ORMMyBatis 或 MyBatis-Plus手寫 SQL 可控性強MyBatis-Plus 能減少重復(fù)代碼鑒權(quán)方案JWT 或微信登錄態(tài) session小程序場景下微信登錄是標(biāo)配JWT 適合管理端接口鑒權(quán)從實際開發(fā)的角度看Spring Boot MyBatis MySQL 微信小程序原生這套組合是資料最全、踩坑最少的方案。網(wǎng)上關(guān)于這套技術(shù)棧的教程數(shù)量巨大遇到問題幾乎都能搜到對應(yīng)的解決方案對于時間有限的畢業(yè)生來說這本身就是巨大的優(yōu)勢。2.3 為什么不用更復(fù)雜的技術(shù)有些同學(xué)為了讓選題顯得“高級”會在系統(tǒng)里引入 Redis 緩存、消息隊列、微服務(wù)等組件。這里給一個比較直接的建議如果這是畢業(yè)設(shè)計而不是大廠生產(chǎn)項目不要為了堆技術(shù)而堆技術(shù)。水果店管理系統(tǒng)的并發(fā)量和使用規(guī)模用 Spring Boot 單機部署完全足夠。技術(shù)選型好不好不是看用了多少新技術(shù)而是看每一項技術(shù)是否解決了實際問題。如果論文里寫了 Redis 緩存那么答辯老師問你緩存穿透、緩存雪崩怎么處理你需要答得上來如果寫了消息隊列那么你要能說清楚削峰填谷在這個系統(tǒng)里到底解決了什么具體問題。這些追問如果答不上來反而會變成扣分點。當(dāng)然如果你確實熟悉這些技術(shù)在論文里作為“擴展與優(yōu)化方向”提一下會是加分項。3. 核心功能設(shè)計與角色劃分3.1 用戶角色與需求分析水果店管理系統(tǒng)涉及兩類使用者需求截然不同。普通用戶消費者關(guān)注的是購買體驗?zāi)懿荒芸焖僬业较胭I的水果能不能看到清晰的圖片和價格購物車好不好用下單流程是否順暢能不能查到自己的歷史訂單。在小程序端需要實現(xiàn)的用戶功能包括微信登錄和手機號綁定、水果分類瀏覽與商品搜索、商品詳情查看、加入購物車、購物車數(shù)量修改、提交訂單、訂單支付或模擬支付、訂單狀態(tài)查詢、個人中心信息管理。管理員關(guān)注的是運營效率哪些商品賣得好需要補貨哪些商品庫存不足訂單處理到哪一步了今天營業(yè)額是多少。在管理端需要實現(xiàn)的功能包括管理員登錄與權(quán)限校驗、商品分類管理、商品信息管理新增、編輯、上下架、庫存調(diào)整、訂單管理訂單查詢、發(fā)貨、完成、取消、公告管理、用戶管理、基礎(chǔ)數(shù)據(jù)統(tǒng)計。從需求分析的角度這兩類角色已經(jīng)覆蓋了“用戶端 管理端”的完整業(yè)務(wù)閉環(huán)論文里寫“系統(tǒng)分析”章節(jié)時用例圖和用例說明都有充足素材。3.2 功能模塊劃分整個系統(tǒng)的功能模塊可以做如下劃分模塊所屬端核心功能用戶模塊小程序端微信登錄、用戶信息維護商品模塊小程序端 管理端商品分類、商品列表、商品詳情、商品管理購物車模塊小程序端加入購物車、修改數(shù)量、刪除、清空訂單模塊小程序端 管理端提交訂單、訂單狀態(tài)流轉(zhuǎn)、訂單管理公告模塊小程序端 管理端公告列表、公告詳情、公告發(fā)布統(tǒng)計模塊管理端商品銷量統(tǒng)計、訂單金額統(tǒng)計這種模塊劃分在論文寫作時非常友好每個模塊都可以寫一段功能描述對應(yīng)一張界面截圖或接口說明工作量清晰可見。3.3 訂單狀態(tài)設(shè)計訂單是整個管理系統(tǒng)的核心狀態(tài)設(shè)計是否合理會直接影響開發(fā)的復(fù)雜度和論文的深度。建議把訂單狀態(tài)設(shè)計為以下幾個階段待付款用戶提交訂單但尚未支付待發(fā)貨用戶完成支付商家需要準(zhǔn)備水果待收貨商家確認發(fā)貨水果在配送路上已完成用戶確認收貨訂單正常結(jié)束已取消用戶或管理員取消訂單在數(shù)據(jù)庫里訂單狀態(tài)字段可以用int類型存儲如 0、1、2、3、4也可以使用varchar存儲狀態(tài)名稱。從可讀性考慮建議使用數(shù)字枚舉在代碼和論文中定義好狀態(tài)常量前端再根據(jù)數(shù)字映射中文提示。這一點在后端接口設(shè)計部分會給出代碼示例。4. 數(shù)據(jù)庫表結(jié)構(gòu)設(shè)計4.1 設(shè)計原則數(shù)據(jù)庫設(shè)計是畢業(yè)設(shè)計論文里最容易拿分也最容易出錯的部分。水果店管理系統(tǒng)的核心表可以控制在 8 張以內(nèi)每張表的字段命名要規(guī)范類型選擇要合理外鍵關(guān)系要在 ER 圖中體現(xiàn)清楚。一個比較穩(wěn)妥的設(shè)計是包含以下數(shù)據(jù)表user用戶表存儲小程序用戶信息category商品分類表product商品表存儲水果的名稱、圖片、價格、庫存、描述等cart購物車表orders訂單表存儲用戶下單信息order_item訂單明細表存儲訂單中包含的商品明細announcement公告表admin管理員表4.2 核心表結(jié)構(gòu)示例下面給出三張核心表的建表 SQL可以直接在 MySQL 中執(zhí)行。表名字段使用下劃線命名主鍵統(tǒng)一使用id時間字段統(tǒng)一使用datetime金額字段使用decimal(10, 2)這些細節(jié)在論文中都會被評審老師注意到。-- 用戶表 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 手機號, create_time datetime DEFAULT CURRENT_TIMESTAMP COMMENT 注冊時間, 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 銷售價格, original_price decimal(10, 2) DEFAULT NULL COMMENT 原價用于展示劃線價, 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)建時間, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新時間, 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 支付時間, deliver_time datetime DEFAULT NULL COMMENT 發(fā)貨時間, finish_time datetime DEFAULT NULL COMMENT 完成時間, create_time datetime DEFAULT CURRENT_TIMESTAMP COMMENT 下單時間, 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訂單表;訂單明細表的重點是記錄下單那一刻的商品快照包括商品名稱、下單價格、數(shù)量。不要只存商品 id否則商品價格或名稱后續(xù)發(fā)生變化歷史訂單里的信息就會對不上。4.3 表關(guān)系說明這些表之間的關(guān)系是user與orders是一對多一個用戶可以有多個訂單orders與order_item是一對多一個訂單包含多個商品明細category與product是一對多一個分類下包含多個商品product與cart是一對多購物車?yán)锩總€商品對應(yīng)一個記錄。在論文里畫 ER 圖時把這些關(guān)系標(biāo)清楚即可。需要特別注意的是cart表的唯一鍵要設(shè)置為user_id product_id避免同一個用戶把同一個商品多次加進購物車產(chǎn)生重復(fù)數(shù)據(jù)。5. 后端接口設(shè)計與核心代碼實現(xiàn)5.1 接口設(shè)計規(guī)范這套系統(tǒng)的后端接口按照 RESTful 風(fēng)格設(shè)計所有接口統(tǒng)一以/api開頭。小程序端接口以/api/user、/api/product、/api/cart、/api/order作為前綴管理端接口以/api/admin作為前綴便于區(qū)分和鑒權(quán)。統(tǒng)一返回結(jié)構(gòu)是后端接口設(shè)計中最容易被忽略、但實際非常重要的細節(jié)。建議定義一個統(tǒng)一的 JSON 返回體包含狀態(tài)碼、消息和數(shù)據(jù)三個字段例如{ code: 200, message: success, data: {} }前端拿到這個結(jié)構(gòu)后只需要判斷code是否等于 200 就能知道請求是否成功不需要在每個頁面各自處理異常結(jié)構(gòu)。在論文里也可以把統(tǒng)一返回結(jié)構(gòu)作為“接口設(shè)計規(guī)范”的一節(jié)來寫體現(xiàn)工程化思維。5.2 小程序端用戶登錄接口用戶登錄微信小程序端是第一個需要完成的接口。登錄流程是小程序端調(diào)用wx.login獲取臨時code把code發(fā)送給后端后端拿著code請求微信接口換取openid然后根據(jù)openid判斷用戶是否已經(jī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后端通過攔截器校驗登錄狀態(tài)。5.3 商品列表與商品詳情接口商品模塊是小程序端的核心展示模塊。商品列表接口需要支持按分類查詢、按關(guān)鍵詞搜索、按價格排序等能力商品詳情接口返回指定商品的完整信息。// 文件路徑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ù)會隨著后臺不斷添加商品而增加如果一次性全量返回首屏加載會越來越慢。分頁參數(shù)pageNum和pageSize是最常規(guī)的設(shè)計配合小程序端的onReachBottom觸底加載可以實現(xiàn)滾動分頁效果。5.4 購物車接口與下單流程購物車接口通常包含加入購物車、查看購物車、修改數(shù)量、刪除商品四個操作。加入購物車時要判斷該用戶是否已經(jīng)加過同一商品如果已存在則把數(shù)量累加否則新增記錄。下單流程是整套系統(tǒng)邏輯最復(fù)雜的部分建議按下述步驟實現(xiàn)用戶從購物車選擇商品提交訂單后端接收商品 id 列表和收貨信息校驗商品是否存在、是否上架、庫存是否充足計算訂單總金額生成訂單主表記錄和訂單明細記錄扣減商品庫存清空購物車中已下單的商品這里有兩個容易出錯的地方。第一庫存扣減和訂單創(chuàng)建必須在同一個數(shù)據(jù)庫事務(wù)中完成否則會出現(xiàn)“訂單創(chuàng)建成功但庫存沒有扣減”或“庫存扣減了但訂單沒創(chuàng)建成功”的不一致問題第二計算商品價格時必須以服務(wù)端查詢到的數(shù)據(jù)庫價格為準(zhǔn)不能直接信任前端傳過來的價格否則用戶可以篡改請求數(shù)據(jù)把價格改成 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); // 插入訂單明細 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注解是整個方法的保護傘。一旦任何一步拋出異常前面已經(jīng)執(zhí)行的數(shù)據(jù)庫操作都會回滾不會留下臟數(shù)據(jù)。5.5 管理端訂單管理接口管理端的功能主要是對數(shù)據(jù)的增刪改查。以訂單管理為例接口包括分頁查詢訂單列表、查看訂單詳情、訂單發(fā)貨、取消訂單。管理端的鑒權(quán)方式建議使用 JWT。管理員登錄成功后后端生成一個帶有效期的 token后續(xù)管理端請求在 header 中攜帶 token后端攔截器校驗 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; } // 校驗 JWT token 有效性 try { Long adminId JwtUtil.parseToken(token); request.setAttribute(adminId, adminId); return true; } catch (Exception e) { response.setStatus(401); return false; } } }在 WebMvcConfig 中注冊攔截器時只需要攔截/api/admin/**路徑小程序端接口另做登錄態(tài)校驗避免兩套鑒權(quán)邏輯互相干擾。6. 微信小程序前端實現(xiàn)要點6.1 小程序項目結(jié)構(gòu)與頁面劃分微信小程序原生開發(fā)的項目結(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確認訂單和支付頁pages/user/user個人中心在app.json中可以配置底部 TabBar把首頁、分類、購物車、個人中心四個核心頁面放在底部導(dǎo)航。TabBar 是微信小程序里比較能提升“系統(tǒng)感”的功能能讓界面看起來更像完整的應(yīng)用。6.2 小程序調(diào)用后端接口的封裝小程序端請求后端接口時建議不要在每個頁面直接寫wx.request而是封裝一個統(tǒng)一的請求工具。這樣可以統(tǒng)一處理 baseURL、token 注入、錯誤提示和登錄過期跳轉(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一個文件如果未來要接入登錄鑒權(quán)也只需要在request.js里統(tǒng)一處理 header。6.3 購物車頁面注意事項購物車頁面是小程序端交互邏輯最重的頁面。它需要支持勾選商品、修改數(shù)量、實時計算總價、刪除商品還要在左下角展示“合計xx 元”并在右下角提供“結(jié)算”按鈕。這里需要特別注意兩點。第一小程序的數(shù)據(jù)綁定是單向的修改數(shù)量之后必須手動調(diào)用this.setData重新渲染頁面同時重新計算總價。第二購物車勾選狀態(tài)要使用商品 id 做標(biāo)識不要簡單地用數(shù)組索引否則刪除中間項后勾選狀態(tài)會錯亂。購物車的數(shù)據(jù)建議在onShow生命周期中重新拉取而不是在onLoad中只加載一次。因為用戶可能從商品詳情頁再次加入商品后返回購物車此時需要展示最新的購物車數(shù)據(jù)onShow每次進入頁面都會觸發(fā)能保證數(shù)據(jù)的一致性。6.4 訂單列表下拉刷新與觸底加載訂單列表頁建議使用enablePullDownRefresh開啟下拉刷新配合onReachBottom實現(xiàn)觸底分頁加載。這兩個能力是微信小程序內(nèi)置的頁面事件只需要在頁面的.json配置文件中設(shè)置{ enablePullDownRefresh: true, backgroundTextStyle: dark }然后在頁面的 js 中對應(yīng)實現(xiàn)onPullDownRefresh和onReachBottom方法。下拉刷新時重置pageNum為 1重新加載第一頁數(shù)據(jù)并替換列表觸底時pageNum加 1把新數(shù)據(jù)追加到列表末尾同時判斷返回的total是否大于當(dāng)前已加載條數(shù)決定是否還有下一頁。7. 運行驗證與聯(lián)調(diào)排錯7.1 本地啟動完整流程這套系統(tǒng)在本地開發(fā)時建議按以下順序啟動啟動 MySQL執(zhí)行數(shù)據(jù)庫初始化腳本創(chuàng)建數(shù)據(jù)庫和表結(jié)構(gòu)修改后端application.yml中的數(shù)據(jù)庫賬號密碼啟動 Spring Boot 服務(wù)使用微信開發(fā)者工具導(dǎo)入小程序項目目錄修改request.js中的 baseURL 為http://localhost:8080在微信開發(fā)者工具的“詳情 - 本地設(shè)置”中勾選“不校驗合法域名…”編譯運行小程序完成注冊登錄、商品瀏覽、下單全流程這一步最常見的坑是端口被占用或數(shù)據(jù)庫連接失敗?？梢栽诤蠖藛有畔⒅胁榭词欠翊蛴omcat started on port(s): 8080如果端口被占用修改server.port即可如果數(shù)據(jù)庫連接失敗優(yōu)先檢查 MySQL 服務(wù)是否啟動、賬號密碼是否正確、spring.datasource.url中的庫名是否存在。7.2 使用 Postman 驗證后端接口小程序端調(diào)試不太方便時可以用 Postman 或 Apifox 直接調(diào)用后端接口。驗證商品列表接口GET http://localhost:8080/api/product/list?pageNum1pageSize10驗證管理員登錄接口在 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)最典型的問題是小程序端請求后端不成功。這里給一個固定的排查順序先看后端控制臺有沒有收到請求日志再看數(shù)據(jù)庫有沒有對應(yīng)的數(shù)據(jù)最后看小程序控制臺報什么錯誤。如果后端沒有收到請求大概率是 baseURL 配錯或真機調(diào)試時填了 localhost真機上 localhost 指向手機本身不是電腦應(yīng)該改為電腦的局域網(wǎng) IP如果后端收到了請求但數(shù)據(jù)庫沒有數(shù)據(jù)優(yōu)先檢查 SQL 是否執(zhí)行成功、事務(wù)是否回滾如果小程序端報錯把錯誤信息完整貼出來搜索基本都能找到答案。8. 常見問題與避坑清單問題現(xiàn)象可能原因排查方式解決方案小程序請求后端超時baseURL 使用 localhost 或端口錯誤查看后端控制臺有無請求日志開發(fā)者工具改用 127.0.0.1真機調(diào)試改用局域網(wǎng) IP登錄后用戶信息為空微信登錄 code 換取 openid 失敗查看后端日志中微信接口響應(yīng)確認小程序 AppID 是否填寫正確后端 appid/secret 是否匹配提交訂單時庫存沒有變化下單邏輯沒有開啟事務(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注解時有一個比較隱蔽的坑如果方法內(nèi)部直接 catch 住異常并且沒有重新拋出事務(wù)就會正常提交而不是回滾。在寫下單邏輯時不要在方法里統(tǒng)一 catch 所有異常然后返回錯誤信息而是拋出業(yè)務(wù)異常讓事務(wù)管理器統(tǒng)一處理回滾在 Controller 層再做異常捕獲。8.2 價格計算用浮點類型Java 中float和double在做金額運算時會出現(xiàn)精度丟失問題。例如0.1 0.2在二進制浮點數(shù)中并不等于0.3。訂單金額相關(guān)字段一定要使用BigDecimal數(shù)據(jù)庫使用decimal(10,2)。在代碼示例中沒有直接演示金額累加但實際開發(fā)時所有金額計算都要用BigDecimal千萬不要用double做加法。8.3 上線部署與合法域名如果這套系統(tǒng)要部署到真實環(huán)境微信小程序上線有一個關(guān)鍵要求所有請求的域名必須是 HTTPS 且已經(jīng)在微信公眾平臺配置為合法的 request 合法域名。個人開發(fā)者在本地測試時可以使用“不校驗合法域名”開關(guān)但正式發(fā)布前必須準(zhǔn)備 HTTPS 域名并完成 ICP 備案。這一點在論文的“系統(tǒng)部署”章節(jié)中可以如實說明但實際操作時要留足時間。9. 畢業(yè)設(shè)計論文結(jié)構(gòu)與答辯準(zhǔn)備9.1 論文章節(jié)建議畢業(yè)設(shè)計論文的結(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è)計總體架構(gòu)設(shè)計、功能模塊設(shè)計、數(shù)據(jù)庫設(shè)計、接口設(shè)計系統(tǒng)實現(xiàn)按功能模塊分別描述實現(xiàn)過程配合核心代碼和運行截圖系統(tǒng)測試測試環(huán)境、功能測試用例、測試結(jié)果分析總結(jié)與展望每一章的寫作邏輯是“先把場景和問題描述清楚再說明采用了什么方案最后貼出結(jié)果證明有效”。代碼不要大段整段地貼只摘錄關(guān)鍵方法并附簡短說明更有論文感。9.2 答辯常見追問答辯老師一般不會為難學(xué)生但很可能會圍繞系統(tǒng)實際實現(xiàn)細節(jié)展開提問。以下幾個問題是水果店管理系統(tǒng)最高頻的追問方向購物車加同一商品時是新增記錄還是數(shù)量累加為什么提交訂單時如何保證庫存不會超賣代碼中是怎么實現(xiàn)的微信登錄的完整流程是什么code 換 openid 這一步發(fā)生在哪里用戶和管理員是否共用同一套登錄邏輯權(quán)限是如何隔離的如果用戶同時下單導(dǎo)致庫存扣減沖突系統(tǒng)會怎樣處理對于最后一個問題如果項目只做了基本的庫存校驗可以回答當(dāng)前的實現(xiàn)方案是“查詢庫存 - 判斷充足 - 扣減庫存”在單機低并發(fā)場景下可以正常工作然后補充一句如果要應(yīng)對更高并發(fā)可以使用數(shù)據(jù)庫行鎖或樂觀鎖機制這是后續(xù)優(yōu)化方向。這樣既如實說明了當(dāng)前實現(xiàn)又展示了對擴展性的思考是一個比較穩(wěn)妥的回答策略。9.3 演示時注意演示節(jié)奏答辯演示環(huán)節(jié)建議提前準(zhǔn)備一份“演示腳本”按順序展示核心功能管理員登錄后先添加一個水果商品然后在用戶端小程序刷新查看新商品加入購物車提交訂單再回到管理端看到訂單并執(zhí)行發(fā)貨操作。這個流程約 3 到 5 分鐘覆蓋了系統(tǒng)的全部核心鏈路比零散地點擊各個頁面更能在短時間內(nèi)讓評審老師建立完整印象。演示前確認網(wǎng)絡(luò)通暢、后端服務(wù)和數(shù)據(jù)庫均已啟動這是最基礎(chǔ)但也是最容易被忽略的準(zhǔn)備。10. 總結(jié)與后續(xù)優(yōu)化方向微信小程序水果店管理系統(tǒng)這個題目看起來并不炫酷但它的工程完整度和可擴展性恰恰是畢業(yè)設(shè)計最看重的。從用戶端到管理端從購物車到訂單事務(wù)從數(shù)據(jù)庫設(shè)計到接口鑒權(quán)每一個環(huán)節(jié)都是真實業(yè)務(wù)系統(tǒng)的縮影。做好這套系統(tǒng)你掌握的并不是某一段代碼而是“把一個實際業(yè)務(wù)拆解成需求、設(shè)計、編碼、測試、文檔”的完整方法這種能力在后續(xù)的工作和項目實踐中會持續(xù)復(fù)用。如果做完基礎(chǔ)功能后還有余力可以從三個方向繼續(xù)深化。第一接入微信支付把模擬支付替換為真實支付鏈路但這需要企業(yè)主體的小程序賬號個人開發(fā)者只能作為論文中的理論設(shè)計。第二加入數(shù)據(jù)可視化圖表在后端定時統(tǒng)計每日銷售額和熱銷商品用 ECharts 在管理端展示趨勢圖這是一個明顯的加分項。第三在訂單模塊引入樂觀鎖或 Redis 預(yù)扣庫存方案驗證高并發(fā)場景下的庫存一致性把系統(tǒng)從“能跑”推向“抗打”。如果你是正在做這道題的學(xué)生建議先把這篇文中的核心流程逐個跑通再結(jié)合自己的理解去擴展。代碼可以復(fù)用但數(shù)據(jù)庫字段是否合理、接口是否健壯、論文中的技術(shù)表述是否準(zhǔn)確需要你親自檢查。把這些事情做扎實畢業(yè)設(shè)計不僅是一份作業(yè)也會成為你簡歷上可以坦然寫出的一項完整項目經(jīng)歷。