簡介這是一套面向計算機專業本科生的2025屆畢業設計/課程設計實戰項目聚焦服裝搭配推薦場景解決用戶個性化穿搭決策效率低、后臺管理缺乏系統化工具等實際問題適用于Java全棧技術學習與工程實踐。資源包共6個文件含Vue3SpringBoot3完整源碼zip、MySQL8數據庫腳本sql、系統需求文檔docx、全流程操作錄屏mp4及返修版本源碼與文檔zip總大小87.05MB結構清晰、模塊完整覆蓋前后端分離開發典型流程。已有64人下載學習適合掌握基礎Java、Vue.js和SpringBoot的學生開展二次開發或答辯復現。讀者可直接部署運行通過錄屏快速掌握后臺商品/搭配模板管理、前臺瀏覽推薦、用戶交互等核心功能并結合需求文檔理解業務建模邏輯返修材料更便于對照學習常見優化點與代碼規范改進路徑。 從衣櫥里挑衣服這件事很多人每天都要糾結十分鐘起步——這件上衣配哪條褲子這雙鞋能不能搭這條裙子顏色會不會沖突風格是不是統一如果你仔細想想會發現這其實是一個典型的“信息過載決策困難”問題。也正是這個痛點讓我在2025年做畢業設計的時候毫不猶豫地選了服裝搭配推薦系統這個方向技術棧用了SpringBoot3 Vue.js3。先擺個結論這套系統做出來之后不只是“畢設能過”的水平。它既能當完整的電商/穿搭類項目來展示功能又能把“推薦算法”作為核心亮點去答辯同時前后端技術棧又踩在2025年的主流節點上。對于需要一個既有技術深度、又有實際應用場景、還不容易和同學撞車的畢設題目來說這是一個很難得的選擇。這篇文章我會把這個項目的完整思路拆開講從選題邏輯、功能設計、數據庫建模到推薦算法怎么落地成真正的Java代碼再到Vue3前端怎么做搭配展示最后是答辯和演示時最容易踩的坑。整篇文章不是泛泛的介紹而是照著能復現、能運行、能答辯的標準來寫。1. 為什么選“服裝搭配推薦”這個方向從痛點倒推選題每年畢業設計選題的時候總能刷到一批“經典款”題目XXX管理系統、XXX商城、XXX論壇。不是說這些題目不行而是撞車率太高而且功能做完就是標準的增刪改查答辯的時候老師問一句“你的難點在哪里”場面會變得很安靜。服裝搭配推薦系統能在這種大環境里跳出來核心原因是它站得住兩個維度。第一個維度是真實場景。根據我對周圍人的觀察絕大多數人的衣櫥里并不缺衣服缺的是“怎么把它們組合起來”的能力。買的時候覺得好看回家發現不知道怎么搭最后衣服要么壓箱底、要么永遠穿那兩三套。所以“搭配推薦”解決的不僅是“找相似商品”而是“幫你做決策”的問題。這個場景放在哪個時代都成立比純粹賣東西的商城系統多了一層用戶價值。第二個維度是技術難度剛好卡在畢設的“甜點區”。它比純CRUD復雜但又沒有復雜到讓人做不完。推薦邏輯可以用規則引擎、可以用相似度計算、也可以加一點協同過濾的變體算法的解釋成本低演示效果好。這個度是非常重要的——太簡單了沒有亮點太難了做到一半心態崩掉。再看技術棧的選擇。之所以選SpringBoot3 Vue3而不是還在到處流傳的SpringBoot2 Vue2有兩個方面的考慮一是2025年這個時間點上SpringBoot3已經非常成熟。它基于JDK17底層是Spring Framework 6性能、安全性、生態都對得上當前工業界的新項目標準。現在出去找工作簡歷上寫SpringBoot2反而會讓面試官覺得技術棧更新不及時。既然畢設是一個能寫進簡歷的項目那技術棧最好是當前企業正在用的。二是Vue3配合Vite構建工具開發體驗比Vue2的Webpack方案好很多。Composition API在邏輯復用、組織代碼這件事上比Options API更舒服Element Plus組件庫也很成熟。前端部分做衣櫥管理、搭配展示這類界面正好能把Vue3的優勢發揮出來。為了讓你直觀感受技術選型的合理性我做了個對比表對比維度SpringBoot2 Vue2SpringBoot3 Vue3JDK要求JDK8/11JDK17支持新語法和新特性底層框架Spring Framework 5Spring Framework 6性能優化明顯構建工具Webpack為主Vite冷啟動速度快一個量級前端狀態方案VuexPiniaTypeScript支持更好組件庫Element UIElement Plus答辯面試優勢常規水平能體現2025年技術敏感度所以這個選題的核心邏輯是用真實的用戶決策痛點作為項目外殼用“推薦算法主流前后端框架”作為技術內核。外行看著覺得有意思內行看著覺得有深度老師看著覺得工作量飽滿。2. 系統功能骨架與數據庫設計先把“賣什么”定清楚動手寫代碼之前我花了兩天時間畫功能腦圖和設計稿。這個階段最忌諱的是“上來就寫Controller”因為服裝搭配這個領域里物品屬性、標簽體系、搭配規則之間是有依賴關系的不提前定好數據模型后面改起來會非常痛。2.1 三種角色與核心業務閉環我先把這個系統涉及的角色和業務閉環講清楚這部分也是后面數據庫建模的依據。系統分了三種角色游客只能看首頁和熱門搭配用來撐起項目展示面的“公開區域”。注冊用戶系統的核心使用角色。可以在衣櫥里上傳衣服、完善屬性標簽、發起搭配請求、收藏滿意的搭配、查看歷史搭配記錄。管理員負責服裝庫的維護、標簽字典的管理、用戶內容審核。畢設里這一塊不需要做得太重但要有否則“后臺管理功能”這個基本盤就丟了。核心業務閉環是一條很清楚的鏈路用戶上傳/添加服裝 → 維護服裝標簽屬性 → 發起搭配請求 → 系統生成搭配方案 → 用戶收藏或反饋 → 系統記錄日志并優化后續推薦。這條鏈路里最關鍵的實體是“服裝”而服裝的關鍵又在于“標簽屬性”。為什么不是直接在服裝表里寫死十幾個字段比如顏色、風格、季節這個我后面講數據庫設計的時候詳細說。2.2 數據庫表結構設計數據庫我用的MySQLSpring Data JPA做ORM。核心表一共六張用戶表、服裝表、標簽表、服裝標簽關聯表、搭配記錄表、搭配收藏表。額外還有一套室內裝飾、穿著場景的字典表但那是擴展用的不影響主流程。表名核心字段說明userid, username, password, nickname, avatar用戶信息clothingid, user_id, name, category, image_url, color, season, style, occasion, fit服裝單品簡化版屬性tagid, name, type標簽字典比如“通勤”“小清新”“暖色系”clothing_tagclothing_id, tag_id服裝和標簽多對多關聯outfitid, user_id, top_id, bottom_id, shoes_id, outer_id, reason, create_time搭配記錄一條記錄存一套完整方案outfit_favoriteid, user_id, outfit_id, create_time收藏功能這里我想重點說三個設計決策都是實際開發中踩過或者思考過的第一為什么服裝表既要有獨立屬性字段又要有關聯標簽表獨立屬性字段color、season、style等是為了滿足“條件篩選”這種高性能查詢比如用戶想看“夏天通勤連衣裙”標簽表是為了滿足“柔性擴展”比如以后想加一個“適合約會”的標簽改字典就行不用改表結構。兩者結合既能跑推薦算法又能做篩選靈活性最高。第二為什么搭配記錄單獨建一張outfit表而不是每次臨時算推薦算法的計算是有開銷的而且用戶對同一套搭配可能反復查看。把生成好的搭配方案存下來好處是歷史記錄查詢極快也在數據結構上天然形成了“用戶的行為日志”——這是后續優化推薦效果的依據。第三category字段用String而不是用外鍵關聯分類表加分類表更規范但畢設場景里分類就那么幾個上裝、下裝、裙子、外套、鞋靴、配飾用枚舉字符串反而簡單直觀。你要是為了在論文里多寫一張表也可以拆出去但我個人覺得沒必要這是典型的“過度建模”。2.3 接口清單規劃數據庫定完接口基本就出來了。我按照RESTful風格整理了一下核心接口不算多模塊方法路徑說明用戶POST/api/user/register注冊用戶POST/api/user/login登錄返回JWT服裝GET/api/clothing/list當前用戶的衣櫥列表服裝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管理員分頁查看服裝庫這套接口清單背后有一個隱藏設計邏輯所有推薦相關的路徑都收斂在/api/recommend下和普通CRUD接口隔離開來。這樣做是為了在代碼層面清晰地告訴閱讀者——哪些是普通業務哪些是算法核心答辯的時候講代碼結構會非常清爽。3. 推薦算法落地從余弦相似度到可解釋推薦這部分是整個系統的靈魂也是很多同學最容易犯怵的地方。其實沒必要慌我先把算法選擇的邏輯講清楚你就知道為什么我會放棄那些聽起來高大上的方案。3.1 為什么我沒選“協同過濾”當主力算法協同過濾是推薦系統教材上的經典內容分成基于用戶的UserCF和基于物品的ItemCF。但放在畢設這個場景下有一個繞不開的問題數據稀疏。協同過濾本質上是“物以類聚、人以群分”它需要大量用戶行為數據才能發揮作用。你一個畢設項目哪來的幾萬用戶用戶不多行為矩陣稀稀拉拉算出來的相似度根本沒有統計意義演示的時候效果完全不可控。更重要的是協同過濾是黑盒模型你很難跟答辯老師解釋清楚“為什么推薦了這一套搭配”。萬一老師追著問具體案例你只能反復說“因為其他用戶也這樣選擇”——這個解釋力在答辯現場是很弱的。3.2 適合畢設的解法基于內容特征的搭配評分我最后用的方案是基于服裝內容特征 規則約束 余弦相似度打分屬于混合式推薦。它比純協同過濾的可解釋性更強比純規則的硬編碼更有技術含量而且效果完全可控。核心思想分三層規則層先做硬約束比如“外套不能推薦成內搭”“夏季上裝優先配薄款下裝”“西裝外套優先配通勤風單品”。這些規則用代碼if-else實現過濾掉明顯不合理的搭配。特征層每件服裝根據屬性標簽轉成一個特征向量。比如一件“白色、夏季、通勤風、修身上裝”它的特征向量就是{白色:1, 夏季:1, 通勤:1, 修身:1}顏色、季節、風格、版型這些維度組成一個多值編碼的boolean向量。評分層計算候選單品與推薦目標之間的余弦相似度再疊加規則權重得到最終得分按分數排序取TopN。3.3 特征向量構建與余弦相似度計算這里我直接把核心代碼邏輯貼出來代碼是Java寫的用的SpringBoot3環境。先定義服裝的特征提取器public class ClothingFeatureExtractor { /** * 將服裝實體轉為特征向量。 * 這里用了LinkedHashMap保證特征順序一致便于后續計算。 */ public static MapString, Double extract(Clothing clothing) { MapString, Double vector new LinkedHashMap(); // 基礎屬性編碼 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); } // 關聯標簽編碼 if (clothing.getTags() ! null) { for (Tag tag : clothing.getTags()) { vector.put(tag_ tag.getName().toLowerCase(), 1.0); } } return vector; } }這里有個關鍵細節把“類別”也編碼進特征向量了。這個操作會讓“上裝”和“下裝”天然擁有不同的向量簽名避免推薦出同類單品互搭的尷尬局面。跑相似度計算時同類服裝的相似度矩陣也能正常使用但生成搭配時會加類別約束不讓上裝配上裝。然后是余弦相似度計算器和搭配推薦服務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; } /** * 給定一件單品推薦一套搭配。 * 流程先按類別硬約束過濾再計算相似度最后返回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. 對候選單品按相似度打分 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. 按分類取最優下裝、鞋/配飾、外套作為可選 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我單獨提出來一個規則引擎類里面全是硬約束規則。比如“上衣不跟上衣搭配”“顏色對比度不能太刺眼”“風格標簽至少有一個重合”。這些規則看著簡單但它們是整個推薦方案里“防呆”的關鍵。沒有這些硬約束余弦相似度再高也可能推出一套“紅衣配紅褲”的春節聯歡會造型。3.4 冷啟動與兜底策略畢設項目沒有真實用戶數據冷啟動是必然要面對的。我的處理方式是系統初始內置一批“專家搭配模板”作為種子數據大概20套左右。這些模板是我自己按通勤、休閑、約會、運動四個場景整理的每套模板含有基礎單品組合和推薦理由。當計算出的相似度分數太低比如低于閾值0.1或者衣櫥里根本沒有合適搭配的時候就返回種子模板里的“同風格相近搭配”保證演示效果永遠在線。這個策略在答辯演示時非常關鍵——現場是網速不穩定、數據準備不充分都可能發生有兜底方案就不會翻車。3.5 推薦理由的可解釋性設計為了講清楚“為什么推薦這套”我在生成搭配記錄的時候同步生成了一段自然語言推薦理由就是代碼里的buildReason方法。private String buildReason(Clothing base, Clothing bottom, Clothing shoes) { StringBuilder sb new StringBuilder(); sb.append(根據您選擇的).append(base.getName()); if (bottom ! null) { sb.append(推薦搭配).append(bottom.getName()) .append(兩者在).append(commonStyle(base, bottom)).append(風格上高度契合); } if (shoes ! null) { sb.append(同時用).append(shoes.getName()).append(來提升整體完成度); } sb.append(。); return sb.toString(); }這段理由不是花架子。答辯的時候老師大概率會問“你的推薦邏輯是怎么被用戶感知的”你直接把前端頁面上展示的推薦理由指給他看再順著講一遍特征提取和相似度計算流程整個邏輯鏈就完整了。技術含量、業務完成度都有了這是很多同類畢設項目做不好的地方。4. SpringBoot3后端實現從項目初始化到核心接口算法思路清楚了接下來就是工程落地的部分。SpringBoot3和SpringBoot2在寫法上區別不大但有幾個關鍵點在你建項目的時候就需要留意。我按實際操作順序講。4.1 建項目的正確姿勢建議直接用Spring Initializrstart.spring.io生成項目骨架而不是自己手搭Maven結構。選擇項如下ProjectMavenGradle也行但Maven更適合國內環境資料多LanguageJavaSpring Boot3.2.x或3.3.x選正式穩定版不要選快照版Group/Artifact根據自己的包名來比如com.example.clothingDependenciesSpring Web、Spring Data JPA、MySQL Driver、Validation、Lombok、Spring Security可選項如果只用JWT可以選注意一個坑SpringBoot3的javax.*包已經全部遷移到jakarta.*了。你從網上復制老代碼的時候很多import javax.persistence.*會直接報錯要改成jakarta.persistence.*。這個小坑卡了我半天網上大量博客寫的還是SpringBoot2的代碼復制時一定要檢查包名。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 實體映射與JPA的坑Clothing實體的核心映射代碼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(); }這里我想特別提醒一個實踐中的坑JPA的懶加載在事務外訪問關聯對象會報LazyInitializationException。最簡單的解決辦法是在Service層方法上標注Transactional保證整個方法在同一個持久化上下文里執行。我的RecommendService方法就加了注解。如果你在Controller里直接訪問實體關聯屬性那就等著報錯吧。還有一點為了和前面的算法配合Clothing實體里我加了一個簡化設計的fit字段表示版型修身、寬松、標準這個字段在相似度計算時是一個重要的區分維度。兩件衣服如果顏色、風格都一樣但一個是修身一個是寬松搭起來效果可能完全相反所以推薦時最好先看版型匹配度。4.3 推薦接口的RESTful設計推薦接口我設計成GET請求語義清晰方便前端直接調用展示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) { // 內部調用推薦服務生成搭配 OutfitVO outfitVO recommendService.generateOutfit(clothingId); return Result.success(outfitVO); } /** * 獲取今日推薦 */ GetMapping(/daily) public ResultListOutfitVO dailyOutfit() { return Result.success(recommendService.dailyOutfit()); } }Result是我封裝的統一返回體里面包含code、message、data三個字段。這個包裝不是為了炫技而是讓前端能統一處理錯誤狀態不用到處去try-catch網絡異常。Service層的代碼組織上我建議把“算法邏輯”和“數據持久化”分開。推薦生成部分放在RecommendService搭配記錄的查詢和收藏放在OutfitService兩個Service互相獨立。這樣后面你想調推薦算法只改RecommendService就行不會誤傷其他業務。4.4 靜態資源與文件上傳服裝肯定要配圖。畢設項目我不建議自己搞OSS對象存儲直接用本地文件存儲就行。在application.yml里配置靜態資源映射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就能直接映射到磁盤目錄。如果部署到云服務器把upload.path改成/home/ubuntu/clothing-upload/即可。Linux環境要注意目錄存在權限否則文件上傳會失敗這個坑我在答辯前夜遇到過——服務器上目錄不存在SpringBoot不會主動給你建文件上傳直接500。5. Vue3前端三塊核心界面的實現思路前端不是從零手寫我用的是Vue3 Vite Element Plus Pinia這套組合。搭建過程比較順重點講三塊核心界面的實現思路和代碼組織方式。5.1 項目初始化與關鍵配置用Vite創建Vue3項目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的引入分成全量引入和按需引入兩種。畢設項目我直接全量引入了省事。但如果你想在簡歷里體現對性能的在意可以用unplugin-auto-import和unplugin-vue-components實現按需引入這里我不過多展開知道有這條路就行。前端路由用Vue Router分三個主頁面衣櫥管理、AI搭配推薦、搭配日志。路由配置簡單關鍵是前端和后端的接口聯調。聯調的第一步是解決跨域。開發環境下Vite代理配置在vite.config.jsexport default defineConfig({ plugins: [vue()], server: { port: 3000, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } })這個配置讓前端的/api請求自動轉發到后端8080端口同時瀏覽器的CORS請求就不會出來了。如果是生產部署就需要在后端寫一個跨域配置類把前端域名放進去。開發環境用代理是最省事的方式。Axios的封裝上我習慣在src/utils/request.js里統一配置baseURL和請求攔截器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 || 請求失敗) return Promise.reject(error) } ) export default request5.2 衣櫥管理頁卡片網格與標簽選擇器衣櫥頁是用戶操作的基礎用Element Plus的el-cardel-upload實現。一件服裝卡片包含圖片、名稱、分類、標簽、操作按鈕設為搭配基礎款、編輯、刪除。核心是“添加服裝”的表單里面有個標簽多選器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風格標簽 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這里的邏輯要點是風格標簽選項應該從后端接口動態獲取而不是寫死在前端。因為管理員可能隨時往字典表里添加新標簽如果前端寫死了后端改了前端不更新就會出現“后臺加了標簽前臺選不到”的割裂情況。從后端獲取的接口是GET /api/tag/list返回全部標簽字典。5.3 AI搭配推薦頁核心交互設計這是整個前端最核心的頁面。交互流程是用戶先選擇一件衣櫥里的單品比如選擇了一件白色襯衫點擊“AI智能搭配”系統就會調用推薦接口把搭配結果展示在下方。頁面布局我用了左右分欄左側是衣櫥單品列表點擊選中右側是推薦結果區從上到下展示“上裝搭配→下裝搭配→鞋靴→推薦理由”。推薦結果區用了卡片式展示template div classrecommend-container h3搭配推薦結果/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這里值得說的是“匹配度”這個展示項。它直接來自后端算法計算出的余弦相似度并轉換成百分比展示。這個數字能非常直觀地向觀眾證明“這個推薦不是瞎猜的是有算法在背后支撐的”演示效果極好。5.4 搭配日志與收藏頁搭配日志頁展示歷史生成過的搭配記錄每一組搭配都有時間、搭配方案、當時的推薦理由并提供“再次收藏”和“刪除記錄”操作。這個頁面是后端outfit表的直接映射前端邏輯不復雜用el-table或卡片時間線就能做得好看。Pinia作為全局狀態管理我主要用于用戶登錄信息、Token、以及“當前選中的搭配”這個跨頁面共享狀態。比如用戶在推薦頁生成了一個搭配收藏時需要把搭配數據傳給收藏接口如果不用狀態管理就要通過路由參數傳會比較狼狽。6. 演示和答辯環節最容易翻車的細節項目做完了代碼能跑了但離“高分畢設”還差一步——演示和答辯。這一步很多人栽跟頭不是因為項目不好而是因為準備不充分。下面這幾條全是我親身踩過或者看別人踩過的坑。6.1 演示數據的準備是門技術活千萬不能隨便找幾張衣服圖片就往系統里塞。演示數據需要滿足三個條件圖片風格統一、屬性標簽完整、分類覆蓋足夠。我的經驗是準備30件衣服覆蓋上裝、下裝、外套、鞋靴、配飾五類。風格上至少覆蓋通勤、休閑、運動、約會四個場景。每件衣服的標簽要仔細打比如“白色”“寬松”“棉質”“通勤”。只有數據質量高推薦算法才能跑出讓人眼前一亮的效果。我測試的時候就發現如果數據里只有“黑色”“白色”兩種顏色冷色系和暖色系的區分就完全失效了推薦結果的多樣性會大打折扣。還有一個小技巧演示之前先把“歷史搭配記錄”里預置幾條數據這樣打開搭配日志頁時頁面不會空空的視覺上非常加分。6.2 現場演示的三大翻車點第一是圖片加載。如果你用本地靜態資源路徑打包部署后圖片路徑很可能會漂移。解決方法是后端返回圖片時返回完整訪問路徑比如http://localhost:8080/images/xxx.jpg而不是只返回/images/xxx.jpg這樣無論前端怎么部署都能正確拼接。當然如果你在Application.yml里配置了context-path那拼接的時候就要多帶一層前綴。第二是接口超時。首次調用推薦接口時如果數據庫里服裝數據量增大到幾百件全量遍歷相似度計算可能有點慢。而前端Axios的timeout如果設的是5秒很容易超時。我前端統一設成了15秒同時后端在推薦接口上加了Cacheable緩存把“同一種基礎單品”的推薦結果緩存起來第二次請求就直接走緩存速度快到飛起。第三是Token過期。演示現場通常是打開的瀏覽器一直放著等正式演示時JWT可能已經過期了。結果一調用接口后端返回401前端跳轉到登錄頁場面很尷尬。解決辦法很簡單演示前刷新一下頁面重新登錄或者把后端的token過期時間設長一點。我在代碼里把JWT過期時間默認設置為24小時足夠覆蓋整場答辯。6.3 答辯時怎么講清楚推薦原理答辯老師不一定會看你代碼但一定會問“你的推薦算法是怎么工作的”。我準備了一個三句話版本的答案“我先給每件服裝構建一個特征向量向量里的維度包括顏色、季節、風格、版型等屬性用0和1表示是否具備該特征然后我計算兩件服裝特征向量的余弦相似度相似度越高說明風格越匹配最后通過規則引擎過濾掉不合理的組合比如上裝不跟上裝配再按相似度從高到低推薦出最合適的下裝、鞋靴和外套。”這段話里有“特征向量”“余弦相似度”“規則引擎”三個技術名詞每個詞都能展開講每個展開的細節都對得上項目代碼。老師不管問哪個方向你都有話可接。這就是“可解釋推薦”在畢設答辯里的最大價值。6.4 萬一推薦結果不合理怎么辦如果演示現場推薦出了明顯不合理的搭配千萬別慌更別說“系統有點小問題”。我準備了一套應急說法“這套推薦是基于當前衣櫥數據的全局最優解但搭配本身有主觀性所以我們系統還設計了用戶反饋機制您可以點擊‘換一套’來獲得備選方案也可以手動調整單品組合。”然后順勢演示一下“換一套”功能反而把劣勢變成了展示彈性和交互完整性的機會。這就是為什么我做推薦結果頁時故意保留了“換一套”的按鈕——它不只是功能更是答辯時的安全墊。7. 一套可復用的擴展思路如果你做完了以上內容還想再進一步這里有幾個擴展方向都不難實現但能顯著提升項目上限。第一個是天氣聯動推薦。接入第三方天氣API根據溫度、天氣情況調整推薦策略下雨推薦防水鞋靴天冷推薦厚外套。這個擴展邏輯清晰且實現簡單但在答辯時能讓人眼前一亮。第二個是著裝記錄與智能統計。記錄用戶每天的穿著一個月后展示用戶的風格偏好、穿著頻率圖表。這就引入了數據可視化和用戶畫像的概念可以讓項目從“工具型”升級為“服務型”。第三個是搭配社區。用戶可以分享自己的搭配方案到公共區域其他用戶可以點贊、評論。這個擴展如果做出來你的項目就從一個單機工具變成了一個社交產品工作量會大很多但帶來的項目分量也不可同日而語。我自己做項目的時候沒時間實現全部擴展但我建議學有余力的同學至少做第一個“天氣聯動”。它前面有現成的API后面接的是推薦規則的動態調整改動范圍很小卻能讓答辯老師感覺到你具備產品思維而不僅僅是會寫接口。最后再分享一點個人體會做這個系統的過程中我最大的收獲其實不是技術本身而是學會了一種“先想清楚再動手”的習慣。從選題、功能定義、數據建模到算法選型每一步都是先回答“為什么”再考慮“怎么做”。如果你也在做類似的畢設項目我建議你拿這個思路去對照自己的方案你的每一張表、每一個接口、每一段算法邏輯是不是都能回答出“為什么這樣設計”如果每個問題都能答上來你的項目就不僅僅是一份作業而是一件拿得出手的作品。本文還有配套的精品資源點擊獲取 基于SpringBoot3+Vue3的服裝搭配推薦系統設計與實現
簡介這是一套面向計算機專業本科生的2025屆畢業設計/課程設計實戰項目聚焦服裝搭配推薦場景解決用戶個性化穿搭決策效率低、后臺管理缺乏系統化工具等實際問題適用于Java全棧技術學習與工程實踐。資源包共6個文件含Vue3SpringBoot3完整源碼zip、MySQL8數據庫腳本sql、系統需求文檔docx、全流程操作錄屏mp4及返修版本源碼與文檔zip總大小87.05MB結構清晰、模塊完整覆蓋前后端分離開發典型流程。已有64人下載學習適合掌握基礎Java、Vue.js和SpringBoot的學生開展二次開發或答辯復現。讀者可直接部署運行通過錄屏快速掌握后臺商品/搭配模板管理、前臺瀏覽推薦、用戶交互等核心功能并結合需求文檔理解業務建模邏輯返修材料更便于對照學習常見優化點與代碼規范改進路徑。 從衣櫥里挑衣服這件事很多人每天都要糾結十分鐘起步——這件上衣配哪條褲子這雙鞋能不能搭這條裙子顏色會不會沖突風格是不是統一如果你仔細想想會發現這其實是一個典型的“信息過載決策困難”問題。也正是這個痛點讓我在2025年做畢業設計的時候毫不猶豫地選了服裝搭配推薦系統這個方向技術棧用了SpringBoot3 Vue.js3。先擺個結論這套系統做出來之后不只是“畢設能過”的水平。它既能當完整的電商/穿搭類項目來展示功能又能把“推薦算法”作為核心亮點去答辯同時前后端技術棧又踩在2025年的主流節點上。對于需要一個既有技術深度、又有實際應用場景、還不容易和同學撞車的畢設題目來說這是一個很難得的選擇。這篇文章我會把這個項目的完整思路拆開講從選題邏輯、功能設計、數據庫建模到推薦算法怎么落地成真正的Java代碼再到Vue3前端怎么做搭配展示最后是答辯和演示時最容易踩的坑。整篇文章不是泛泛的介紹而是照著能復現、能運行、能答辯的標準來寫。1. 為什么選“服裝搭配推薦”這個方向從痛點倒推選題每年畢業設計選題的時候總能刷到一批“經典款”題目XXX管理系統、XXX商城、XXX論壇。不是說這些題目不行而是撞車率太高而且功能做完就是標準的增刪改查答辯的時候老師問一句“你的難點在哪里”場面會變得很安靜。服裝搭配推薦系統能在這種大環境里跳出來核心原因是它站得住兩個維度。第一個維度是真實場景。根據我對周圍人的觀察絕大多數人的衣櫥里并不缺衣服缺的是“怎么把它們組合起來”的能力。買的時候覺得好看回家發現不知道怎么搭最后衣服要么壓箱底、要么永遠穿那兩三套。所以“搭配推薦”解決的不僅是“找相似商品”而是“幫你做決策”的問題。這個場景放在哪個時代都成立比純粹賣東西的商城系統多了一層用戶價值。第二個維度是技術難度剛好卡在畢設的“甜點區”。它比純CRUD復雜但又沒有復雜到讓人做不完。推薦邏輯可以用規則引擎、可以用相似度計算、也可以加一點協同過濾的變體算法的解釋成本低演示效果好。這個度是非常重要的——太簡單了沒有亮點太難了做到一半心態崩掉。再看技術棧的選擇。之所以選SpringBoot3 Vue3而不是還在到處流傳的SpringBoot2 Vue2有兩個方面的考慮一是2025年這個時間點上SpringBoot3已經非常成熟。它基于JDK17底層是Spring Framework 6性能、安全性、生態都對得上當前工業界的新項目標準。現在出去找工作簡歷上寫SpringBoot2反而會讓面試官覺得技術棧更新不及時。既然畢設是一個能寫進簡歷的項目那技術棧最好是當前企業正在用的。二是Vue3配合Vite構建工具開發體驗比Vue2的Webpack方案好很多。Composition API在邏輯復用、組織代碼這件事上比Options API更舒服Element Plus組件庫也很成熟。前端部分做衣櫥管理、搭配展示這類界面正好能把Vue3的優勢發揮出來。為了讓你直觀感受技術選型的合理性我做了個對比表對比維度SpringBoot2 Vue2SpringBoot3 Vue3JDK要求JDK8/11JDK17支持新語法和新特性底層框架Spring Framework 5Spring Framework 6性能優化明顯構建工具Webpack為主Vite冷啟動速度快一個量級前端狀態方案VuexPiniaTypeScript支持更好組件庫Element UIElement Plus答辯面試優勢常規水平能體現2025年技術敏感度所以這個選題的核心邏輯是用真實的用戶決策痛點作為項目外殼用“推薦算法主流前后端框架”作為技術內核。外行看著覺得有意思內行看著覺得有深度老師看著覺得工作量飽滿。2. 系統功能骨架與數據庫設計先把“賣什么”定清楚動手寫代碼之前我花了兩天時間畫功能腦圖和設計稿。這個階段最忌諱的是“上來就寫Controller”因為服裝搭配這個領域里物品屬性、標簽體系、搭配規則之間是有依賴關系的不提前定好數據模型后面改起來會非常痛。2.1 三種角色與核心業務閉環我先把這個系統涉及的角色和業務閉環講清楚這部分也是后面數據庫建模的依據。系統分了三種角色游客只能看首頁和熱門搭配用來撐起項目展示面的“公開區域”。注冊用戶系統的核心使用角色。可以在衣櫥里上傳衣服、完善屬性標簽、發起搭配請求、收藏滿意的搭配、查看歷史搭配記錄。管理員負責服裝庫的維護、標簽字典的管理、用戶內容審核。畢設里這一塊不需要做得太重但要有否則“后臺管理功能”這個基本盤就丟了。核心業務閉環是一條很清楚的鏈路用戶上傳/添加服裝 → 維護服裝標簽屬性 → 發起搭配請求 → 系統生成搭配方案 → 用戶收藏或反饋 → 系統記錄日志并優化后續推薦。這條鏈路里最關鍵的實體是“服裝”而服裝的關鍵又在于“標簽屬性”。為什么不是直接在服裝表里寫死十幾個字段比如顏色、風格、季節這個我后面講數據庫設計的時候詳細說。2.2 數據庫表結構設計數據庫我用的MySQLSpring Data JPA做ORM。核心表一共六張用戶表、服裝表、標簽表、服裝標簽關聯表、搭配記錄表、搭配收藏表。額外還有一套室內裝飾、穿著場景的字典表但那是擴展用的不影響主流程。表名核心字段說明userid, username, password, nickname, avatar用戶信息clothingid, user_id, name, category, image_url, color, season, style, occasion, fit服裝單品簡化版屬性tagid, name, type標簽字典比如“通勤”“小清新”“暖色系”clothing_tagclothing_id, tag_id服裝和標簽多對多關聯outfitid, user_id, top_id, bottom_id, shoes_id, outer_id, reason, create_time搭配記錄一條記錄存一套完整方案outfit_favoriteid, user_id, outfit_id, create_time收藏功能這里我想重點說三個設計決策都是實際開發中踩過或者思考過的第一為什么服裝表既要有獨立屬性字段又要有關聯標簽表獨立屬性字段color、season、style等是為了滿足“條件篩選”這種高性能查詢比如用戶想看“夏天通勤連衣裙”標簽表是為了滿足“柔性擴展”比如以后想加一個“適合約會”的標簽改字典就行不用改表結構。兩者結合既能跑推薦算法又能做篩選靈活性最高。第二為什么搭配記錄單獨建一張outfit表而不是每次臨時算推薦算法的計算是有開銷的而且用戶對同一套搭配可能反復查看。把生成好的搭配方案存下來好處是歷史記錄查詢極快也在數據結構上天然形成了“用戶的行為日志”——這是后續優化推薦效果的依據。第三category字段用String而不是用外鍵關聯分類表加分類表更規范但畢設場景里分類就那么幾個上裝、下裝、裙子、外套、鞋靴、配飾用枚舉字符串反而簡單直觀。你要是為了在論文里多寫一張表也可以拆出去但我個人覺得沒必要這是典型的“過度建模”。2.3 接口清單規劃數據庫定完接口基本就出來了。我按照RESTful風格整理了一下核心接口不算多模塊方法路徑說明用戶POST/api/user/register注冊用戶POST/api/user/login登錄返回JWT服裝GET/api/clothing/list當前用戶的衣櫥列表服裝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管理員分頁查看服裝庫這套接口清單背后有一個隱藏設計邏輯所有推薦相關的路徑都收斂在/api/recommend下和普通CRUD接口隔離開來。這樣做是為了在代碼層面清晰地告訴閱讀者——哪些是普通業務哪些是算法核心答辯的時候講代碼結構會非常清爽。3. 推薦算法落地從余弦相似度到可解釋推薦這部分是整個系統的靈魂也是很多同學最容易犯怵的地方。其實沒必要慌我先把算法選擇的邏輯講清楚你就知道為什么我會放棄那些聽起來高大上的方案。3.1 為什么我沒選“協同過濾”當主力算法協同過濾是推薦系統教材上的經典內容分成基于用戶的UserCF和基于物品的ItemCF。但放在畢設這個場景下有一個繞不開的問題數據稀疏。協同過濾本質上是“物以類聚、人以群分”它需要大量用戶行為數據才能發揮作用。你一個畢設項目哪來的幾萬用戶用戶不多行為矩陣稀稀拉拉算出來的相似度根本沒有統計意義演示的時候效果完全不可控。更重要的是協同過濾是黑盒模型你很難跟答辯老師解釋清楚“為什么推薦了這一套搭配”。萬一老師追著問具體案例你只能反復說“因為其他用戶也這樣選擇”——這個解釋力在答辯現場是很弱的。3.2 適合畢設的解法基于內容特征的搭配評分我最后用的方案是基于服裝內容特征 規則約束 余弦相似度打分屬于混合式推薦。它比純協同過濾的可解釋性更強比純規則的硬編碼更有技術含量而且效果完全可控。核心思想分三層規則層先做硬約束比如“外套不能推薦成內搭”“夏季上裝優先配薄款下裝”“西裝外套優先配通勤風單品”。這些規則用代碼if-else實現過濾掉明顯不合理的搭配。特征層每件服裝根據屬性標簽轉成一個特征向量。比如一件“白色、夏季、通勤風、修身上裝”它的特征向量就是{白色:1, 夏季:1, 通勤:1, 修身:1}顏色、季節、風格、版型這些維度組成一個多值編碼的boolean向量。評分層計算候選單品與推薦目標之間的余弦相似度再疊加規則權重得到最終得分按分數排序取TopN。3.3 特征向量構建與余弦相似度計算這里我直接把核心代碼邏輯貼出來代碼是Java寫的用的SpringBoot3環境。先定義服裝的特征提取器public class ClothingFeatureExtractor { /** * 將服裝實體轉為特征向量。 * 這里用了LinkedHashMap保證特征順序一致便于后續計算。 */ public static MapString, Double extract(Clothing clothing) { MapString, Double vector new LinkedHashMap(); // 基礎屬性編碼 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); } // 關聯標簽編碼 if (clothing.getTags() ! null) { for (Tag tag : clothing.getTags()) { vector.put(tag_ tag.getName().toLowerCase(), 1.0); } } return vector; } }這里有個關鍵細節把“類別”也編碼進特征向量了。這個操作會讓“上裝”和“下裝”天然擁有不同的向量簽名避免推薦出同類單品互搭的尷尬局面。跑相似度計算時同類服裝的相似度矩陣也能正常使用但生成搭配時會加類別約束不讓上裝配上裝。然后是余弦相似度計算器和搭配推薦服務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; } /** * 給定一件單品推薦一套搭配。 * 流程先按類別硬約束過濾再計算相似度最后返回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. 對候選單品按相似度打分 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. 按分類取最優下裝、鞋/配飾、外套作為可選 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我單獨提出來一個規則引擎類里面全是硬約束規則。比如“上衣不跟上衣搭配”“顏色對比度不能太刺眼”“風格標簽至少有一個重合”。這些規則看著簡單但它們是整個推薦方案里“防呆”的關鍵。沒有這些硬約束余弦相似度再高也可能推出一套“紅衣配紅褲”的春節聯歡會造型。3.4 冷啟動與兜底策略畢設項目沒有真實用戶數據冷啟動是必然要面對的。我的處理方式是系統初始內置一批“專家搭配模板”作為種子數據大概20套左右。這些模板是我自己按通勤、休閑、約會、運動四個場景整理的每套模板含有基礎單品組合和推薦理由。當計算出的相似度分數太低比如低于閾值0.1或者衣櫥里根本沒有合適搭配的時候就返回種子模板里的“同風格相近搭配”保證演示效果永遠在線。這個策略在答辯演示時非常關鍵——現場是網速不穩定、數據準備不充分都可能發生有兜底方案就不會翻車。3.5 推薦理由的可解釋性設計為了講清楚“為什么推薦這套”我在生成搭配記錄的時候同步生成了一段自然語言推薦理由就是代碼里的buildReason方法。private String buildReason(Clothing base, Clothing bottom, Clothing shoes) { StringBuilder sb new StringBuilder(); sb.append(根據您選擇的).append(base.getName()); if (bottom ! null) { sb.append(推薦搭配).append(bottom.getName()) .append(兩者在).append(commonStyle(base, bottom)).append(風格上高度契合); } if (shoes ! null) { sb.append(同時用).append(shoes.getName()).append(來提升整體完成度); } sb.append(。); return sb.toString(); }這段理由不是花架子。答辯的時候老師大概率會問“你的推薦邏輯是怎么被用戶感知的”你直接把前端頁面上展示的推薦理由指給他看再順著講一遍特征提取和相似度計算流程整個邏輯鏈就完整了。技術含量、業務完成度都有了這是很多同類畢設項目做不好的地方。4. SpringBoot3后端實現從項目初始化到核心接口算法思路清楚了接下來就是工程落地的部分。SpringBoot3和SpringBoot2在寫法上區別不大但有幾個關鍵點在你建項目的時候就需要留意。我按實際操作順序講。4.1 建項目的正確姿勢建議直接用Spring Initializrstart.spring.io生成項目骨架而不是自己手搭Maven結構。選擇項如下ProjectMavenGradle也行但Maven更適合國內環境資料多LanguageJavaSpring Boot3.2.x或3.3.x選正式穩定版不要選快照版Group/Artifact根據自己的包名來比如com.example.clothingDependenciesSpring Web、Spring Data JPA、MySQL Driver、Validation、Lombok、Spring Security可選項如果只用JWT可以選注意一個坑SpringBoot3的javax.*包已經全部遷移到jakarta.*了。你從網上復制老代碼的時候很多import javax.persistence.*會直接報錯要改成jakarta.persistence.*。這個小坑卡了我半天網上大量博客寫的還是SpringBoot2的代碼復制時一定要檢查包名。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 實體映射與JPA的坑Clothing實體的核心映射代碼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(); }這里我想特別提醒一個實踐中的坑JPA的懶加載在事務外訪問關聯對象會報LazyInitializationException。最簡單的解決辦法是在Service層方法上標注Transactional保證整個方法在同一個持久化上下文里執行。我的RecommendService方法就加了注解。如果你在Controller里直接訪問實體關聯屬性那就等著報錯吧。還有一點為了和前面的算法配合Clothing實體里我加了一個簡化設計的fit字段表示版型修身、寬松、標準這個字段在相似度計算時是一個重要的區分維度。兩件衣服如果顏色、風格都一樣但一個是修身一個是寬松搭起來效果可能完全相反所以推薦時最好先看版型匹配度。4.3 推薦接口的RESTful設計推薦接口我設計成GET請求語義清晰方便前端直接調用展示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) { // 內部調用推薦服務生成搭配 OutfitVO outfitVO recommendService.generateOutfit(clothingId); return Result.success(outfitVO); } /** * 獲取今日推薦 */ GetMapping(/daily) public ResultListOutfitVO dailyOutfit() { return Result.success(recommendService.dailyOutfit()); } }Result是我封裝的統一返回體里面包含code、message、data三個字段。這個包裝不是為了炫技而是讓前端能統一處理錯誤狀態不用到處去try-catch網絡異常。Service層的代碼組織上我建議把“算法邏輯”和“數據持久化”分開。推薦生成部分放在RecommendService搭配記錄的查詢和收藏放在OutfitService兩個Service互相獨立。這樣后面你想調推薦算法只改RecommendService就行不會誤傷其他業務。4.4 靜態資源與文件上傳服裝肯定要配圖。畢設項目我不建議自己搞OSS對象存儲直接用本地文件存儲就行。在application.yml里配置靜態資源映射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就能直接映射到磁盤目錄。如果部署到云服務器把upload.path改成/home/ubuntu/clothing-upload/即可。Linux環境要注意目錄存在權限否則文件上傳會失敗這個坑我在答辯前夜遇到過——服務器上目錄不存在SpringBoot不會主動給你建文件上傳直接500。5. Vue3前端三塊核心界面的實現思路前端不是從零手寫我用的是Vue3 Vite Element Plus Pinia這套組合。搭建過程比較順重點講三塊核心界面的實現思路和代碼組織方式。5.1 項目初始化與關鍵配置用Vite創建Vue3項目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的引入分成全量引入和按需引入兩種。畢設項目我直接全量引入了省事。但如果你想在簡歷里體現對性能的在意可以用unplugin-auto-import和unplugin-vue-components實現按需引入這里我不過多展開知道有這條路就行。前端路由用Vue Router分三個主頁面衣櫥管理、AI搭配推薦、搭配日志。路由配置簡單關鍵是前端和后端的接口聯調。聯調的第一步是解決跨域。開發環境下Vite代理配置在vite.config.jsexport default defineConfig({ plugins: [vue()], server: { port: 3000, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } })這個配置讓前端的/api請求自動轉發到后端8080端口同時瀏覽器的CORS請求就不會出來了。如果是生產部署就需要在后端寫一個跨域配置類把前端域名放進去。開發環境用代理是最省事的方式。Axios的封裝上我習慣在src/utils/request.js里統一配置baseURL和請求攔截器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 || 請求失敗) return Promise.reject(error) } ) export default request5.2 衣櫥管理頁卡片網格與標簽選擇器衣櫥頁是用戶操作的基礎用Element Plus的el-cardel-upload實現。一件服裝卡片包含圖片、名稱、分類、標簽、操作按鈕設為搭配基礎款、編輯、刪除。核心是“添加服裝”的表單里面有個標簽多選器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風格標簽 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這里的邏輯要點是風格標簽選項應該從后端接口動態獲取而不是寫死在前端。因為管理員可能隨時往字典表里添加新標簽如果前端寫死了后端改了前端不更新就會出現“后臺加了標簽前臺選不到”的割裂情況。從后端獲取的接口是GET /api/tag/list返回全部標簽字典。5.3 AI搭配推薦頁核心交互設計這是整個前端最核心的頁面。交互流程是用戶先選擇一件衣櫥里的單品比如選擇了一件白色襯衫點擊“AI智能搭配”系統就會調用推薦接口把搭配結果展示在下方。頁面布局我用了左右分欄左側是衣櫥單品列表點擊選中右側是推薦結果區從上到下展示“上裝搭配→下裝搭配→鞋靴→推薦理由”。推薦結果區用了卡片式展示template div classrecommend-container h3搭配推薦結果/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這里值得說的是“匹配度”這個展示項。它直接來自后端算法計算出的余弦相似度并轉換成百分比展示。這個數字能非常直觀地向觀眾證明“這個推薦不是瞎猜的是有算法在背后支撐的”演示效果極好。5.4 搭配日志與收藏頁搭配日志頁展示歷史生成過的搭配記錄每一組搭配都有時間、搭配方案、當時的推薦理由并提供“再次收藏”和“刪除記錄”操作。這個頁面是后端outfit表的直接映射前端邏輯不復雜用el-table或卡片時間線就能做得好看。Pinia作為全局狀態管理我主要用于用戶登錄信息、Token、以及“當前選中的搭配”這個跨頁面共享狀態。比如用戶在推薦頁生成了一個搭配收藏時需要把搭配數據傳給收藏接口如果不用狀態管理就要通過路由參數傳會比較狼狽。6. 演示和答辯環節最容易翻車的細節項目做完了代碼能跑了但離“高分畢設”還差一步——演示和答辯。這一步很多人栽跟頭不是因為項目不好而是因為準備不充分。下面這幾條全是我親身踩過或者看別人踩過的坑。6.1 演示數據的準備是門技術活千萬不能隨便找幾張衣服圖片就往系統里塞。演示數據需要滿足三個條件圖片風格統一、屬性標簽完整、分類覆蓋足夠。我的經驗是準備30件衣服覆蓋上裝、下裝、外套、鞋靴、配飾五類。風格上至少覆蓋通勤、休閑、運動、約會四個場景。每件衣服的標簽要仔細打比如“白色”“寬松”“棉質”“通勤”。只有數據質量高推薦算法才能跑出讓人眼前一亮的效果。我測試的時候就發現如果數據里只有“黑色”“白色”兩種顏色冷色系和暖色系的區分就完全失效了推薦結果的多樣性會大打折扣。還有一個小技巧演示之前先把“歷史搭配記錄”里預置幾條數據這樣打開搭配日志頁時頁面不會空空的視覺上非常加分。6.2 現場演示的三大翻車點第一是圖片加載。如果你用本地靜態資源路徑打包部署后圖片路徑很可能會漂移。解決方法是后端返回圖片時返回完整訪問路徑比如http://localhost:8080/images/xxx.jpg而不是只返回/images/xxx.jpg這樣無論前端怎么部署都能正確拼接。當然如果你在Application.yml里配置了context-path那拼接的時候就要多帶一層前綴。第二是接口超時。首次調用推薦接口時如果數據庫里服裝數據量增大到幾百件全量遍歷相似度計算可能有點慢。而前端Axios的timeout如果設的是5秒很容易超時。我前端統一設成了15秒同時后端在推薦接口上加了Cacheable緩存把“同一種基礎單品”的推薦結果緩存起來第二次請求就直接走緩存速度快到飛起。第三是Token過期。演示現場通常是打開的瀏覽器一直放著等正式演示時JWT可能已經過期了。結果一調用接口后端返回401前端跳轉到登錄頁場面很尷尬。解決辦法很簡單演示前刷新一下頁面重新登錄或者把后端的token過期時間設長一點。我在代碼里把JWT過期時間默認設置為24小時足夠覆蓋整場答辯。6.3 答辯時怎么講清楚推薦原理答辯老師不一定會看你代碼但一定會問“你的推薦算法是怎么工作的”。我準備了一個三句話版本的答案“我先給每件服裝構建一個特征向量向量里的維度包括顏色、季節、風格、版型等屬性用0和1表示是否具備該特征然后我計算兩件服裝特征向量的余弦相似度相似度越高說明風格越匹配最后通過規則引擎過濾掉不合理的組合比如上裝不跟上裝配再按相似度從高到低推薦出最合適的下裝、鞋靴和外套。”這段話里有“特征向量”“余弦相似度”“規則引擎”三個技術名詞每個詞都能展開講每個展開的細節都對得上項目代碼。老師不管問哪個方向你都有話可接。這就是“可解釋推薦”在畢設答辯里的最大價值。6.4 萬一推薦結果不合理怎么辦如果演示現場推薦出了明顯不合理的搭配千萬別慌更別說“系統有點小問題”。我準備了一套應急說法“這套推薦是基于當前衣櫥數據的全局最優解但搭配本身有主觀性所以我們系統還設計了用戶反饋機制您可以點擊‘換一套’來獲得備選方案也可以手動調整單品組合。”然后順勢演示一下“換一套”功能反而把劣勢變成了展示彈性和交互完整性的機會。這就是為什么我做推薦結果頁時故意保留了“換一套”的按鈕——它不只是功能更是答辯時的安全墊。7. 一套可復用的擴展思路如果你做完了以上內容還想再進一步這里有幾個擴展方向都不難實現但能顯著提升項目上限。第一個是天氣聯動推薦。接入第三方天氣API根據溫度、天氣情況調整推薦策略下雨推薦防水鞋靴天冷推薦厚外套。這個擴展邏輯清晰且實現簡單但在答辯時能讓人眼前一亮。第二個是著裝記錄與智能統計。記錄用戶每天的穿著一個月后展示用戶的風格偏好、穿著頻率圖表。這就引入了數據可視化和用戶畫像的概念可以讓項目從“工具型”升級為“服務型”。第三個是搭配社區。用戶可以分享自己的搭配方案到公共區域其他用戶可以點贊、評論。這個擴展如果做出來你的項目就從一個單機工具變成了一個社交產品工作量會大很多但帶來的項目分量也不可同日而語。我自己做項目的時候沒時間實現全部擴展但我建議學有余力的同學至少做第一個“天氣聯動”。它前面有現成的API后面接的是推薦規則的動態調整改動范圍很小卻能讓答辯老師感覺到你具備產品思維而不僅僅是會寫接口。最后再分享一點個人體會做這個系統的過程中我最大的收獲其實不是技術本身而是學會了一種“先想清楚再動手”的習慣。從選題、功能定義、數據建模到算法選型每一步都是先回答“為什么”再考慮“怎么做”。如果你也在做類似的畢設項目我建議你拿這個思路去對照自己的方案你的每一張表、每一個接口、每一段算法邏輯是不是都能回答出“為什么這樣設計”如果每個問題都能答上來你的項目就不僅僅是一份作業而是一件拿得出手的作品。本文還有配套的精品資源點擊獲取