1. 旅游商品管理系統(tǒng)的真實(shí)需求場(chǎng)景畢設(shè)選題之前要想清楚的事很多同學(xué)一看到“旅游商品管理系統(tǒng)”這個(gè)題目第一反應(yīng)是“又一個(gè)CRUD”第二反應(yīng)是“Spring Boot 大數(shù)據(jù)聽(tīng)起來(lái)高級(jí)但大數(shù)據(jù)到底用在哪”。說(shuō)實(shí)話這兩個(gè)反應(yīng)都沒(méi)錯(cuò)但也都只對(duì)了一半。我本人這幾年幫不少計(jì)算機(jī)專(zhuān)業(yè)的學(xué)弟學(xué)妹審過(guò)畢業(yè)設(shè)計(jì)題目也帶過(guò)幾個(gè)類(lèi)似的系統(tǒng)項(xiàng)目。這個(gè)題目的價(jià)值恰恰在于它不像純粹的電商系統(tǒng)那樣只需要做好訂單和庫(kù)存也不像純粹的數(shù)據(jù)分析平臺(tái)那樣只需要做報(bào)表和挖掘。旅游商品這個(gè)業(yè)務(wù)域天然帶有“商品管理共性 旅游場(chǎng)景特性 數(shù)據(jù)價(jià)值挖掘潛力”三重屬性做起來(lái)既有基本功的展示空間又有差異化亮點(diǎn)的發(fā)揮余地。先說(shuō)一個(gè)反直覺(jué)的結(jié)論旅游商品管理系統(tǒng)最大的難點(diǎn)從來(lái)不在“系統(tǒng)能不能跑通”而在“你憑什么說(shuō)這個(gè)系統(tǒng)是旅游商品的系統(tǒng)而不是把超市進(jìn)銷(xiāo)存改了個(gè)名字”。很多同學(xué)做完系統(tǒng)去答辯老師問(wèn)了三個(gè)問(wèn)題就卡住了基本都出在這一點(diǎn)上。你的旅游商品和普通電商商品有什么區(qū)別——答不上來(lái)。大數(shù)據(jù)技術(shù)在你的系統(tǒng)里做了什么MySQL存數(shù)據(jù)也算大數(shù)據(jù)嗎——答不上來(lái)。你的并發(fā)設(shè)計(jì)了沒(méi)有節(jié)假日旅游高峰怎么辦——答不上來(lái)。所以這篇博文我不想給那種“先建個(gè)Spring Boot項(xiàng)目然后抄一堆代碼”的流水賬教程。我要做的是把一條相對(duì)完整的實(shí)現(xiàn)路徑拆給你看——從技術(shù)選型的取舍邏輯到數(shù)據(jù)庫(kù)建模的坑到“大數(shù)據(jù)”在畢設(shè)里怎么落地才算合理再到前后端對(duì)接和文檔撰寫(xiě)的避坑點(diǎn)。這篇內(nèi)容適合的人群是準(zhǔn)備做Java方向畢業(yè)設(shè)計(jì)的本科生、需要課程設(shè)計(jì)成果的專(zhuān)科或培訓(xùn)學(xué)員以及想快速理解“Spring Boot 數(shù)據(jù)類(lèi)應(yīng)用”怎么結(jié)合的轉(zhuǎn)行開(kāi)發(fā)者。為了讓你對(duì)最終做出來(lái)的東西有個(gè)具象感知先說(shuō)一下整個(gè)系統(tǒng)的目標(biāo)形態(tài)一個(gè)可以演示、可以答辯、可以寫(xiě)進(jìn)簡(jiǎn)歷的Web應(yīng)用管理端完成商品、分類(lèi)、景區(qū)關(guān)聯(lián)、庫(kù)存、訂單、用戶、公告的全流程管理加上基于訂單數(shù)據(jù)衍生的統(tǒng)計(jì)報(bào)表。前端不做太重的東西后端結(jié)構(gòu)規(guī)范數(shù)據(jù)庫(kù)設(shè)計(jì)合理文檔和演示流程齊全。聽(tīng)起來(lái)不難但把每個(gè)環(huán)節(jié)做扎實(shí)至少需要一到兩周的密集開(kāi)發(fā)時(shí)間。2. 技術(shù)選型背后的取舍邏輯為什么是Spring Boot為什么是MySQL又為什么碰“大數(shù)據(jù)”2.1 Spring Boot在畢設(shè)場(chǎng)景下的統(tǒng)治力你去看近三年Java方向的課程設(shè)計(jì)和畢業(yè)設(shè)計(jì)Spring Boot的覆蓋率大概在七成以上這不是偶然。Spring Boot解決了傳統(tǒng)SSM整合時(shí)最痛苦的配置問(wèn)題——你不需要再寫(xiě)那一大堆XML不需要手動(dòng)配置事務(wù)管理器不需要操心Bean之間的依賴(lài)關(guān)系怎么聲明一個(gè)SpringBootApplication注解啟動(dòng)類(lèi)加上自動(dòng)配置機(jī)制就能把大部分基礎(chǔ)設(shè)施從“顯式配置”變成“約定優(yōu)于配置”。我用一個(gè)生活化的類(lèi)比來(lái)說(shuō)SSM時(shí)代做項(xiàng)目像是自己裝修房子水電、墻面、地板都得盯著每一步都能看到過(guò)程但每步都很累Spring Boot時(shí)代做項(xiàng)目像是全屋定制你在菜單上選好風(fēng)格和模塊工廠一次性生產(chǎn)好到現(xiàn)場(chǎng)拼裝就能住。對(duì)于畢設(shè)這種“既要完成度、又要時(shí)間可控”的場(chǎng)景來(lái)說(shuō)全屋定制顯然是更理性的選擇。但你要注意一個(gè)關(guān)鍵點(diǎn)Spring Boot的自動(dòng)配置解決的是“怎么把項(xiàng)目跑起來(lái)”而不是“項(xiàng)目該怎么做”。很多同學(xué)的誤區(qū)是Spring Boot幫我把配置搞定了我就只需要寫(xiě)Controller和Mapper就行。實(shí)際上Spring Boot項(xiàng)目的架構(gòu)分層、統(tǒng)一返回結(jié)構(gòu)、異常處理、參數(shù)校驗(yàn)這些都是“技術(shù)債”前期不搭好后期改起來(lái)痛不欲生。在本項(xiàng)目里Spring Boot承擔(dān)的具體職責(zé)如下職責(zé)維度具體技術(shù)點(diǎn)作用說(shuō)明Web層Spring MVC RESTful API提供前后端分離的接口訪問(wèn)數(shù)據(jù)層Spring Data JPA / MyBatis-Plus完成ORM映射和數(shù)據(jù)庫(kù)操作安全校驗(yàn)Spring Validation 攔截器參數(shù)合法性和登錄狀態(tài)校驗(yàn)事務(wù)管理Transactional保證訂單和庫(kù)存操作的原子性數(shù)據(jù)初始化CommandLineRunner / SQL腳本啟動(dòng)時(shí)初始化基礎(chǔ)數(shù)據(jù)版本方面建議Spring Boot 2.7.x系列不要盲目追新。理由很實(shí)在2.7.x是2.x時(shí)代的收尾版本資料豐富、兼容性好、網(wǎng)上踩坑案例多畢設(shè)階段遇到問(wèn)題時(shí)搜到的解決方案基本都能用。Spring Boot 3.x雖然已經(jīng)成熟但涉及Jakarta命名空間遷移和Java 17的要求對(duì)很多同學(xué)來(lái)說(shuō)沒(méi)必要冒這個(gè)險(xiǎn)。2.2 數(shù)據(jù)庫(kù)選型MySQL是默認(rèn)答案嗎如果你問(wèn)十個(gè)做過(guò)畢設(shè)的人九個(gè)會(huì)告訴你就用MySQL。這個(gè)答案對(duì)但你要理解“為什么對(duì)”才能去答辯時(shí)候說(shuō)清楚。第一MySQL的生態(tài)成熟度無(wú)人能比。無(wú)論是Navicat、DataGrip這些圖形化工具還是網(wǎng)上鋪天蓋地的教程和報(bào)錯(cuò)解決方案都能極大降低開(kāi)發(fā)期的排錯(cuò)成本。第二MySQL的InnoDB引擎在事務(wù)支持方面夠用且可靠——旅游商品訂單涉及金額、庫(kù)存扣減、用戶余額多個(gè)數(shù)據(jù)表聯(lián)動(dòng)沒(méi)有事務(wù)保障很容易出現(xiàn)數(shù)據(jù)不一致。第三學(xué)校機(jī)房、演示環(huán)境、答辯現(xiàn)場(chǎng)的兼容性最穩(wěn)你不可能在答辯時(shí)告訴老師“這個(gè)系統(tǒng)必須跑在PostgreSQL特定版本上”。數(shù)據(jù)庫(kù)版本建議8.0原因很簡(jiǎn)單8.0的窗口函數(shù)、CTE公共表表達(dá)式等特性在后續(xù)寫(xiě)統(tǒng)計(jì)報(bào)表SQL時(shí)會(huì)非常方便。字符集統(tǒng)一使用utf8mb4因?yàn)樯唐访Q(chēng)、景區(qū)介紹里完全可能包含emoji或特殊符號(hào)utf8mb4才能完整支持。但我要特別提醒你把數(shù)據(jù)持久層從JDBC原生寫(xiě)法升級(jí)為MyBatis-Plus是本項(xiàng)目開(kāi)發(fā)效率提升幅度最大的一步。MyBatis-Plus提供的BaseMapper接口內(nèi)置了增刪改查和分頁(yè)查詢的通用方法你不需要為每個(gè)實(shí)體類(lèi)重復(fù)編寫(xiě)基礎(chǔ)SQL它的LambdaQueryWrapper則讓條件查詢變得像寫(xiě)偽代碼一樣直觀。// 使用LambdaQueryWrapper完成多條件商品查詢 LambdaQueryWrapperGoods wrapper new LambdaQueryWrapper(); wrapper.like(StringUtils.hasText(keyword), Goods::getName, keyword) .eq(categoryId ! null, Goods::getCategoryId, categoryId) .eq(Goods::getStatus, 1) .orderByDesc(Goods::getSales); PageGoods page goodsMapper.selectPage(new Page(pageNum, pageSize), wrapper);2.3 “大數(shù)據(jù)技術(shù)”在畢業(yè)設(shè)計(jì)中的合理落地方式這是整個(gè)選題里最需要想清楚的部分。你我都知道用MySQL做個(gè)三張表的系統(tǒng)離真正的“大數(shù)據(jù)”還有十萬(wàn)八千里。但畢設(shè)題目的要求是“基于大數(shù)據(jù)技術(shù)”你必須在系統(tǒng)里找到一個(gè)真實(shí)、合理、可解釋的場(chǎng)景把大數(shù)據(jù)相關(guān)的技術(shù)或思路融進(jìn)去而不是生硬地堆一個(gè)ElasticSearch或者Redis就完事。我給的落地路徑是三個(gè)層次第一層數(shù)據(jù)采集層。在系統(tǒng)前端埋點(diǎn)記錄用戶的瀏覽、搜索、收藏、購(gòu)買(mǎi)行為生成用戶行為日志表。這部分可以直接用MySQL實(shí)現(xiàn)但在設(shè)計(jì)時(shí)要考慮日志數(shù)據(jù)的增長(zhǎng)量——旅游商品系統(tǒng)的日訂單量可能不高但行為日志量級(jí)是訂單量的幾十倍。這本身就是大數(shù)據(jù)思想的萌芽行為和交易分離存儲(chǔ)就是數(shù)倉(cāng)分層建模中ODS操作數(shù)據(jù)存儲(chǔ)與DWD明細(xì)數(shù)據(jù)分離的簡(jiǎn)化版。第二層數(shù)據(jù)分析層。基于訂單明細(xì)和用戶行為數(shù)據(jù)實(shí)現(xiàn)若干維度統(tǒng)計(jì)商品銷(xiāo)量排行按景區(qū)、分類(lèi)、時(shí)間段、用戶消費(fèi)金額分布、復(fù)購(gòu)率分析、熱門(mén)景區(qū)關(guān)聯(lián)商品推薦等。這些統(tǒng)計(jì)邏輯用SQL聚合函數(shù)就能實(shí)現(xiàn)但它們的表達(dá)方式——按維度分組、按度量聚合、趨勢(shì)對(duì)比——本質(zhì)上就是OLAP在線分析處理的核心思路。答辯時(shí)完全可以說(shuō)清楚“我的分析模塊采用的是一種輕量化的多維數(shù)據(jù)分析方案”。第三層數(shù)據(jù)應(yīng)用層。這是最能體現(xiàn)“大數(shù)據(jù)”價(jià)值的場(chǎng)景簡(jiǎn)單協(xié)同過(guò)濾推薦。根據(jù)“購(gòu)買(mǎi)了某景區(qū)門(mén)票的用戶還購(gòu)買(mǎi)了哪些商品”的歷史訂單數(shù)據(jù)計(jì)算商品間的共現(xiàn)關(guān)系從而在商品詳情頁(yè)展示“購(gòu)買(mǎi)此商品的用戶也買(mǎi)了”的推薦列表。這個(gè)邏輯不復(fù)雜但它是實(shí)實(shí)在在的數(shù)據(jù)驅(qū)動(dòng)應(yīng)用而且可視化效果好足以作為系統(tǒng)的亮點(diǎn)展示。這里有個(gè)很重要的原則要說(shuō)明畢業(yè)設(shè)計(jì)中的數(shù)據(jù)量可能只有幾百條模擬數(shù)據(jù)但你要讓架構(gòu)具備面對(duì)更大數(shù)據(jù)量的擴(kuò)張思路也就是說(shuō)不是“實(shí)現(xiàn)了多少數(shù)據(jù)量”而是“你為了應(yīng)對(duì)更大的數(shù)據(jù)量做了什么設(shè)計(jì)”。比如分頁(yè)查詢是標(biāo)配比如統(tǒng)計(jì)查詢的SQL要寫(xiě)索引友好型寫(xiě)法比如日志表和業(yè)務(wù)表分離存儲(chǔ)這些都是答辯時(shí)可以主動(dòng)陳述的設(shè)計(jì)取舍。3. 數(shù)據(jù)庫(kù)與系統(tǒng)架構(gòu)設(shè)計(jì)一張好的ER圖能幫你避免80%的返工3.1 實(shí)體關(guān)系建模旅游商品系統(tǒng)至少需要哪些表做畢設(shè)最忌諱的事情就是拿到題目直接開(kāi)寫(xiě)代碼寫(xiě)到一半發(fā)現(xiàn)字段不夠用表缺了好幾項(xiàng)。先花半天時(shí)間把數(shù)據(jù)模型設(shè)計(jì)清楚后面開(kāi)發(fā)效率能快三倍左右。旅游商品管理系統(tǒng)的核心實(shí)體我按業(yè)務(wù)域拆成五組來(lái)說(shuō)業(yè)務(wù)域核心表關(guān)鍵字段說(shuō)明用戶域sys_user用戶名、密碼BCrypt密文、昵稱(chēng)、頭像、手機(jī)號(hào)、狀態(tài)、角色I(xiàn)D商品域goods商品名稱(chēng)、主圖、輪播圖JSON數(shù)組、詳情富文本、價(jià)格、庫(kù)存、銷(xiāo)量、狀態(tài)、所屬景區(qū)分類(lèi)域category分類(lèi)名稱(chēng)、父ID支持二級(jí)分類(lèi)、排序號(hào)、圖標(biāo)交易域orders和order_item訂單號(hào)唯一、總金額、支付狀態(tài)、收貨信息子表存商品快照信息內(nèi)容域banner、notice、feedback首頁(yè)輪播圖、系統(tǒng)公告、用戶反饋建議再說(shuō)說(shuō)為什么這樣拆分。把核心業(yè)務(wù)數(shù)據(jù)與支撐性基礎(chǔ)數(shù)據(jù)分離是中小型管理系統(tǒng)設(shè)計(jì)的核心準(zhǔn)則。goods表里不要塞入分類(lèi)名和景區(qū)名這種冗余內(nèi)容而是用外鍵關(guān)聯(lián)到category表和scenic_spot表。這樣分類(lèi)名稱(chēng)一旦修改所有商品自動(dòng)生效不需要逐條更新。orders表與order_item表分離則是標(biāo)準(zhǔn)的訂單模型——主表存訂單整體狀態(tài)和金額子表存目標(biāo)商品、數(shù)量、單價(jià)快照。注意“快照”這個(gè)詞商品價(jià)格后續(xù)完全可能調(diào)整但已生成的訂單必須保留交易當(dāng)下時(shí)刻的價(jià)格所以子表需要冗余存儲(chǔ)商品名和成交單價(jià)而不是簡(jiǎn)單關(guān)聯(lián)goods_id。3.2 用戶角色與權(quán)限模型一個(gè)表解決還是RBAC以畢設(shè)的系統(tǒng)復(fù)雜度來(lái)說(shuō)我建議用簡(jiǎn)潔的RBAC基于角色的訪問(wèn)控制模型而不是復(fù)雜的Spring Security OAuth2全家桶。所謂簡(jiǎn)潔版就是三張核心表sys_user用戶、sys_role角色、sys_menu菜單/權(quán)限加上一張關(guān)聯(lián)表打通用戶與角色關(guān)系。本系統(tǒng)的角色劃分管理員admin擁有全部菜單和操作權(quán)限包括商品管理、分類(lèi)管理、訂單管理、用戶管理、數(shù)據(jù)分析、系統(tǒng)設(shè)置。商戶/運(yùn)營(yíng)operator可管理商品和訂單可查看統(tǒng)計(jì)數(shù)據(jù)但不可操作用戶和系統(tǒng)設(shè)置。普通用戶user前臺(tái)小程序/H5端的注冊(cè)用戶可瀏覽商品、下單購(gòu)買(mǎi)、查看個(gè)人訂單、提交反饋。在Spring Boot端實(shí)現(xiàn)權(quán)限控制最簡(jiǎn)單的方案是攔截器 用戶角色判斷。這個(gè)方案的好處是不引入額外的安全框架依賴(lài)代碼邏輯直觀答辯時(shí)容易說(shuō)清楚。當(dāng)然也可以用Spring Security的注解式權(quán)限控制PreAuthorize兩種方案我都跑過(guò)如果你的時(shí)間充裕建議用Spring Security走一遍簡(jiǎn)歷上能多寫(xiě)一行技能點(diǎn)如果時(shí)間緊張攔截器方案完全足夠。3.3 關(guān)鍵表結(jié)構(gòu)的細(xì)節(jié)設(shè)計(jì)示范這里重點(diǎn)說(shuō)幾個(gè)容易踩坑的表字段設(shè)計(jì)直接給出我實(shí)測(cè)過(guò)的建表SQL片段CREATE TABLE goods ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 商品ID, goods_sn VARCHAR(32) NOT NULL COMMENT 商品編號(hào), name VARCHAR(128) NOT NULL COMMENT 商品名稱(chēng), category_id BIGINT NOT NULL COMMENT 分類(lèi)ID, scenic_spot_id BIGINT DEFAULT NULL COMMENT 關(guān)聯(lián)景區(qū)ID, main_image VARCHAR(255) DEFAULT NULL COMMENT 主圖URL, gallery JSON DEFAULT NULL COMMENT 輪播圖列表, detail TEXT COMMENT 商品詳情富文本, price DECIMAL(10,2) NOT NULL COMMENT 銷(xiāo)售單價(jià), original_price DECIMAL(10,2) DEFAULT NULL COMMENT 原價(jià)劃線價(jià), stock INT NOT NULL DEFAULT 0 COMMENT 庫(kù)存, sales INT NOT NULL DEFAULT 0 COMMENT 銷(xiāo)量, status TINYINT NOT NULL DEFAULT 1 COMMENT 狀態(tài) 1上架 0下架, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_goods_sn (goods_sn), KEY idx_category (category_id), KEY idx_status_sales (status, sales DESC) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT旅游商品表;這里有幾個(gè)值得你在答辯時(shí)主動(dòng)提及的設(shè)計(jì)思考goods_sn使用唯一索引而不是直接用自增ID做商品編號(hào)這樣商品編號(hào)對(duì)外暴露時(shí)不會(huì)泄露業(yè)務(wù)量同時(shí)給后續(xù)導(dǎo)入導(dǎo)出留下穩(wěn)定業(yè)務(wù)主鍵。status與sales建立聯(lián)合索引idx_status_sales因?yàn)樯唐妨斜眄?yè)最常見(jiàn)的查詢條件是“上架狀態(tài)下的銷(xiāo)量排行”這個(gè)索引能讓排序查詢走覆蓋索引避免文件排序。價(jià)格類(lèi)型使用DECIMAL(10,2)而不是FLOAT或DOUBLE因?yàn)楦↑c(diǎn)類(lèi)型在金額運(yùn)算時(shí)存在精度丟失問(wèn)題這個(gè)在答辯中經(jīng)常被問(wèn)到。訂單表有一點(diǎn)要特別注意訂單金額必須在后端進(jìn)行計(jì)算前端傳過(guò)來(lái)的金額只能當(dāng)作參考值。你在實(shí)際項(xiàng)目里肯定明白前端傳值等于把業(yè)務(wù)規(guī)則交給客戶端手里用戶隨便改個(gè)參數(shù)就能以0.01元下單。正確的做法是后端根據(jù)商品單價(jià)和數(shù)量實(shí)時(shí)計(jì)算訂單金額再用事務(wù)確保庫(kù)存扣減和訂單生成的一致性。3.4 系統(tǒng)架構(gòu)的分層設(shè)計(jì)從Controller到Mapper的路不能亂關(guān)于后端包結(jié)構(gòu)我推薦按業(yè)務(wù)模塊分包而不是按技術(shù)層次分包。兩種方式各有利弊但對(duì)畢設(shè)來(lái)說(shuō)按模塊分包會(huì)讓你在寫(xiě)代碼時(shí)更自然地思考“這個(gè)功能屬于哪個(gè)業(yè)務(wù)域”比如com.tourism.goods ├── controller // 請(qǐng)求入口 ├── service // 業(yè)務(wù)邏輯層 ├── mapper // 數(shù)據(jù)訪問(wèn)層 ├── entity // 實(shí)體類(lèi) ├── dto // 數(shù)據(jù)傳輸對(duì)象 ├── vo // 視圖對(duì)象 ├── config // 配置類(lèi) ├── common // 通用類(lèi)統(tǒng)一返回結(jié)果、異常處理等 └── utils // 工具類(lèi)接口設(shè)計(jì)上統(tǒng)一返回結(jié)構(gòu)類(lèi)必不可少這是前后端協(xié)作的基礎(chǔ)Data public class ResultT { private Integer code; // 200 成功其他為錯(cuò)誤碼 private String message; // 提示信息 private T data; // 業(yè)務(wù)數(shù)據(jù) public static T ResultT ok(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(操作成功); result.setData(data); return result; } public static T ResultT fail(String message) { ResultT result new Result(); result.setCode(500); result.setMessage(message); return result; } }這個(gè)類(lèi)看著簡(jiǎn)單但它是整個(gè)項(xiàng)目腳手架的地基。有了它Controller里的每個(gè)方法都不需要手動(dòng)拼JSON異常處理器可以統(tǒng)一攔截錯(cuò)誤并包裝成Result返回前端拿到結(jié)果后只需要判斷code字段即可。4. 核心功能模塊的實(shí)現(xiàn)思路與代碼實(shí)踐商品、訂單、統(tǒng)計(jì)逐個(gè)擊破4.1 商品管理模塊設(shè)計(jì)“完整”比“花哨”更重要商品管理的標(biāo)準(zhǔn)功能包括商品列表含分頁(yè)和多條件篩選、新增商品、編輯商品、上下架、批量刪除、導(dǎo)入導(dǎo)出。這可能是你寫(xiě)過(guò)很多遍的CRUD但在旅游商品背景下有兩個(gè)值得深挖的點(diǎn)。第一個(gè)是條件查詢。商品列表頁(yè)的搜索條件通常有商品名稱(chēng)模糊、分類(lèi)ID精確、狀態(tài)精確、價(jià)格區(qū)間范圍、銷(xiāo)量排序、上架時(shí)間排序。用LambdaQueryWrapper可以優(yōu)雅處理這些條件的組合public PageVOGoodsVO queryGoodsPage(GoodsQueryDTO queryDTO) { LambdaQueryWrapperGoods wrapper new LambdaQueryWrapper(); // 關(guān)鍵字搜索 wrapper.like(StringUtils.hasText(queryDTO.getKeyword()), Goods::getName, queryDTO.getKeyword()); // 分類(lèi)篩選 wrapper.eq(queryDTO.getCategoryId() ! null, Goods::getCategoryId, queryDTO.getCategoryId()); // 狀態(tài)篩選 wrapper.eq(queryDTO.getStatus() ! null, Goods::getStatus, queryDTO.getStatus()); // 價(jià)格區(qū)間篩選 wrapper.between(queryDTO.getMinPrice() ! null queryDTO.getMaxPrice() ! null, Goods::getPrice, queryDTO.getMinPrice(), queryDTO.getMaxPrice()); // 排序邏輯 if (sales.equals(queryDTO.getOrderBy())) { wrapper.orderByDesc(Goods::getSales); } else if (price_asc.equals(queryDTO.getOrderBy())) { wrapper.orderByAsc(Goods::getPrice); } else { wrapper.orderByDesc(Goods::getCreateTime); } return pageToVO(goodsMapper.selectPage(new Page(queryDTO.getPageNum(), queryDTO.getPageSize()), wrapper)); }這段代碼沒(méi)有高深的技術(shù)含量但它代表了實(shí)際業(yè)務(wù)開(kāi)發(fā)中的一種重要能力查詢條件的組合拼接能力。每一個(gè)if守衛(wèi)都對(duì)應(yīng)一個(gè)前端可能發(fā)起查詢的邊界情況如果沒(méi)有這些守衛(wèi)空值條件拼接進(jìn)SQL會(huì)產(chǎn)生不可預(yù)期結(jié)果。第二個(gè)是商品上架前必做的庫(kù)存校驗(yàn)和唯一校驗(yàn)。新增商品時(shí)goods_sn需要在數(shù)據(jù)庫(kù)中檢查唯一性否則會(huì)拋出數(shù)據(jù)庫(kù)層異常。項(xiàng)目里應(yīng)當(dāng)先調(diào)用count方法做一次業(yè)務(wù)校驗(yàn)返回給前端明確的提示信息而不是直接報(bào)錯(cuò)。4.2 訂單交易模塊事務(wù)、狀態(tài)機(jī)與并發(fā)扣庫(kù)存訂單流程是整個(gè)系統(tǒng)的核心鏈路扮演著“不能出岔子”的角色。流程大概是用戶在前臺(tái)下單 → 后端校驗(yàn)商品上下架狀態(tài)和庫(kù)存 → 計(jì)算訂單金額 → 生成訂單主記錄和子記錄 → 扣減庫(kù)存 → 模擬支付或走真正的支付接口 → 更新訂單狀態(tài)。為什么必須用事務(wù)你試想一個(gè)場(chǎng)景用戶下單成功后訂單生成了但庫(kù)存沒(méi)扣減或者庫(kù)存扣了但訂單失敗。這兩個(gè)操作有的是“同時(shí)成功”有的是“同時(shí)失敗”。Spring的Transactional就是用來(lái)保證這種一致性的Override Transactional(rollbackFor Exception.class) public OrderVO createOrder(OrderCreateDTO createDTO) { // 1. 校驗(yàn)商品是否存在且上架 Goods goods goodsMapper.selectById(createDTO.getGoodsId()); if (goods null || goods.getStatus() ! 1) { throw new BizException(商品不存在或已下架); } // 2. 校驗(yàn)庫(kù)存充足 if (goods.getStock() createDTO.getQuantity()) { throw new BizException(庫(kù)存不足); } // 3. 計(jì)算訂單金額 BigDecimal totalAmount goods.getPrice() .multiply(BigDecimal.valueOf(createDTO.getQuantity())); // 4. 生成訂單號(hào)時(shí)間戳 隨機(jī)數(shù)或雪花算法 String orderSn generateOrderSn(); // 5. 創(chuàng)建訂單記錄 Orders order new Orders(); order.setOrderSn(orderSn); order.setUserId(createDTO.getUserId()); order.setTotalAmount(totalAmount); order.setStatus(0); // 待支付 // 6. 創(chuàng)建訂單子記錄保存商品快照 // 7. 原子扣減庫(kù)存 int updated goodsMapper.deductStock(createDTO.getGoodsId(), createDTO.getQuantity()); if (updated 0) { throw new BizException(庫(kù)存不足扣減失敗); } // 8. 返回訂單信息 return orderVO; }關(guān)于并發(fā)扣庫(kù)存有一個(gè)老生常談但值得深入說(shuō)明的細(xì)節(jié)不能用select查庫(kù)存再判斷大于0后直接update這樣在并發(fā)場(chǎng)景下會(huì)造成超賣(mài)。比如庫(kù)存剩1件兩個(gè)用戶同時(shí)下單都查到庫(kù)存是1都通過(guò)了檢查然后都執(zhí)行扣減最后庫(kù)存會(huì)變成-1。正確做法是用一條帶條件的UPDATE語(yǔ)句讓數(shù)據(jù)庫(kù)在原子層面完成檢查與扣減UPDATE goods SET stock stock - #{quantity}, sales sales #{quantity} WHERE id #{goodsId} AND stock #{quantity}這條SQL執(zhí)行后如果影響行數(shù)為0就說(shuō)明庫(kù)存不足或商品狀態(tài)有變catch到信號(hào)后直接在業(yè)務(wù)拋異常回滾事務(wù)即可。這個(gè)“原子遞減”方案是電商系統(tǒng)的通用解法也是畢設(shè)答辯時(shí)展示技術(shù)深度的好素材。4.3 統(tǒng)計(jì)分析模塊用少量數(shù)據(jù)展示多維分析思路統(tǒng)計(jì)頁(yè)面的常見(jiàn)展示包括總銷(xiāo)售額、總訂單數(shù)、總商品數(shù)、總用戶數(shù)四個(gè)核心指標(biāo)加上近7日/近30日銷(xiāo)售趨勢(shì)折線圖、商品分類(lèi)銷(xiāo)量占比餅圖、銷(xiāo)量TOP10商品條形圖。這些圖表的實(shí)現(xiàn)方式有兩條路前端用ECharts后端只提供JSON數(shù)據(jù)。這是目前最主流的方案。后端需要針對(duì)性寫(xiě)聚合查詢SQL以近7日銷(xiāo)售趨勢(shì)為例SELECT DATE_FORMAT(create_time, %Y-%m-%d) AS day, COUNT(*) AS order_count, SUM(total_amount) AS sales_amount FROM orders WHERE create_time DATE_SUB(CURDATE(), INTERVAL 7 DAY) AND status ! 4 -- 排除已取消訂單 GROUP BY DATE_FORMAT(create_time, %Y-%m-%d) ORDER BY day;一個(gè)有實(shí)用價(jià)值的擴(kuò)展是加入景區(qū)維度的分析因?yàn)槁糜紊唐泛推胀娚滩煌牡胤骄褪撬壎司皡^(qū)場(chǎng)景。比如統(tǒng)計(jì)“某某景區(qū)相關(guān)商品的銷(xiāo)量占比”“哪個(gè)景區(qū)的關(guān)聯(lián)商品銷(xiāo)售額最高”。這個(gè)分析維度在普通電商系統(tǒng)里是沒(méi)有的恰好能成為本項(xiàng)目的有力差異化展示點(diǎn)。統(tǒng)計(jì)模塊實(shí)現(xiàn)不復(fù)雜但要注意統(tǒng)計(jì)SQL一定要在數(shù)據(jù)庫(kù)端做聚合而不是查出明細(xì)數(shù)據(jù)后在Java里循環(huán)求和。前者利用數(shù)據(jù)庫(kù)索引和聚合引擎效率高幾倍后者一旦數(shù)據(jù)量上來(lái)就會(huì)內(nèi)存溢出。這也是答辯時(shí)考察“你對(duì)大數(shù)據(jù)量處理有沒(méi)有敬畏心”的經(jīng)典問(wèn)題。4.4 首頁(yè)數(shù)據(jù)聚合接口一次請(qǐng)求返回多模塊數(shù)據(jù)前臺(tái)首頁(yè)通常包含輪播圖、熱門(mén)商品、新品上市、為你推薦等模塊。這些數(shù)據(jù)各自需要訪問(wèn)不同表如果前端分別調(diào)七八個(gè)接口不僅慢而且代碼凌亂。更好的方案是后端提供一個(gè)聚合接口一次返回首頁(yè)全部數(shù)據(jù)。GetMapping(/home) public ResultHomeVO getHomeData() { HomeVO homeVO new HomeVO(); // 輪播圖 - 狀態(tài)為啟用的banner homeVO.setBanners(bannerService.listEnabled()); // 熱門(mén)商品 - 銷(xiāo)量前8 LambdaQueryWrapperGoods hotWrapper new LambdaQueryWrapper(); hotWrapper.eq(Goods::getStatus, 1).orderByDesc(Goods::getSales).last(LIMIT 8); homeVO.setHotGoods(goodsMapper.selectList(hotWrapper)); // 新品上市 - 上架時(shí)間最新 LambdaQueryWrapperGoods newWrapper new LambdaQueryWrapper(); newWrapper.eq(Goods::getStatus, 1).orderByDesc(Goods::getCreateTime).last(LIMIT 8); homeVO.setNewGoods(goodsMapper.selectList(newWrapper)); // 推薦列表基于協(xié)同過(guò)濾見(jiàn)下一節(jié) homeVO.setRecommendGoods(recommendService.recommend(1L, 8)); return Result.ok(homeVO); }這種“BFFBackend For Frontend聚合模式”在實(shí)際企業(yè)開(kāi)發(fā)中隨處可見(jiàn)——后端不為每個(gè)數(shù)據(jù)模塊單獨(dú)暴露接口而是為端上的特定頁(yè)面組織一份最優(yōu)的數(shù)據(jù)結(jié)構(gòu)。把這個(gè)思路寫(xiě)進(jìn)畢業(yè)設(shè)計(jì)文檔的“設(shè)計(jì)亮點(diǎn)”部分面試官看過(guò)后通常會(huì)眼前一亮。5. “大數(shù)據(jù)技術(shù)”核心亮點(diǎn)的實(shí)現(xiàn)基于共現(xiàn)關(guān)系的商品推薦5.1 為什么選協(xié)同過(guò)濾而不是更復(fù)雜的算法很多同學(xué)一提到推薦就想上機(jī)器學(xué)習(xí)、深度學(xué)習(xí)其實(shí)大可不必。原因有兩個(gè)第一畢設(shè)階段的項(xiàng)目沒(méi)有足夠的數(shù)據(jù)量來(lái)訓(xùn)練復(fù)雜模型強(qiáng)行做深度學(xué)習(xí)只會(huì)得到一個(gè)“過(guò)擬合到只有幾十條交互記錄”的玩具。第二論文答辯時(shí)評(píng)委更看重的是“你對(duì)算法思想的理解以及你根據(jù)場(chǎng)景做了哪些合理簡(jiǎn)化”而不是你不會(huì)跑一個(gè)又大又空的模型。協(xié)同過(guò)濾家族中最適合本項(xiàng)目的是基于物品的協(xié)同過(guò)濾Item-based Collaborative Filtering。它的核心思想用一句話概括喜歡物品A的用戶通常也喜歡物品B——基于“用戶對(duì)歷史行為數(shù)據(jù)”的分析把與目標(biāo)商品高度關(guān)聯(lián)的其他商品推薦給用戶。比如用戶買(mǎi)了“黃山風(fēng)景區(qū)成人門(mén)票”系統(tǒng)就可以推薦“山頂酒店早餐券”“登山杖租賃券”等關(guān)聯(lián)商品。5.2 共現(xiàn)矩陣推薦算法的簡(jiǎn)化實(shí)現(xiàn)基于物品的協(xié)同過(guò)濾實(shí)現(xiàn)思路分解為三步第一步從訂單明細(xì)中提取“商品共現(xiàn)關(guān)系”。統(tǒng)計(jì)哪些商品出現(xiàn)在同一個(gè)訂單里。比如訂單A包含商品1和商品2訂單B包含商品1和商品3那么商品1與商品2、商品3都產(chǎn)生了一次共現(xiàn)。第二步計(jì)算商品間的相似度。用“共同被購(gòu)買(mǎi)的頻率”來(lái)近似商品之間的相似度。一種簡(jiǎn)單有效的計(jì)算方式是Jaccard相似度sim(A, B) |購(gòu)買(mǎi)A也購(gòu)買(mǎi)B的用戶數(shù)| / |購(gòu)買(mǎi)A或購(gòu)買(mǎi)B的用戶數(shù)|但Jaccard有個(gè)問(wèn)題熱門(mén)商品會(huì)把相似度稀釋。更常用的是“共現(xiàn)次數(shù)的歸一化”。對(duì)于畢設(shè)項(xiàng)目而言用戶量不大直接用“共同出現(xiàn)在同一訂單中的次數(shù)作為相似度分?jǐn)?shù)”再按分?jǐn)?shù)排序取TOP-N即可。第三步生成推薦列表。當(dāng)用戶查看商品A時(shí)找出與A最相似的前K個(gè)商品扣除用戶已購(gòu)買(mǎi)過(guò)的商品即得到“看了又看”的推薦列表。用一段SQL加少量Java邏輯就能實(shí)現(xiàn)從order_item表中找出所有“包含商品A的訂單”再找出這些訂單中出現(xiàn)的“其他商品”按出現(xiàn)次數(shù)降序排列。SELECT oi2.goods_id, COUNT(*) AS co_count FROM order_item oi1 JOIN order_item oi2 ON oi1.order_id oi2.order_id WHERE oi1.goods_id #{goodsId} AND oi2.goods_id ! #{goodsId} GROUP BY oi2.goods_id ORDER BY co_count DESC LIMIT #{limit}這樣一段SQL在答辯時(shí)能清晰地展示了你對(duì)數(shù)據(jù)庫(kù)關(guān)聯(lián)查詢、子查詢、聚合分組的熟練度又確實(shí)落地了推薦算法的核心步驟。如果還要進(jìn)一步說(shuō)明“為什么不用Spark”——你可以說(shuō)系統(tǒng)現(xiàn)階段數(shù)據(jù)量在百萬(wàn)級(jí)以內(nèi)單機(jī)關(guān)系型數(shù)據(jù)庫(kù)的聚合性能已足夠支撐秒級(jí)響應(yīng)若后續(xù)數(shù)據(jù)規(guī)模增長(zhǎng)可將共現(xiàn)矩陣計(jì)算遷移至Spark離線批處理架構(gòu)上預(yù)留了擴(kuò)展路徑。這句話一出來(lái)“大數(shù)據(jù)技術(shù)”在系統(tǒng)里的融入點(diǎn)就是真實(shí)可信的。5.3 推薦接口的降級(jí)策略代碼之外的工程意識(shí)推薦模塊的調(diào)用鏈“商品ID → 共現(xiàn)查詢 → 排序去重 → 過(guò)濾已購(gòu)”如果用戶或商品沒(méi)有歷史訂單數(shù)據(jù)共現(xiàn)查詢結(jié)果為空。這種空狀態(tài)必須有降級(jí)處理返回銷(xiāo)量排行TOP-N作為“默認(rèn)推薦”。這個(gè)設(shè)計(jì)不是復(fù)雜但體現(xiàn)的是工程上的魯棒性思維——線上系統(tǒng)最怕的不是數(shù)據(jù)不夠準(zhǔn)確而是接口報(bào)錯(cuò)。public ListGoods recommendByItem(Long goodsId, int limit, Long userId) { ListGoods result itemCFService.recommend(goodsId, limit); if (result.isEmpty()) { // 冷啟動(dòng)降級(jí)返回?zé)徜N(xiāo)商品 LambdaQueryWrapperGoods wrapper new LambdaQueryWrapper(); wrapper.eq(Goods::getStatus, 1).orderByDesc(Goods::getSales).last(LIMIT limit); result goodsMapper.selectList(wrapper); } return result; }6. 從代碼到可演示數(shù)據(jù)庫(kù)初始化腳本、測(cè)試數(shù)據(jù)與前端適配的坑6.1 數(shù)據(jù)庫(kù)初始化腳本的標(biāo)準(zhǔn)化寫(xiě)法一個(gè)完整的畢設(shè)項(xiàng)目源碼包和數(shù)據(jù)庫(kù)腳本必須是完全匹配的我見(jiàn)過(guò)太多項(xiàng)目和SQL腳本對(duì)不上導(dǎo)致跑不起來(lái)的情況。你在交付時(shí)數(shù)據(jù)庫(kù)腳本應(yīng)該包含1_schema.sql建庫(kù)、建表語(yǔ)句包含所有外鍵和索引2_data.sql基礎(chǔ)數(shù)據(jù)包括管理員賬號(hào)BCrypt加密后的密碼、菜單權(quán)限、基礎(chǔ)分類(lèi)、測(cè)試商品和測(cè)試訂單數(shù)據(jù)3_reset.sql清理業(yè)務(wù)表數(shù)據(jù)、重置自增ID的語(yǔ)句方便多次重啟演示時(shí)復(fù)位測(cè)試數(shù)據(jù)的生成上有一個(gè)前人經(jīng)驗(yàn)用Python腳本批量生成模擬用戶、訂單和瀏覽記錄數(shù)據(jù)比手寫(xiě)SQL快十倍。你可以用腳本隨機(jī)組合用戶ID、商品ID、數(shù)量、下單時(shí)間生成千條量級(jí)的訂單數(shù)據(jù)然后導(dǎo)入MySQL。這些數(shù)據(jù)不僅讓首頁(yè)圖表看起來(lái)豐富也讓推薦算法具備有效的計(jì)算輸入。我建議訂單數(shù)據(jù)至少生成500條以上日期范圍覆蓋近30天這樣趨勢(shì)圖才有“曲線感”。6.2 對(duì)接前端時(shí)最容易出現(xiàn)的聯(lián)調(diào)問(wèn)題和解決思路日期格式化錯(cuò)亂。后端返回java.util.Date或LocalDateTime時(shí)默認(rèn)序列化格式可能是Redis通用的時(shí)間戳或者ISO字符串和前端ECharts的期望格式對(duì)不上。統(tǒng)一配置Jackson格式化spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8如果是LocalDateTime類(lèi)型還需要額外引入jackson-datatype-jsr310模塊Spring Boot在spring-boot-starter-web中已包含并配置spring: jackson: serialization: write-dates-as-timestamps: false跨域問(wèn)題。本地開(kāi)發(fā)時(shí)前端比如Vite默認(rèn)端口5173和后端8080端口分屬兩個(gè)域名瀏覽器會(huì)執(zhí)行跨域攔截。Spring Boot后端最簡(jiǎn)單的處理方式是新建一個(gè)Cors配置類(lèi)Configuration public class CorsConfig { Bean public CorsFilter corsFilter() { CorsConfiguration config new CorsConfiguration(); config.addAllowedOriginPattern(*); config.addAllowedMethod(*); config.addAllowedHeader(*); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration(/**, config); return new CorsFilter(source); } }注意涉及登錄校驗(yàn)的接口不要放開(kāi)所有origin生產(chǎn)環(huán)境要配置白名單畢業(yè)設(shè)計(jì)本地演示階段可以放行。圖片上傳與訪問(wèn)路徑。商品圖片不能只存在后端服務(wù)器本地磁盤(pán)否則換個(gè)環(huán)境演示就得重新傳圖。推薦簡(jiǎn)單的方案在application.yml里配置upload.dir為本地某個(gè)目錄同時(shí)建一個(gè)/images/**的靜態(tài)資源映射指向該目錄圖片URL返回相對(duì)路徑。如果條件允許直接上OSS或七牛云對(duì)象存儲(chǔ)——這一行在簡(jiǎn)歷上寫(xiě)“熟悉云存儲(chǔ)SDK接入”也是個(gè)加分項(xiàng)。6.3 演示環(huán)境的穩(wěn)定優(yōu)先原則部署到哪怎么啟動(dòng)答辯演示那天什么意外都可能發(fā)生。我最慘的一次經(jīng)歷是現(xiàn)場(chǎng)電腦沒(méi)有安裝JDK好在提前打包了可執(zhí)行JAR臨時(shí)裝了Java 8才勉強(qiáng)救場(chǎng)。所以演示前請(qǐng)注意本機(jī)務(wù)必安裝JDK 8或JDK 11并配置好JAVA_HOME項(xiàng)目打包用mvn clean package確保生成可執(zhí)行JAR數(shù)據(jù)庫(kù)腳本執(zhí)行后用一個(gè)可以一鍵重置的reset.sql復(fù)位準(zhǔn)備一臺(tái)備用電腦或者至少把演示視頻錄一份放U盤(pán)里數(shù)據(jù)庫(kù)連接配置不要寫(xiě)死IP用jdbc:mysql://localhost:3306/tourism_goods?serverTimezoneAsia/Shanghai這類(lèi)相對(duì)配置7. 萬(wàn)文文檔的寫(xiě)作策略論文字?jǐn)?shù)與質(zhì)量如何平衡7.1 目錄結(jié)構(gòu)讓老師一眼看到你要寫(xiě)什么畢設(shè)文檔不是隨筆它需要嚴(yán)格遵循學(xué)校模板但內(nèi)容詳略完全可以自己把控。一份合格的Spring Boot系統(tǒng)設(shè)計(jì)文檔至少應(yīng)該包含以下章節(jié)緒論背景、意義、國(guó)內(nèi)外研究現(xiàn)狀、主要工作需求分析可行性分析、功能需求、非功能需求、用例圖系統(tǒng)設(shè)計(jì)總體架構(gòu)圖、功能模塊設(shè)計(jì)、數(shù)據(jù)庫(kù)設(shè)計(jì)、接口設(shè)計(jì)系統(tǒng)實(shí)現(xiàn)各核心模塊的關(guān)鍵代碼與界面展示系統(tǒng)測(cè)試測(cè)試環(huán)境、功能測(cè)試用例、測(cè)試結(jié)果分析總結(jié)與展望很多同學(xué)最頭疼的是第一個(gè)章節(jié)“研究現(xiàn)狀”不知道寫(xiě)什么。我的建議是不要寫(xiě)空泛的趨勢(shì)要寫(xiě)具體的工程背景。你可以用一兩段談旅游行業(yè)數(shù)字化轉(zhuǎn)型背景下旅游商品的線上銷(xiāo)售管理需求增長(zhǎng)引出系統(tǒng)建設(shè)的必要性再對(duì)照一兩篇優(yōu)秀碩士論文的研究現(xiàn)狀說(shuō)明自己的工作在哪些方面做了簡(jiǎn)化、在哪些方面做了適配。這種有實(shí)質(zhì)內(nèi)容的寫(xiě)法導(dǎo)師看起來(lái)會(huì)舒服得多也不容易被判定為“網(wǎng)上復(fù)制粘貼”。7.2 核心實(shí)現(xiàn)章節(jié)的寫(xiě)作技巧先圖后碼再解釋文檔中的第三章和第四章最核心也是最應(yīng)該下功夫的地方。好的做法是先放設(shè)計(jì)圖/流程圖/ER圖再放關(guān)鍵代碼片段最后用200字左右的文字解釋代碼的設(shè)計(jì)意圖和亮點(diǎn)。這樣每一頁(yè)都有圖表支撐視覺(jué)上不會(huì)大段全是文字閱讀體驗(yàn)也好。特別提醒一點(diǎn)代碼不要貼完整類(lèi)只貼核心方法即可。一個(gè)完整的Mapper類(lèi)可能有幾百行全文放進(jìn)去浪費(fèi)頁(yè)碼且沒(méi)有閱讀價(jià)值。但像createOrder這種包含事務(wù)注解、業(yè)務(wù)校驗(yàn)、庫(kù)存扣減三步邏輯的核心方法值得完整呈現(xiàn)并配上解釋。選代碼的邏輯是選“能體現(xiàn)你思考過(guò)程的方法”而不是“看起來(lái)很長(zhǎng)的文件”。7.3 測(cè)試章節(jié)的落地方式基于功能的用例設(shè)計(jì)關(guān)于測(cè)試章節(jié)很多同學(xué)只會(huì)寫(xiě)“運(yùn)行成功”老師根本不信。標(biāo)準(zhǔn)做法是列出功能模塊清單每張表給幾條具體的測(cè)試用例包含前置條件、操作步驟、預(yù)期結(jié)果、實(shí)際結(jié)果、是否通過(guò)。舉一個(gè)示例用例編號(hào)TC-GOODS-003測(cè)試內(nèi)容商品上下架狀態(tài)切換前置條件管理員已登錄存在一條狀態(tài)為“上架”的商品記錄操作步驟1. 進(jìn)入商品管理列表頁(yè)2. 點(diǎn)擊目標(biāo)商品的“下架”按鈕3. 列表頁(yè)刷新預(yù)期結(jié)果商品狀態(tài)變更為“下架”前臺(tái)首頁(yè)不再展示該商品實(shí)際結(jié)果狀態(tài)變更成功前臺(tái)首頁(yè)已不再展示該商品結(jié)論通過(guò)這樣的測(cè)試用例寫(xiě)20到25條覆蓋商品管理、分類(lèi)管理、訂單管理、用戶登錄、權(quán)限校驗(yàn)、首頁(yè)聚合、數(shù)據(jù)統(tǒng)計(jì)幾個(gè)核心模塊文檔的“測(cè)試”章節(jié)就有了厚度支撐。8. 我踩過(guò)的坑和給你的避坑清單做這類(lèi)系統(tǒng)很多問(wèn)題不是不會(huì)寫(xiě)而是在寫(xiě)的過(guò)程中姿勢(shì)不對(duì)白白浪費(fèi)時(shí)間和情緒。我把自己實(shí)操里踩過(guò)的坑按“高發(fā)頻率”列出來(lái)算是這篇博文最有價(jià)值的部分之一。第一個(gè)坑上來(lái)就寫(xiě)代碼沒(méi)畫(huà)ER圖做到一半推倒重來(lái)。我見(jiàn)過(guò)太多學(xué)弟的項(xiàng)目商品表里直接沒(méi)有分類(lèi)表分類(lèi)用一個(gè)字符串字段裝“文創(chuàng)/特產(chǎn)/門(mén)票/酒店”等做到統(tǒng)計(jì)模塊才發(fā)現(xiàn)按分類(lèi)統(tǒng)計(jì)根本沒(méi)法用字符串做精確聚合。我的經(jīng)驗(yàn)是前夕花4到6小時(shí)把ER圖和字段清單整理出來(lái)找導(dǎo)師或同學(xué)確認(rèn)一遍再進(jìn)入開(kāi)發(fā)。這個(gè)時(shí)間投入的收益比非常高。第二個(gè)坑密碼明文存儲(chǔ)。別覺(jué)得畢設(shè)無(wú)所謂答辯時(shí)老師隨便看一眼數(shù)據(jù)庫(kù)就會(huì)問(wèn)“你的密碼為什么是明文” 用Spring Security的BCryptPasswordEncoder加密一行代碼的事但體現(xiàn)的是安全意識(shí)。你自己看這類(lèi)項(xiàng)目時(shí)也留意一下明文密碼出現(xiàn)在任何交付物里都是低級(jí)錯(cuò)誤。第三個(gè)坑前端素材的版權(quán)和加載問(wèn)題。很多同學(xué)喜歡直接從網(wǎng)上拖一堆圖片當(dāng)商品圖演示時(shí)圖片加載不出來(lái)會(huì)顯得很廉價(jià)。建議用本地占位圖或者用picsum這種穩(wěn)定圖源并確保圖片上傳到項(xiàng)目附帶的resources目錄或云存儲(chǔ)而不是依賴(lài)外鏈。旅游商品場(chǎng)景下可以用景點(diǎn)風(fēng)光類(lèi)無(wú)版權(quán)圖片網(wǎng)會(huì)顯得更專(zhuān)業(yè)。第四個(gè)坑事務(wù)不生效的經(jīng)典誤用。Transactional默認(rèn)只在拋出RuntimeException時(shí)回滾如果你在事務(wù)方法里自己用try-catch把異常吃了事務(wù)就會(huì)照常提交扣庫(kù)存和生成訂單就會(huì)變成兩個(gè)獨(dú)立的行為。做訂單模塊時(shí)不要在createOrder內(nèi)部catch未知異常而是向上拋由全局異常處理器處理并返回統(tǒng)一錯(cuò)誤提示。第五個(gè)坑文檔和代碼版本對(duì)不上。交材料前務(wù)必核對(duì)文檔里的核心代碼片段、數(shù)據(jù)庫(kù)腳本和實(shí)際項(xiàng)目完全一致。評(píng)分時(shí)最尷尬的就是老師翻你的論文找到了一個(gè)跟你項(xiàng)目里根本不存在的類(lèi)名或方法名。9. 寫(xiě)在最后從能運(yùn)行到講得出如果你已經(jīng)看到這里我要把最想說(shuō)的一句話放在結(jié)尾畢業(yè)設(shè)計(jì)評(píng)分的分水嶺從來(lái)不是系統(tǒng)能不能跑起來(lái)而是你對(duì)自己的系統(tǒng)能不能講出“為什么這么設(shè)計(jì)”。能夠運(yùn)行是基本盤(pán)但“為什么這里用Redis”“為什么這里用事務(wù)”“為什么推薦算法選協(xié)同過(guò)濾”“為什么庫(kù)存扣減用原子SQL”這些才是答辯老師在提問(wèn)環(huán)節(jié)真正想聽(tīng)到的內(nèi)容。我用自己帶項(xiàng)目的一個(gè)標(biāo)準(zhǔn)來(lái)給你做自檢找一個(gè)完全不了解你項(xiàng)目的同學(xué)讓他拿到你的系統(tǒng)的演示視頻、源碼、數(shù)據(jù)庫(kù)腳本和論文看完后向你提問(wèn)20個(gè)問(wèn)題。如果這20個(gè)問(wèn)題你都能順利答上來(lái)那你的畢業(yè)設(shè)計(jì)無(wú)論從功能還是從展示角度看都已經(jīng)超越了平均水準(zhǔn)。技術(shù)選型、數(shù)據(jù)結(jié)構(gòu)、代碼實(shí)現(xiàn)、文檔寫(xiě)作——每個(gè)環(huán)節(jié)單獨(dú)看都不難但它們組合在一起需要的正是耐心、邏輯和工程意識(shí)。給自己留足時(shí)間按我上面建議的順序一步步推進(jìn)你會(huì)發(fā)現(xiàn)做到“能夠清晰講出自己的系統(tǒng)”這個(gè)目標(biāo)并沒(méi)有想象中遙遠(yuǎn)。