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