簡(jiǎn)介這是一套面向計(jì)算機(jī)專業(yè)本科生的2025屆畢業(yè)設(shè)計(jì)/課程設(shè)計(jì)實(shí)戰(zhàn)項(xiàng)目聚焦服裝搭配推薦場(chǎng)景解決用戶個(gè)性化穿搭決策效率低、后臺(tái)管理缺乏系統(tǒng)化工具等實(shí)際問題適用于Java全棧技術(shù)學(xué)習(xí)與工程實(shí)踐。資源包共6個(gè)文件含Vue3SpringBoot3完整源碼zip、MySQL8數(shù)據(jù)庫(kù)腳本sql、系統(tǒng)需求文檔docx、全流程操作錄屏mp4及返修版本源碼與文檔zip總大小87.05MB結(jié)構(gòu)清晰、模塊完整覆蓋前后端分離開發(fā)典型流程。已有64人下載學(xué)習(xí)適合掌握基礎(chǔ)Java、Vue.js和SpringBoot的學(xué)生開展二次開發(fā)或答辯復(fù)現(xiàn)。讀者可直接部署運(yùn)行通過錄屏快速掌握后臺(tái)商品/搭配模板管理、前臺(tái)瀏覽推薦、用戶交互等核心功能并結(jié)合需求文檔理解業(yè)務(wù)建模邏輯返修材料更便于對(duì)照學(xué)習(xí)常見優(yōu)化點(diǎn)與代碼規(guī)范改進(jìn)路徑。 從衣櫥里挑衣服這件事很多人每天都要糾結(jié)十分鐘起步——這件上衣配哪條褲子這雙鞋能不能搭這條裙子顏色會(huì)不會(huì)沖突風(fēng)格是不是統(tǒng)一如果你仔細(xì)想想會(huì)發(fā)現(xiàn)這其實(shí)是一個(gè)典型的“信息過載決策困難”問題。也正是這個(gè)痛點(diǎn)讓我在2025年做畢業(yè)設(shè)計(jì)的時(shí)候毫不猶豫地選了服裝搭配推薦系統(tǒng)這個(gè)方向技術(shù)棧用了SpringBoot3 Vue.js3。先擺個(gè)結(jié)論這套系統(tǒng)做出來之后不只是“畢設(shè)能過”的水平。它既能當(dāng)完整的電商/穿搭類項(xiàng)目來展示功能又能把“推薦算法”作為核心亮點(diǎn)去答辯同時(shí)前后端技術(shù)棧又踩在2025年的主流節(jié)點(diǎn)上。對(duì)于需要一個(gè)既有技術(shù)深度、又有實(shí)際應(yīng)用場(chǎng)景、還不容易和同學(xué)撞車的畢設(shè)題目來說這是一個(gè)很難得的選擇。這篇文章我會(huì)把這個(gè)項(xiàng)目的完整思路拆開講從選題邏輯、功能設(shè)計(jì)、數(shù)據(jù)庫(kù)建模到推薦算法怎么落地成真正的Java代碼再到Vue3前端怎么做搭配展示最后是答辯和演示時(shí)最容易踩的坑。整篇文章不是泛泛的介紹而是照著能復(fù)現(xiàn)、能運(yùn)行、能答辯的標(biāo)準(zhǔn)來寫。1. 為什么選“服裝搭配推薦”這個(gè)方向從痛點(diǎn)倒推選題每年畢業(yè)設(shè)計(jì)選題的時(shí)候總能刷到一批“經(jīng)典款”題目XXX管理系統(tǒng)、XXX商城、XXX論壇。不是說這些題目不行而是撞車率太高而且功能做完就是標(biāo)準(zhǔn)的增刪改查答辯的時(shí)候老師問一句“你的難點(diǎn)在哪里”場(chǎng)面會(huì)變得很安靜。服裝搭配推薦系統(tǒng)能在這種大環(huán)境里跳出來核心原因是它站得住兩個(gè)維度。第一個(gè)維度是真實(shí)場(chǎng)景。根據(jù)我對(duì)周圍人的觀察絕大多數(shù)人的衣櫥里并不缺衣服缺的是“怎么把它們組合起來”的能力。買的時(shí)候覺得好看回家發(fā)現(xiàn)不知道怎么搭最后衣服要么壓箱底、要么永遠(yuǎn)穿那兩三套。所以“搭配推薦”解決的不僅是“找相似商品”而是“幫你做決策”的問題。這個(gè)場(chǎng)景放在哪個(gè)時(shí)代都成立比純粹賣東西的商城系統(tǒng)多了一層用戶價(jià)值。第二個(gè)維度是技術(shù)難度剛好卡在畢設(shè)的“甜點(diǎn)區(qū)”。它比純CRUD復(fù)雜但又沒有復(fù)雜到讓人做不完。推薦邏輯可以用規(guī)則引擎、可以用相似度計(jì)算、也可以加一點(diǎn)協(xié)同過濾的變體算法的解釋成本低演示效果好。這個(gè)度是非常重要的——太簡(jiǎn)單了沒有亮點(diǎn)太難了做到一半心態(tài)崩掉。再看技術(shù)棧的選擇。之所以選SpringBoot3 Vue3而不是還在到處流傳的SpringBoot2 Vue2有兩個(gè)方面的考慮一是2025年這個(gè)時(shí)間點(diǎn)上SpringBoot3已經(jīng)非常成熟。它基于JDK17底層是Spring Framework 6性能、安全性、生態(tài)都對(duì)得上當(dāng)前工業(yè)界的新項(xiàng)目標(biāo)準(zhǔn)。現(xiàn)在出去找工作簡(jiǎn)歷上寫SpringBoot2反而會(huì)讓面試官覺得技術(shù)棧更新不及時(shí)。既然畢設(shè)是一個(gè)能寫進(jìn)簡(jiǎn)歷的項(xiàng)目那技術(shù)棧最好是當(dāng)前企業(yè)正在用的。二是Vue3配合Vite構(gòu)建工具開發(fā)體驗(yàn)比Vue2的Webpack方案好很多。Composition API在邏輯復(fù)用、組織代碼這件事上比Options API更舒服Element Plus組件庫(kù)也很成熟。前端部分做衣櫥管理、搭配展示這類界面正好能把Vue3的優(yōu)勢(shì)發(fā)揮出來。為了讓你直觀感受技術(shù)選型的合理性我做了個(gè)對(duì)比表對(duì)比維度SpringBoot2 Vue2SpringBoot3 Vue3JDK要求JDK8/11JDK17支持新語法和新特性底層框架Spring Framework 5Spring Framework 6性能優(yōu)化明顯構(gòu)建工具Webpack為主Vite冷啟動(dòng)速度快一個(gè)量級(jí)前端狀態(tài)方案VuexPiniaTypeScript支持更好組件庫(kù)Element UIElement Plus答辯面試優(yōu)勢(shì)常規(guī)水平能體現(xiàn)2025年技術(shù)敏感度所以這個(gè)選題的核心邏輯是用真實(shí)的用戶決策痛點(diǎn)作為項(xiàng)目外殼用“推薦算法主流前后端框架”作為技術(shù)內(nèi)核。外行看著覺得有意思內(nèi)行看著覺得有深度老師看著覺得工作量飽滿。2. 系統(tǒng)功能骨架與數(shù)據(jù)庫(kù)設(shè)計(jì)先把“賣什么”定清楚動(dòng)手寫代碼之前我花了兩天時(shí)間畫功能腦圖和設(shè)計(jì)稿。這個(gè)階段最忌諱的是“上來就寫Controller”因?yàn)榉b搭配這個(gè)領(lǐng)域里物品屬性、標(biāo)簽體系、搭配規(guī)則之間是有依賴關(guān)系的不提前定好數(shù)據(jù)模型后面改起來會(huì)非常痛。2.1 三種角色與核心業(yè)務(wù)閉環(huán)我先把這個(gè)系統(tǒng)涉及的角色和業(yè)務(wù)閉環(huán)講清楚這部分也是后面數(shù)據(jù)庫(kù)建模的依據(jù)。系統(tǒng)分了三種角色游客只能看首頁(yè)和熱門搭配用來?yè)纹痦?xiàng)目展示面的“公開區(qū)域”。注冊(cè)用戶系統(tǒng)的核心使用角色。可以在衣櫥里上傳衣服、完善屬性標(biāo)簽、發(fā)起搭配請(qǐng)求、收藏滿意的搭配、查看歷史搭配記錄。管理員負(fù)責(zé)服裝庫(kù)的維護(hù)、標(biāo)簽字典的管理、用戶內(nèi)容審核。畢設(shè)里這一塊不需要做得太重但要有否則“后臺(tái)管理功能”這個(gè)基本盤就丟了。核心業(yè)務(wù)閉環(huán)是一條很清楚的鏈路用戶上傳/添加服裝 → 維護(hù)服裝標(biāo)簽屬性 → 發(fā)起搭配請(qǐng)求 → 系統(tǒng)生成搭配方案 → 用戶收藏或反饋 → 系統(tǒng)記錄日志并優(yōu)化后續(xù)推薦。這條鏈路里最關(guān)鍵的實(shí)體是“服裝”而服裝的關(guān)鍵又在于“標(biāo)簽屬性”。為什么不是直接在服裝表里寫死十幾個(gè)字段比如顏色、風(fēng)格、季節(jié)這個(gè)我后面講數(shù)據(jù)庫(kù)設(shè)計(jì)的時(shí)候詳細(xì)說。2.2 數(shù)據(jù)庫(kù)表結(jié)構(gòu)設(shè)計(jì)數(shù)據(jù)庫(kù)我用的MySQLSpring Data JPA做ORM。核心表一共六張用戶表、服裝表、標(biāo)簽表、服裝標(biāo)簽關(guān)聯(lián)表、搭配記錄表、搭配收藏表。額外還有一套室內(nèi)裝飾、穿著場(chǎng)景的字典表但那是擴(kuò)展用的不影響主流程。表名核心字段說明userid, username, password, nickname, avatar用戶信息clothingid, user_id, name, category, image_url, color, season, style, occasion, fit服裝單品簡(jiǎn)化版屬性tagid, name, type標(biāo)簽字典比如“通勤”“小清新”“暖色系”clothing_tagclothing_id, tag_id服裝和標(biāo)簽多對(duì)多關(guān)聯(lián)outfitid, user_id, top_id, bottom_id, shoes_id, outer_id, reason, create_time搭配記錄一條記錄存一套完整方案outfit_favoriteid, user_id, outfit_id, create_time收藏功能這里我想重點(diǎn)說三個(gè)設(shè)計(jì)決策都是實(shí)際開發(fā)中踩過或者思考過的第一為什么服裝表既要有獨(dú)立屬性字段又要有關(guān)聯(lián)標(biāo)簽表獨(dú)立屬性字段color、season、style等是為了滿足“條件篩選”這種高性能查詢比如用戶想看“夏天通勤連衣裙”標(biāo)簽表是為了滿足“柔性擴(kuò)展”比如以后想加一個(gè)“適合約會(huì)”的標(biāo)簽改字典就行不用改表結(jié)構(gòu)。兩者結(jié)合既能跑推薦算法又能做篩選靈活性最高。第二為什么搭配記錄單獨(dú)建一張outfit表而不是每次臨時(shí)算推薦算法的計(jì)算是有開銷的而且用戶對(duì)同一套搭配可能反復(fù)查看。把生成好的搭配方案存下來好處是歷史記錄查詢極快也在數(shù)據(jù)結(jié)構(gòu)上天然形成了“用戶的行為日志”——這是后續(xù)優(yōu)化推薦效果的依據(jù)。第三category字段用String而不是用外鍵關(guān)聯(lián)分類表加分類表更規(guī)范但畢設(shè)場(chǎng)景里分類就那么幾個(gè)上裝、下裝、裙子、外套、鞋靴、配飾用枚舉字符串反而簡(jiǎn)單直觀。你要是為了在論文里多寫一張表也可以拆出去但我個(gè)人覺得沒必要這是典型的“過度建?！?。2.3 接口清單規(guī)劃數(shù)據(jù)庫(kù)定完接口基本就出來了。我按照RESTful風(fēng)格整理了一下核心接口不算多模塊方法路徑說明用戶POST/api/user/register注冊(cè)用戶POST/api/user/login登錄返回JWT服裝GET/api/clothing/list當(dāng)前用戶的衣櫥列表服裝POST/api/clothing/add添加服裝信息服裝DELETE/api/clothing/{id}刪除服裝推薦GET/api/recommend/outfit/{clothingId}基于指定單品生成搭配推薦GET/api/recommend/daily每日精選搭配搭配GET/api/outfit/history歷史搭配記錄搭配POST/api/outfit/favorite收藏搭配管理GET/api/admin/clothing/page管理員分頁(yè)查看服裝庫(kù)這套接口清單背后有一個(gè)隱藏設(shè)計(jì)邏輯所有推薦相關(guān)的路徑都收斂在/api/recommend下和普通CRUD接口隔離開來。這樣做是為了在代碼層面清晰地告訴閱讀者——哪些是普通業(yè)務(wù)哪些是算法核心答辯的時(shí)候講代碼結(jié)構(gòu)會(huì)非常清爽。3. 推薦算法落地從余弦相似度到可解釋推薦這部分是整個(gè)系統(tǒng)的靈魂也是很多同學(xué)最容易犯怵的地方。其實(shí)沒必要慌我先把算法選擇的邏輯講清楚你就知道為什么我會(huì)放棄那些聽起來高大上的方案。3.1 為什么我沒選“協(xié)同過濾”當(dāng)主力算法協(xié)同過濾是推薦系統(tǒng)教材上的經(jīng)典內(nèi)容分成基于用戶的UserCF和基于物品的ItemCF。但放在畢設(shè)這個(gè)場(chǎng)景下有一個(gè)繞不開的問題數(shù)據(jù)稀疏。協(xié)同過濾本質(zhì)上是“物以類聚、人以群分”它需要大量用戶行為數(shù)據(jù)才能發(fā)揮作用。你一個(gè)畢設(shè)項(xiàng)目哪來的幾萬用戶用戶不多行為矩陣稀稀拉拉算出來的相似度根本沒有統(tǒng)計(jì)意義演示的時(shí)候效果完全不可控。更重要的是協(xié)同過濾是黑盒模型你很難跟答辯老師解釋清楚“為什么推薦了這一套搭配”。萬一老師追著問具體案例你只能反復(fù)說“因?yàn)槠渌脩粢策@樣選擇”——這個(gè)解釋力在答辯現(xiàn)場(chǎng)是很弱的。3.2 適合畢設(shè)的解法基于內(nèi)容特征的搭配評(píng)分我最后用的方案是基于服裝內(nèi)容特征 規(guī)則約束 余弦相似度打分屬于混合式推薦。它比純協(xié)同過濾的可解釋性更強(qiáng)比純規(guī)則的硬編碼更有技術(shù)含量而且效果完全可控。核心思想分三層規(guī)則層先做硬約束比如“外套不能推薦成內(nèi)搭”“夏季上裝優(yōu)先配薄款下裝”“西裝外套優(yōu)先配通勤風(fēng)單品”。這些規(guī)則用代碼if-else實(shí)現(xiàn)過濾掉明顯不合理的搭配。特征層每件服裝根據(jù)屬性標(biāo)簽轉(zhuǎn)成一個(gè)特征向量。比如一件“白色、夏季、通勤風(fēng)、修身上裝”它的特征向量就是{白色:1, 夏季:1, 通勤:1, 修身:1}顏色、季節(jié)、風(fēng)格、版型這些維度組成一個(gè)多值編碼的boolean向量。評(píng)分層計(jì)算候選單品與推薦目標(biāo)之間的余弦相似度再疊加規(guī)則權(quán)重得到最終得分按分?jǐn)?shù)排序取TopN。3.3 特征向量構(gòu)建與余弦相似度計(jì)算這里我直接把核心代碼邏輯貼出來代碼是Java寫的用的SpringBoot3環(huán)境。先定義服裝的特征提取器public class ClothingFeatureExtractor { /** * 將服裝實(shí)體轉(zhuǎn)為特征向量。 * 這里用了LinkedHashMap保證特征順序一致便于后續(xù)計(jì)算。 */ public static MapString, Double extract(Clothing clothing) { MapString, Double vector new LinkedHashMap(); // 基礎(chǔ)屬性編碼 vector.put(category_ clothing.getCategory(), 1.0); vector.put(color_ clothing.getColor(), 1.0); vector.put(season_ clothing.getSeason(), 1.0); vector.put(style_ clothing.getStyle(), 1.0); if (clothing.getFit() ! null) { vector.put(fit_ clothing.getFit(), 1.0); } // 關(guān)聯(lián)標(biāo)簽編碼 if (clothing.getTags() ! null) { for (Tag tag : clothing.getTags()) { vector.put(tag_ tag.getName().toLowerCase(), 1.0); } } return vector; } }這里有個(gè)關(guān)鍵細(xì)節(jié)把“類別”也編碼進(jìn)特征向量了。這個(gè)操作會(huì)讓“上裝”和“下裝”天然擁有不同的向量簽名避免推薦出同類單品互搭的尷尬局面。跑相似度計(jì)算時(shí)同類服裝的相似度矩陣也能正常使用但生成搭配時(shí)會(huì)加類別約束不讓上裝配上裝。然后是余弦相似度計(jì)算器和搭配推薦服務(wù)public class CosineSimilarity { public static double calculate(MapString, Double v1, MapString, Double v2) { if (v1.isEmpty() || v2.isEmpty()) { return 0.0; } double dot 0.0; double norm1 0.0; double norm2 0.0; for (Map.EntryString, Double entry : v1.entrySet()) { Double valueInV2 v2.get(entry.getKey()); if (valueInV2 ! null) { dot entry.getValue() * valueInV2; } norm1 entry.getValue() * entry.getValue(); } for (Double value : v2.values()) { norm2 value * value; } if (norm1 0.0 || norm2 0.0) { return 0.0; } return dot / (Math.sqrt(norm1) * Math.sqrt(norm2)); } }Service public class RecommendService { private final ClothingRepository clothingRepository; private final OutfitRepository outfitRepository; public RecommendService(ClothingRepository clothingRepository, OutfitRepository outfitRepository) { this.clothingRepository clothingRepository; this.outfitRepository outfitRepository; } /** * 給定一件單品推薦一套搭配。 * 流程先按類別硬約束過濾再計(jì)算相似度最后返回TopN。 */ public ListOutfit recommendOutfit(Long clothingId) { Clothing base clothingRepository.findById(clothingId) .orElseThrow(() - new RuntimeException(服裝不存在)); MapString, Double baseVector ClothingFeatureExtractor.extract(base); // 1. 找出所有非同類別的可搭配服裝 ListClothing candidates clothingRepository.findAll(); ListClothing filtered candidates.stream() .filter(c - !c.getId().equals(baseId)) .filter(c - RuleEngine.isReasonableMatch(base, c)) .collect(Collectors.toList()); // 2. 對(duì)候選單品按相似度打分 ListScoredClothing scored filtered.stream() .map(c - new ScoredClothing( c, CosineSimilarity.calculate(baseVector, ClothingFeatureExtractor.extract(c)) )) .sorted((a, b) - Double.compare(b.getScore(), a.getScore())) .collect(Collectors.toList()); // 3. 按分類取最優(yōu)下裝、鞋/配飾、外套作為可選 OptionalClothing bottom scored.stream() .filter(s - 下裝.equals(s.getClothing().getCategory())) .findFirst(); OptionalClothing shoes scored.stream() .filter(s - 鞋靴.equals(s.getClothing().getCategory())) .findFirst(); OptionalClothing outer scored.stream() .filter(s - 外套.equals(s.getClothing().getCategory())) .findFirst(); // 4. 生成搭配記錄并保存 Outfit outfit new Outfit(); outfit.setBaseClothingId(baseId); bottom.ifPresent(c - outfit.setBottomId(c.getId())); shoes.ifPresent(c - outfit.setShoesId(c.getId())); outer.ifPresent(c - outfit.setOuterId(c.getId())); outfit.setReason(buildReason(base, bottom.orElse(null), shoes.orElse(null))); return outfitRepository.save(outfit); } }注意這里的RuleEngine.isReasonableMatch我單獨(dú)提出來一個(gè)規(guī)則引擎類里面全是硬約束規(guī)則。比如“上衣不跟上衣搭配”“顏色對(duì)比度不能太刺眼”“風(fēng)格標(biāo)簽至少有一個(gè)重合”。這些規(guī)則看著簡(jiǎn)單但它們是整個(gè)推薦方案里“防呆”的關(guān)鍵。沒有這些硬約束余弦相似度再高也可能推出一套“紅衣配紅褲”的春節(jié)聯(lián)歡會(huì)造型。3.4 冷啟動(dòng)與兜底策略畢設(shè)項(xiàng)目沒有真實(shí)用戶數(shù)據(jù)冷啟動(dòng)是必然要面對(duì)的。我的處理方式是系統(tǒng)初始內(nèi)置一批“專家搭配模板”作為種子數(shù)據(jù)大概20套左右。這些模板是我自己按通勤、休閑、約會(huì)、運(yùn)動(dòng)四個(gè)場(chǎng)景整理的每套模板含有基礎(chǔ)單品組合和推薦理由。當(dāng)計(jì)算出的相似度分?jǐn)?shù)太低比如低于閾值0.1或者衣櫥里根本沒有合適搭配的時(shí)候就返回種子模板里的“同風(fēng)格相近搭配”保證演示效果永遠(yuǎn)在線。這個(gè)策略在答辯演示時(shí)非常關(guān)鍵——現(xiàn)場(chǎng)是網(wǎng)速不穩(wěn)定、數(shù)據(jù)準(zhǔn)備不充分都可能發(fā)生有兜底方案就不會(huì)翻車。3.5 推薦理由的可解釋性設(shè)計(jì)為了講清楚“為什么推薦這套”我在生成搭配記錄的時(shí)候同步生成了一段自然語言推薦理由就是代碼里的buildReason方法。private String buildReason(Clothing base, Clothing bottom, Clothing shoes) { StringBuilder sb new StringBuilder(); sb.append(根據(jù)您選擇的).append(base.getName()); if (bottom ! null) { sb.append(推薦搭配).append(bottom.getName()) .append(兩者在).append(commonStyle(base, bottom)).append(風(fēng)格上高度契合); } if (shoes ! null) { sb.append(同時(shí)用).append(shoes.getName()).append(來提升整體完成度); } sb.append(。); return sb.toString(); }這段理由不是花架子。答辯的時(shí)候老師大概率會(huì)問“你的推薦邏輯是怎么被用戶感知的”你直接把前端頁(yè)面上展示的推薦理由指給他看再順著講一遍特征提取和相似度計(jì)算流程整個(gè)邏輯鏈就完整了。技術(shù)含量、業(yè)務(wù)完成度都有了這是很多同類畢設(shè)項(xiàng)目做不好的地方。4. SpringBoot3后端實(shí)現(xiàn)從項(xiàng)目初始化到核心接口算法思路清楚了接下來就是工程落地的部分。SpringBoot3和SpringBoot2在寫法上區(qū)別不大但有幾個(gè)關(guān)鍵點(diǎn)在你建項(xiàng)目的時(shí)候就需要留意。我按實(shí)際操作順序講。4.1 建項(xiàng)目的正確姿勢(shì)建議直接用Spring Initializrstart.spring.io生成項(xiàng)目骨架而不是自己手搭Maven結(jié)構(gòu)。選擇項(xiàng)如下ProjectMavenGradle也行但Maven更適合國(guó)內(nèi)環(huán)境資料多LanguageJavaSpring Boot3.2.x或3.3.x選正式穩(wěn)定版不要選快照版Group/Artifact根據(jù)自己的包名來比如com.example.clothingDependenciesSpring Web、Spring Data JPA、MySQL Driver、Validation、Lombok、Spring Security可選項(xiàng)如果只用JWT可以選注意一個(gè)坑SpringBoot3的javax.*包已經(jīng)全部遷移到j(luò)akarta.*了。你從網(wǎng)上復(fù)制老代碼的時(shí)候很多import javax.persistence.*會(huì)直接報(bào)錯(cuò)要改成jakarta.persistence.*。這個(gè)小坑卡了我半天網(wǎng)上大量博客寫的還是SpringBoot2的代碼復(fù)制時(shí)一定要檢查包名。pom.xml核心依賴如下dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-jpa/artifactId /dependency dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-validation/artifactId /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency /dependencies4.2 實(shí)體映射與JPA的坑Clothing實(shí)體的核心映射代碼Entity Table(name clothing) Getter Setter public class Clothing { Id GeneratedValue(strategy GenerationType.IDENTITY) private Long id; ManyToOne(fetch FetchType.LAZY) JoinColumn(name user_id) private User user; Column(nullable false) private String name; Column(nullable false) private String category; Column(nullable false) private String color; Column(nullable false) private String season; Column(nullable false) private String style; private String fit; private String imageUrl; ManyToMany(fetch FetchType.LAZY) JoinTable( name clothing_tag, joinColumns JoinColumn(name clothing_id), inverseJoinColumns JoinColumn(name tag_id) ) private ListTag tags new ArrayList(); }這里我想特別提醒一個(gè)實(shí)踐中的坑JPA的懶加載在事務(wù)外訪問關(guān)聯(lián)對(duì)象會(huì)報(bào)LazyInitializationException。最簡(jiǎn)單的解決辦法是在Service層方法上標(biāo)注Transactional保證整個(gè)方法在同一個(gè)持久化上下文里執(zhí)行。我的RecommendService方法就加了注解。如果你在Controller里直接訪問實(shí)體關(guān)聯(lián)屬性那就等著報(bào)錯(cuò)吧。還有一點(diǎn)為了和前面的算法配合Clothing實(shí)體里我加了一個(gè)簡(jiǎn)化設(shè)計(jì)的fit字段表示版型修身、寬松、標(biāo)準(zhǔn)這個(gè)字段在相似度計(jì)算時(shí)是一個(gè)重要的區(qū)分維度。兩件衣服如果顏色、風(fēng)格都一樣但一個(gè)是修身一個(gè)是寬松搭起來效果可能完全相反所以推薦時(shí)最好先看版型匹配度。4.3 推薦接口的RESTful設(shè)計(jì)推薦接口我設(shè)計(jì)成GET請(qǐng)求語義清晰方便前端直接調(diào)用展示RestController RequestMapping(/api/recommend) public class RecommendController { private final RecommendService recommendService; public RecommendController(RecommendService recommendService) { this.recommendService recommendService; } /** * 傳入服裝ID返回搭配方案 */ GetMapping(/outfit/{clothingId}) public ResultOutfitVO recommendOutfit(PathVariable Long clothingId) { // 內(nèi)部調(diào)用推薦服務(wù)生成搭配 OutfitVO outfitVO recommendService.generateOutfit(clothingId); return Result.success(outfitVO); } /** * 獲取今日推薦 */ GetMapping(/daily) public ResultListOutfitVO dailyOutfit() { return Result.success(recommendService.dailyOutfit()); } }Result是我封裝的統(tǒng)一返回體里面包含code、message、data三個(gè)字段。這個(gè)包裝不是為了炫技而是讓前端能統(tǒng)一處理錯(cuò)誤狀態(tài)不用到處去try-catch網(wǎng)絡(luò)異常。Service層的代碼組織上我建議把“算法邏輯”和“數(shù)據(jù)持久化”分開。推薦生成部分放在RecommendService搭配記錄的查詢和收藏放在OutfitService兩個(gè)Service互相獨(dú)立。這樣后面你想調(diào)推薦算法只改RecommendService就行不會(huì)誤傷其他業(yè)務(wù)。4.4 靜態(tài)資源與文件上傳服裝肯定要配圖。畢設(shè)項(xiàng)目我不建議自己搞OSS對(duì)象存儲(chǔ)直接用本地文件存儲(chǔ)就行。在application.yml里配置靜態(tài)資源映射spring: web: resources: static-locations: classpath:/static/,file:${upload.path} servlet: multipart: max-file-size: 5MB max-request-size: 20MB upload: path: D:/clothing-upload/這樣前端訪問http://localhost:8080/images/xxx.jpg就能直接映射到磁盤目錄。如果部署到云服務(wù)器把upload.path改成/home/ubuntu/clothing-upload/即可。Linux環(huán)境要注意目錄存在權(quán)限否則文件上傳會(huì)失敗這個(gè)坑我在答辯前夜遇到過——服務(wù)器上目錄不存在SpringBoot不會(huì)主動(dòng)給你建文件上傳直接500。5. Vue3前端三塊核心界面的實(shí)現(xiàn)思路前端不是從零手寫我用的是Vue3 Vite Element Plus Pinia這套組合。搭建過程比較順重點(diǎn)講三塊核心界面的實(shí)現(xiàn)思路和代碼組織方式。5.1 項(xiàng)目初始化與關(guān)鍵配置用Vite創(chuàng)建Vue3項(xiàng)目npm create vitelatest clothing-frontend -- --template vue cd clothing-frontend npm install npm install element-plus element-plus/icons-vue pinia axios vue-routerElement Plus的引入分成全量引入和按需引入兩種。畢設(shè)項(xiàng)目我直接全量引入了省事。但如果你想在簡(jiǎn)歷里體現(xiàn)對(duì)性能的在意可以用unplugin-auto-import和unplugin-vue-components實(shí)現(xiàn)按需引入這里我不過多展開知道有這條路就行。前端路由用Vue Router分三個(gè)主頁(yè)面衣櫥管理、AI搭配推薦、搭配日志。路由配置簡(jiǎn)單關(guān)鍵是前端和后端的接口聯(lián)調(diào)。聯(lián)調(diào)的第一步是解決跨域。開發(fā)環(huán)境下Vite代理配置在vite.config.jsexport default defineConfig({ plugins: [vue()], server: { port: 3000, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } })這個(gè)配置讓前端的/api請(qǐng)求自動(dòng)轉(zhuǎn)發(fā)到后端8080端口同時(shí)瀏覽器的CORS請(qǐng)求就不會(huì)出來了。如果是生產(chǎn)部署就需要在后端寫一個(gè)跨域配置類把前端域名放進(jìn)去。開發(fā)環(huán)境用代理是最省事的方式。Axios的封裝上我習(xí)慣在src/utils/request.js里統(tǒng)一配置baseURL和請(qǐng)求攔截器import axios from axios import { ElMessage } from element-plus import { useUserStore } from ../stores/user const request axios.create({ baseURL: /api, timeout: 15000 }) request.interceptors.request.use(config { const userStore useUserStore() if (userStore.token) { config.headers.Authorization Bearer ${userStore.token} } return config }) request.interceptors.response.use( response response.data, error { ElMessage.error(error.response?.data?.message || 請(qǐng)求失敗) return Promise.reject(error) } ) export default request5.2 衣櫥管理頁(yè)卡片網(wǎng)格與標(biāo)簽選擇器衣櫥頁(yè)是用戶操作的基礎(chǔ)用Element Plus的el-cardel-upload實(shí)現(xiàn)。一件服裝卡片包含圖片、名稱、分類、標(biāo)簽、操作按鈕設(shè)為搭配基礎(chǔ)款、編輯、刪除。核心是“添加服裝”的表單里面有個(gè)標(biāo)簽多選器template el-form :modelform label-width80px el-form-item label服裝名稱 el-input v-modelform.name / /el-form-item el-form-item label分類 el-select v-modelform.category el-option label上裝 value上裝 / el-option label下裝 value下裝 / el-option label連衣裙 value連衣裙 / el-option label外套 value外套 / el-option label鞋靴 value鞋靴 / el-option label配飾 value配飾 / /el-select /el-form-item el-form-item label風(fēng)格標(biāo)簽 el-select v-modelform.tags multiple el-option v-fortag in tagOptions :keytag.id :labeltag.name :valuetag.id / /el-select /el-form-item /el-form /template這里的邏輯要點(diǎn)是風(fēng)格標(biāo)簽選項(xiàng)應(yīng)該從后端接口動(dòng)態(tài)獲取而不是寫死在前端。因?yàn)楣芾韱T可能隨時(shí)往字典表里添加新標(biāo)簽如果前端寫死了后端改了前端不更新就會(huì)出現(xiàn)“后臺(tái)加了標(biāo)簽前臺(tái)選不到”的割裂情況。從后端獲取的接口是GET /api/tag/list返回全部標(biāo)簽字典。5.3 AI搭配推薦頁(yè)核心交互設(shè)計(jì)這是整個(gè)前端最核心的頁(yè)面。交互流程是用戶先選擇一件衣櫥里的單品比如選擇了一件白色襯衫點(diǎn)擊“AI智能搭配”系統(tǒng)就會(huì)調(diào)用推薦接口把搭配結(jié)果展示在下方。頁(yè)面布局我用了左右分欄左側(cè)是衣櫥單品列表點(diǎn)擊選中右側(cè)是推薦結(jié)果區(qū)從上到下展示“上裝搭配→下裝搭配→鞋靴→推薦理由”。推薦結(jié)果區(qū)用了卡片式展示template div classrecommend-container h3搭配推薦結(jié)果/h3 div classoutfit-row el-card v-foritem in outfitItems :keyitem.category classoutfit-item img :srcitem.imageUrl :altitem.name / div classitem-name{{ item.name }}/div div classitem-tags{{ item.tagsText }}/div div classmatch-score匹配度{{ item.matchScore }}/div /el-card /div el-alert typesuccess :titlerecommendReason :closablefalse / el-button typeprimary clicksaveFavorite收藏這套搭配/el-button /div /template這里值得說的是“匹配度”這個(gè)展示項(xiàng)。它直接來自后端算法計(jì)算出的余弦相似度并轉(zhuǎn)換成百分比展示。這個(gè)數(shù)字能非常直觀地向觀眾證明“這個(gè)推薦不是瞎猜的是有算法在背后支撐的”演示效果極好。5.4 搭配日志與收藏頁(yè)搭配日志頁(yè)展示歷史生成過的搭配記錄每一組搭配都有時(shí)間、搭配方案、當(dāng)時(shí)的推薦理由并提供“再次收藏”和“刪除記錄”操作。這個(gè)頁(yè)面是后端outfit表的直接映射前端邏輯不復(fù)雜用el-table或卡片時(shí)間線就能做得好看。Pinia作為全局狀態(tài)管理我主要用于用戶登錄信息、Token、以及“當(dāng)前選中的搭配”這個(gè)跨頁(yè)面共享狀態(tài)。比如用戶在推薦頁(yè)生成了一個(gè)搭配收藏時(shí)需要把搭配數(shù)據(jù)傳給收藏接口如果不用狀態(tài)管理就要通過路由參數(shù)傳會(huì)比較狼狽。6. 演示和答辯環(huán)節(jié)最容易翻車的細(xì)節(jié)項(xiàng)目做完了代碼能跑了但離“高分畢設(shè)”還差一步——演示和答辯。這一步很多人栽跟頭不是因?yàn)轫?xiàng)目不好而是因?yàn)闇?zhǔn)備不充分。下面這幾條全是我親身踩過或者看別人踩過的坑。6.1 演示數(shù)據(jù)的準(zhǔn)備是門技術(shù)活千萬不能隨便找?guī)讖堃路D片就往系統(tǒng)里塞。演示數(shù)據(jù)需要滿足三個(gè)條件圖片風(fēng)格統(tǒng)一、屬性標(biāo)簽完整、分類覆蓋足夠。我的經(jīng)驗(yàn)是準(zhǔn)備30件衣服覆蓋上裝、下裝、外套、鞋靴、配飾五類。風(fēng)格上至少覆蓋通勤、休閑、運(yùn)動(dòng)、約會(huì)四個(gè)場(chǎng)景。每件衣服的標(biāo)簽要仔細(xì)打比如“白色”“寬松”“棉質(zhì)”“通勤”。只有數(shù)據(jù)質(zhì)量高推薦算法才能跑出讓人眼前一亮的效果。我測(cè)試的時(shí)候就發(fā)現(xiàn)如果數(shù)據(jù)里只有“黑色”“白色”兩種顏色冷色系和暖色系的區(qū)分就完全失效了推薦結(jié)果的多樣性會(huì)大打折扣。還有一個(gè)小技巧演示之前先把“歷史搭配記錄”里預(yù)置幾條數(shù)據(jù)這樣打開搭配日志頁(yè)時(shí)頁(yè)面不會(huì)空空的視覺上非常加分。6.2 現(xiàn)場(chǎng)演示的三大翻車點(diǎn)第一是圖片加載。如果你用本地靜態(tài)資源路徑打包部署后圖片路徑很可能會(huì)漂移。解決方法是后端返回圖片時(shí)返回完整訪問路徑比如http://localhost:8080/images/xxx.jpg而不是只返回/images/xxx.jpg這樣無論前端怎么部署都能正確拼接。當(dāng)然如果你在Application.yml里配置了context-path那拼接的時(shí)候就要多帶一層前綴。第二是接口超時(shí)。首次調(diào)用推薦接口時(shí)如果數(shù)據(jù)庫(kù)里服裝數(shù)據(jù)量增大到幾百件全量遍歷相似度計(jì)算可能有點(diǎn)慢。而前端Axios的timeout如果設(shè)的是5秒很容易超時(shí)。我前端統(tǒng)一設(shè)成了15秒同時(shí)后端在推薦接口上加了Cacheable緩存把“同一種基礎(chǔ)單品”的推薦結(jié)果緩存起來第二次請(qǐng)求就直接走緩存速度快到飛起。第三是Token過期。演示現(xiàn)場(chǎng)通常是打開的瀏覽器一直放著等正式演示時(shí)JWT可能已經(jīng)過期了。結(jié)果一調(diào)用接口后端返回401前端跳轉(zhuǎn)到登錄頁(yè)場(chǎng)面很尷尬。解決辦法很簡(jiǎn)單演示前刷新一下頁(yè)面重新登錄或者把后端的token過期時(shí)間設(shè)長(zhǎng)一點(diǎn)。我在代碼里把JWT過期時(shí)間默認(rèn)設(shè)置為24小時(shí)足夠覆蓋整場(chǎng)答辯。6.3 答辯時(shí)怎么講清楚推薦原理答辯老師不一定會(huì)看你代碼但一定會(huì)問“你的推薦算法是怎么工作的”。我準(zhǔn)備了一個(gè)三句話版本的答案“我先給每件服裝構(gòu)建一個(gè)特征向量向量里的維度包括顏色、季節(jié)、風(fēng)格、版型等屬性用0和1表示是否具備該特征然后我計(jì)算兩件服裝特征向量的余弦相似度相似度越高說明風(fēng)格越匹配最后通過規(guī)則引擎過濾掉不合理的組合比如上裝不跟上裝配再按相似度從高到低推薦出最合適的下裝、鞋靴和外套?！边@段話里有“特征向量”“余弦相似度”“規(guī)則引擎”三個(gè)技術(shù)名詞每個(gè)詞都能展開講每個(gè)展開的細(xì)節(jié)都對(duì)得上項(xiàng)目代碼。老師不管問哪個(gè)方向你都有話可接。這就是“可解釋推薦”在畢設(shè)答辯里的最大價(jià)值。6.4 萬一推薦結(jié)果不合理怎么辦如果演示現(xiàn)場(chǎng)推薦出了明顯不合理的搭配千萬別慌更別說“系統(tǒng)有點(diǎn)小問題”。我準(zhǔn)備了一套應(yīng)急說法“這套推薦是基于當(dāng)前衣櫥數(shù)據(jù)的全局最優(yōu)解但搭配本身有主觀性所以我們系統(tǒng)還設(shè)計(jì)了用戶反饋機(jī)制您可以點(diǎn)擊‘換一套’來獲得備選方案也可以手動(dòng)調(diào)整單品組合?！比缓箜槃?shì)演示一下“換一套”功能反而把劣勢(shì)變成了展示彈性和交互完整性的機(jī)會(huì)。這就是為什么我做推薦結(jié)果頁(yè)時(shí)故意保留了“換一套”的按鈕——它不只是功能更是答辯時(shí)的安全墊。7. 一套可復(fù)用的擴(kuò)展思路如果你做完了以上內(nèi)容還想再進(jìn)一步這里有幾個(gè)擴(kuò)展方向都不難實(shí)現(xiàn)但能顯著提升項(xiàng)目上限。第一個(gè)是天氣聯(lián)動(dòng)推薦。接入第三方天氣API根據(jù)溫度、天氣情況調(diào)整推薦策略下雨推薦防水鞋靴天冷推薦厚外套。這個(gè)擴(kuò)展邏輯清晰且實(shí)現(xiàn)簡(jiǎn)單但在答辯時(shí)能讓人眼前一亮。第二個(gè)是著裝記錄與智能統(tǒng)計(jì)。記錄用戶每天的穿著一個(gè)月后展示用戶的風(fēng)格偏好、穿著頻率圖表。這就引入了數(shù)據(jù)可視化和用戶畫像的概念可以讓項(xiàng)目從“工具型”升級(jí)為“服務(wù)型”。第三個(gè)是搭配社區(qū)。用戶可以分享自己的搭配方案到公共區(qū)域其他用戶可以點(diǎn)贊、評(píng)論。這個(gè)擴(kuò)展如果做出來你的項(xiàng)目就從一個(gè)單機(jī)工具變成了一個(gè)社交產(chǎn)品工作量會(huì)大很多但帶來的項(xiàng)目分量也不可同日而語。我自己做項(xiàng)目的時(shí)候沒時(shí)間實(shí)現(xiàn)全部擴(kuò)展但我建議學(xué)有余力的同學(xué)至少做第一個(gè)“天氣聯(lián)動(dòng)”。它前面有現(xiàn)成的API后面接的是推薦規(guī)則的動(dòng)態(tài)調(diào)整改動(dòng)范圍很小卻能讓答辯老師感覺到你具備產(chǎn)品思維而不僅僅是會(huì)寫接口。最后再分享一點(diǎn)個(gè)人體會(huì)做這個(gè)系統(tǒng)的過程中我最大的收獲其實(shí)不是技術(shù)本身而是學(xué)會(huì)了一種“先想清楚再動(dòng)手”的習(xí)慣。從選題、功能定義、數(shù)據(jù)建模到算法選型每一步都是先回答“為什么”再考慮“怎么做”。如果你也在做類似的畢設(shè)項(xiàng)目我建議你拿這個(gè)思路去對(duì)照自己的方案你的每一張表、每一個(gè)接口、每一段算法邏輯是不是都能回答出“為什么這樣設(shè)計(jì)”如果每個(gè)問題都能答上來你的項(xiàng)目就不僅僅是一份作業(yè)而是一件拿得出手的作品。本文還有配套的精品資源點(diǎn)擊獲取