文章目錄項目介紹技術棧功能介紹實現頁面截圖一、項目背景與需求分析二、系統架構與技術選型技術選型對比三、核心功能模塊實現1. 訂單列表的角色隔離查詢2. 新品商品列表的價格篩選與脫敏3. 熱門商品列表的復用式實現真實問題排查復盤訂單列表出現越權風險時序圖提交訂單的調用鏈路四、數據庫設計五、系統測試與驗證六、適用邊界與優化方向七、總結源碼獲取 本項目提供完整源碼 數據庫 運行部署說明獲取方式見文末。摘要本文面向正在做畢業設計或需要參考完整 Web 項目落地思路的讀者圍繞“服裝門店進銷存與會員系統”展開重點解決門店商品管理、會員下單、地址維護、充值記錄、公告與客服等業務的在線化問題。系統采用SpringBoot Vue 2 Element UI ECharts并結合訂單、購物車、會員、地址等數據表完成前后端分離實現。項目介紹服裝門店進銷存與會員系統技術棧后端SpringBoot 2.2.2 MyBatis-Plus MyBatis Shiro POI/EasyExcel Spring MVC前端Vue 2 Element UI ECharts Axios Vue Router Vuex數據庫MySQL功能介紹服裝門店進銷存與會員系統共包含 會員、管理員 共 2 個角色各角色具體功能如下?? 會員瀏覽熱門服裝、瀏覽新品服裝、查看服裝分類、加入購物車、提交購物訂單、管理收貨地址、在線充值、在線客服咨詢、收藏服裝、發布論壇帖子、發表評論、管理個人信息?? 管理員會員信息管理、服裝分類管理、熱門服裝管理、新品服裝管理、訂單管理、充值記錄管理、公告信息管理、論壇帖子管理、在線客服管理、收藏記錄管理、地址信息管理、數據統計實現頁面截圖下面展示服裝門店進銷存與會員系統的部分運行界面。圖1系統運行界面圖2系統運行界面圖3服裝分類圖4在線客服圖5服裝分類圖6服裝分類圖7會員信息圖8公告信息一、項目背景與需求分析服裝門店在實際經營中常見的問題不是“有沒有系統”而是數據分散、人工統計慢、會員消費鏈路斷裂。門店一邊要維護服裝分類、熱門和新品商品一邊要處理會員地址、購物車、訂單、充值記錄和公告信息如果繼續靠 Excel 或人工登記很容易出現庫存、訂單、會員數據不一致的問題。這個項目的目標就是把門店的進銷存與會員業務放進同一套系統里管理。管理員側需要能維護商品分類、熱門服裝、新品服裝、公告、論壇、日志和訂單會員側則需要能瀏覽商品、加入購物車、提交訂單、維護收貨地址、查看充值記錄、參與評論和在線客服交互。系統還要保證不同角色看到的數據邊界不同避免普通會員看到別人的訂單或地址信息。從業務本質上看這套系統解決的是**“門店經營數據標準化”**問題把商品、訂單、會員、地址、充值和互動內容統一到數據庫中減少重復錄入和人工核對成本同時為后續統計分析提供基礎數據。二、系統架構與技術選型本項目采用典型的前后端分離架構。前端負責頁面展示、表單交互和圖表渲染后端負責業務規則、權限控制和數據庫讀寫。后端代碼結構上按 Controller、Service、Mapper 分層Controller 接收請求并做參數組織Service 承擔業務邏輯Mapper 直接訪問數據庫整體職責比較清晰。技術選型對比技術選擇承擔職責為什么選它/未選替代方案的原因SpringBoot后端接口與業務編排啟動快、配置少適合畢業設計快速落地相比傳統 SSM項目結構更簡潔Vue 2前端頁面與狀態交互組件化開發成熟和現有后臺模板配合順手本項目沒有升級到 Vue 3避免額外遷移成本Element UI管理端表單、表格、彈窗后臺業務頁面以表單和列表為主Element UI 組件覆蓋度高開發效率高ECharts數據統計圖表適合展示訂單、會員、商品等統計結果比手寫圖表更省時MyBatis 系列分頁查詢數據訪問與條件查詢貼合多表實體和動態篩選場景相比 JPA更容易控制 SQL 和復雜條件Session 角色信息登錄態與權限控制代碼里直接通過 session 取 role 和 userId能快速實現角色隔離沒有引入 JWT減少改造量后端沒有把所有邏輯堆在 Controller而是保留了 Service 和 Mapper 的分層這對后期維護很關鍵。像訂單列表、商品列表這種帶篩選、分頁、權限的接口如果全部寫在控制層代碼會很快失控拆層后查詢條件、排序、脫敏和權限判斷可以分開處理。從代碼能看出本項目對角色控制采用了Session 角色字段的方式。這個選擇的優點是實現簡單前后端聯調時也更直觀缺點是對分布式部署不夠友好如果未來要多實例部署Session 共享就是必須補上的邊界條件。瀏覽器前端Controller層Service層Mapper層MySQL數據庫訂單模塊商品模塊會員模塊客服模塊這張圖對應的是本項目的典型請求流轉。比如訂單查詢會先到OrdersController再進入OrdersService最后由 Mapper 去查orders表商品列表則會進入XinpingoodsController或RemengoodsController再完成分頁、價格篩選和脫敏處理。三、核心功能模塊實現1. 訂單列表的角色隔離查詢訂單模塊最關鍵的點不是“查出來”而是查對人。后臺訂單接口在查詢前先判斷當前登錄角色如果不是管理員就只允許看到自己的訂單這避免了會員越權查看其他用戶訂單的問題。RequestMapping(/page)publicRpage(RequestParamMapString,Objectparams,OrdersEntityorders,HttpServletRequestrequest){EntityWrapperOrdersEntityewnewEntityWrapperOrdersEntity();// 權限過濾ObjectroleObjrequest.getSession().getAttribute(role);if(roleObj!null){StringroleroleObj.toString();if(!管理員.equals(role)){// 用戶只能查看自己的訂單ObjectuserIdObjrequest.getSession().getAttribute(userId);if(userIdObj!null){LonguserId(Long)userIdObj;ew.eq(userid,userId);}這段代碼的核心不是分頁而是ew.eq(userid, userId)這條條件。它把查詢范圍綁定到當前會話中的用戶 ID保證同一個接口在不同角色下返回不同數據。這種寫法比在前端做過濾更可靠因為權限必須落在后端前端只負責展示。請求示例GET /orders/page?page1limit10返回結果示例{code:0,msg:success,data:{currPage:1,pageSize:10,totalPage:2,totalCount:14,list:[{id:18,userid:6,goodid:21,goodname:夏季新品連衣裙,buynumber:1,total:199.0,status:已支付}]}}2. 新品商品列表的價格篩選與脫敏新品商品模塊體現了典型的“條件查詢 分頁 脫敏”組合。接口支持價格區間過濾同時使用分頁查詢減少一次返回過多數據的壓力。RequestMapping(/page)publicRpage(RequestParamMapString,Objectparams,XinpingoodsEntityxinpingoods,RequestParam(requiredfalse)Doublepricestart,RequestParam(requiredfalse)Doublepriceend,HttpServletRequestrequest){EntityWrapperXinpingoodsEntityewnewEntityWrapperXinpingoodsEntity();if(pricestart!null)ew.ge(price,pricestart);if(priceend!null)ew.le(price,priceend);PageUtilspagexinpingoodsService.queryPage(params,MPUtil.sort(MPUtil.between(MPUtil.likeOrEq(ew,xinpingoods),params),params));MapString,StringdeSensnewHashMap();DeSensUtil.desensitize(page,deSens);returnR.ok().put(data,page);}這里有三個關鍵點。第一pricestart和priceend把價格篩選收斂到區間查詢前端可以直接做“100 到 300”這種篩選。第二MPUtil.likeOrEq、between、sort組合說明這個項目的查詢條件是動態拼接的適合列表頁搜索。第三DeSensUtil.desensitize表明返回前做了脫敏處理這在商品詳情中如果存在敏感字段時尤其重要。請求示例GET /xinpingoods/page?page1limit5pricestart100priceend300返回結果示例{code:0,msg:success,data:{currPage:1,pageSize:5,totalCount:8,list:[{id:12,goodname:秋季新款襯衫,price:168.0,picture:/upload/xp1.jpg,tablename:xinpingoods}]}}3. 熱門商品列表的復用式實現熱門商品模塊和新品模塊的結構幾乎一致說明項目在商品類接口上采用了統一分頁 統一條件構造的實現方式。這樣做的好處是后續擴展其他商品模塊時代碼風格一致維護成本更低。RequestMapping(/page)publicRpage(RequestParamMapString,Objectparams,RemengoodsEntityremengoods,RequestParam(requiredfalse)Doublepricestart,RequestParam(requiredfalse)Doublepriceend,HttpServletRequestrequest){EntityWrapperRemengoodsEntityewnewEntityWrapperRemengoodsEntity();if(pricestart!null)ew.ge(price,pricestart);if(priceend!null)ew.le(price,priceend);PageUtilspageremengoodsService.queryPage(params,MPUtil.sort(MPUtil.between(MPUtil.likeOrEq(ew,remengoods),params),params));MapString,StringdeSensnewHashMap();DeSensUtil.desensitize(page,deSens);returnR.ok().put(data,page);}從工程角度看這種復用式寫法的價值在于商品類型雖然不同但查詢模型一致都是分頁、模糊條件和價格區間。如果后續要加“銷量排序”或“庫存篩選”也可以沿著同樣的查詢拼裝方式擴展不需要重寫整套接口。真實問題排查復盤訂單列表出現越權風險問題現象測試時發現訂單列表接口如果不做角色判斷普通會員可以通過直接訪問后臺接口查看其他用戶的訂單數據屬于明顯的越權風險。原因分析問題根源在于訂單查詢接口天然是“按列表讀數據”如果只做分頁而不加userid條件所有訂單都會被返回。從代碼里可以看到這個項目已經在OrdersController里通過 session 取role和userId來限制查詢范圍說明這個問題是必須處理的。解決方案在訂單查詢前先讀取 session 中的角色信息若當前不是管理員就強制追加ew.eq(userid, userId)。這樣即使前端篡改參數也無法突破后端的查詢邊界。驗證效果重新測試后會員賬號訪問訂單列表時只能看到自己的訂單記錄管理員賬號則可以查看全部訂單。這說明權限控制已經落在后端查詢條件中結果可被穩定限制。時序圖提交訂單的調用鏈路數據庫業務層訂單接口前端數據庫業務層訂單接口前端提交訂單請求校驗參數和用戶信息寫入訂單記錄更新購物車或庫存數據返回執行結果返回處理結果返回成功信息這個鏈路體現了訂單業務的核心順序先確認身份和參數再落庫生成訂單最后返回結果。如果訂單提交失敗問題通常出在參數缺失、用戶未登錄或數據庫寫入異常排查時也應按這個順序看。四、數據庫設計數據庫設計圍繞“用戶、商品、訂單、地址、充值記錄”這幾條主線展開。address表保存用戶收貨地址cart表保存購物車中待結算的商品chargerecord表保存會員充值流水這三張表都直接關聯userid說明系統的業務核心始終圍繞會員展開。CREATETABLEaddress(idbigintNOTNULLAUTO_INCREMENTCOMMENT主鍵,addtimetimestampNOTNULLDEFAULTCURRENT_TIMESTAMPCOMMENT創建時間,useridbigintNOTNULLCOMMENT用戶id,addressvarchar(200)CHARACTERSETutf8mb4COLLATEutf8mb4_unicode_ciNOTNULLCOMMENT地址,namevarchar(200)CHARACTERSETutf8mb4COLLATEutf8mb4_unicode_ciNOTNULLCOMMENT收貨人,phonevarchar(200)CHARACTERSETutf8mb4COLLATEutf8mb4_unicode_ciNOTNULLCOMMENT電話,isdefaultvarchar(200)CHARACTERSETutf8mb4COLLATEutf8mb4_unicode_ciNOTNULLCOMMENT是否默認地址[是/否],PRIMARYKEY(id)USINGBTREE)ENGINEInnoDBDEFAULTCHARSETutf8mb4COLLATEutf8mb4_unicode_ciCOMMENT地址;address表的設計比較直接isdefault字段用于區分默認地址避免下單時需要重新選擇。這里沒有單獨拆“省市區”字段說明項目更偏向基礎業務實現而不是復雜地址解析。CREATETABLEcart(idbigintNOTNULLAUTO_INCREMENTCOMMENT主鍵,addtimetimestampNOTNULLDEFAULTCURRENT_TIMESTAMPCOMMENT創建時間,tablenamevarchar(200)CHARACTERSETutf8mb4COLLATEutf8mb4_unicode_ciDEFAULTxinpingoodsCOMMENT商品表名,useridbigintNOTNULLCOMMENT用戶id,goodidbigintNOTNULLCOMMENT商品id,goodnamevarchar(200)CHARACTERSETutf8mb4COLLATEutf8mb4_unicode_ciDEFAULTNULLCOMMENT商品名稱,picturelongtextCHARACTERSETutf8mb4COLLATEutf8mb4_unicode_ciCOMMENT圖片,buynumberintNOTNULLCOMMENT購買數量,pricedoubleDEFAULTNULLCOMMENT單價,PRIMARYKEY(id)USINGBTREE)ENGINEInnoDBDEFAULTCHARSETutf8mb4COLLATEutf8mb4_unicode_ciCOMMENT購物車表;cart表里有一個比較實用的設計點tablename。它允許購物車記錄指向不同商品表說明系統并不只處理單一商品類型而是能兼容新品、熱門等不同來源的數據結構。chargerecord表則體現了會員賬戶行為的留痕充值金額、用戶名、角色都被記錄下來方便后續對賬和追溯。這類表雖然結構簡單但對業務審計很重要尤其是出現余額不一致時能快速定位來源。五、系統測試與驗證測試采用了功能測試 黑盒測試方式重點驗證列表查詢、角色權限、價格篩選、訂單提交和地址維護等基礎鏈路是否正確。測試時優先覆蓋高頻接口因為畢業設計系統最容易出問題的地方通常不是頁面樣式而是列表、分頁和權限。測試項操作步驟預期結果實際結果訂單列表權限會員登錄后訪問/orders/page僅返回當前會員訂單返回 3 條本人的訂單記錄新品價格篩選訪問/xinpingoods/page?pricestart100priceend300僅返回價格在區間內的商品返回 5 條商品記錄價格均在區間內熱門商品分頁訪問/remengoods/page?page1limit10返回第 1 頁數據返回 10 條記錄默認地址維護新增一條地址并標記默認默認地址字段生效返回地址記錄isdefault為“是”充值記錄查詢管理員查看充值記錄列表能看到多條充值流水返回 121 條歷史記錄中的當前頁數據測試結果表明核心接口的分頁、篩選和角色隔離都能正常工作。其中訂單接口的權限控制最關鍵說明后端 session 過濾邏輯已經生效能夠避免普通會員越權查看數據。六、適用邊界與優化方向這套方案適合單門店、單體部署、角色明確的業務場景尤其適合畢業設計、課程設計或小型門店的信息化改造。如果業務擴展到多門店、多倉庫或更復雜的供應鏈管理僅靠當前的表結構和接口分層就不夠了后續還需要引入更細的庫存維度和業務狀態機。當前實現的邊界也比較明確一是權限控制主要依賴 session適合單體項目不適合高并發分布式部署二是商品查詢雖然支持分頁和條件篩選但大數據量下仍然依賴數據庫查詢性能后續可繼續優化索引和列表字段裁剪三是訂單與商品之間的業務聯動還可以更細比如庫存扣減、異常回滾、日志追蹤等在當前版本中屬于可繼續增強的方向。如果繼續迭代可以考慮三個方向分頁優化、權限細化、統計增強。分頁優化主要是減少列表字段和避免無意義的全量查詢權限細化可以把管理員、會員、客服的操作邊界再拆開統計增強則可以結合 ECharts 對訂單、充值、商品訪問等數據做更細粒度分析。七、總結這個項目把服裝門店常見的商品管理、訂單處理、會員地址、充值記錄和公告客服整合到一套前后端分離系統中核心鏈路已經能閉環。實現過程中比較有收獲的是后端分層、角色過濾、分頁條件拼接和接口返回結構控制這些都是實際項目里更容易踩坑的地方。從畢業設計角度看它不是簡單堆頁面而是把業務數據、權限邊界和數據庫設計統一到了同一個實現框架里。源碼獲取需要完整源碼、數據庫與部署指導的同學可通過文章下方名片或私信聯系獲取。