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