1. 畢業(yè)季旅游平臺(tái)的項(xiàng)目定位與業(yè)務(wù)邊界每年六七月大學(xué)的班級(jí)群和宿舍群里總會(huì)冒出大量畢業(yè)旅行求組隊(duì)求推薦路線的消息。畢業(yè)旅行和普通旅游的最大區(qū)別在于這不是一次說(shuō)走就走的個(gè)人行程而是一個(gè)涉及多人統(tǒng)籌、預(yù)算分?jǐn)?、時(shí)間協(xié)調(diào)的集體項(xiàng)目。有人管錢(qián)有人管路線有人管拍照還有人負(fù)責(zé)對(duì)付那些都可以型選手——你問(wèn)他想去哪他說(shuō)隨便你定了方案他又說(shuō)不好。做過(guò)一次班級(jí)畢業(yè)旅行組織工作的人應(yīng)該都能體會(huì)這種需求采集靠接龍、路線規(guī)劃靠百度、費(fèi)用核算靠備忘錄的原始狀態(tài)。這個(gè)項(xiàng)目的出發(fā)點(diǎn)就是把上面這一堆亂糟糟的線下協(xié)作搬到一個(gè)Web平臺(tái)上。系統(tǒng)的角色模型很清晰普通學(xué)生用戶能夠?yàn)g覽和報(bào)名畢業(yè)旅行路線、提交定制需求班級(jí)或團(tuán)體組織者可以創(chuàng)建團(tuán)體行程、發(fā)起成員邀請(qǐng)、分?jǐn)傎M(fèi)用并統(tǒng)一管理報(bào)名名單旅游服務(wù)商或管理員則負(fù)責(zé)發(fā)布路線方案、處理定制訂單、維護(hù)景點(diǎn)和酒店資源。整個(gè)系統(tǒng)背后有一個(gè)核心業(yè)務(wù)邏輯它服務(wù)的是一群人一起定制一次旅行而不是一個(gè)人自己訂一張票。這個(gè)定位差異直接影響了好幾個(gè)設(shè)計(jì)決策。比如訂單表必須區(qū)分個(gè)人訂單和團(tuán)體訂單團(tuán)隊(duì)訂單的狀態(tài)流轉(zhuǎn)比個(gè)人訂單復(fù)雜得多——有人繳費(fèi)了有人還沒(méi)繳有人臨時(shí)退出需要退款有人想改行程方案。再比如路線推薦不能只按景點(diǎn)熱度排序還要考慮一個(gè)班級(jí)幾十號(hào)人的集合地點(diǎn)、預(yù)算區(qū)間、出行天數(shù)。我當(dāng)時(shí)做這個(gè)項(xiàng)目的時(shí)候最深的體會(huì)是業(yè)務(wù)邊界想清楚了表結(jié)構(gòu)自然就出來(lái)了業(yè)務(wù)邊界含糊后邊所有代碼都在打補(bǔ)丁。這個(gè)項(xiàng)目適合兩類人參考一類是準(zhǔn)備做畢業(yè)設(shè)計(jì)的Java方向?qū)W生它涵蓋的技術(shù)面比較均衡——Spring Boot、MyBatis、前端頁(yè)面、權(quán)限管理、訂單狀態(tài)機(jī)、文件上傳下載足夠撐起一個(gè)合格畢設(shè)的體量另一類是工作中需要快速搭建一個(gè)中小型業(yè)務(wù)系統(tǒng)的人可以重點(diǎn)看我后面講到的訂單狀態(tài)設(shè)計(jì)和團(tuán)體資金分?jǐn)偹悸贰?. 為什么選Spring Boot做底座時(shí)序、依賴與工程結(jié)構(gòu)現(xiàn)在Spring Boot幾乎成了Java Web項(xiàng)目的默認(rèn)起點(diǎn)但做這個(gè)項(xiàng)目時(shí)還是有幾個(gè)人問(wèn)我為什么不用傳統(tǒng)的SSM分層再加一堆XML配置為什么不用現(xiàn)成的若依框架直接二開(kāi)2.1 Spring Boot解決的核心痛點(diǎn)傳統(tǒng)SSM時(shí)代一個(gè)項(xiàng)目從零搭建要經(jīng)歷引入十多個(gè)Maven依賴、配置web.xml、配置spring-mvc.xml、配置mybatis-config.xml、配置數(shù)據(jù)源、處理靜態(tài)資源映射……光是把環(huán)境跑起來(lái)就能耗掉一兩天。而Spring Boot的自動(dòng)配置機(jī)制把大部分重復(fù)勞動(dòng)收掉了它的核心邏輯可以理解為classpath里有Spring MVC的依賴我就自動(dòng)幫你配好DispatcherServlet有HikariCP和mysql驅(qū)動(dòng)我就自動(dòng)幫你配好數(shù)據(jù)源。項(xiàng)目里只需要保留那些我這套系統(tǒng)特有的配置——比如自定義攔截器要注冊(cè)、Redis連接參數(shù)要指定、文件上傳大小要放開(kāi)。我用的是Spring Boot 2.x系列Java 8這個(gè)組合今天看起來(lái)不算最前沿但作為框架學(xué)習(xí)項(xiàng)目非常穩(wěn)。Spring Boot 3.x要求Java 17起步換了javax到j(luò)akarta的包名很多教程和案例還停留在老寫(xiě)法對(duì)于畢設(shè)來(lái)說(shuō)如果導(dǎo)師給的參考代碼、學(xué)校機(jī)房環(huán)境都偏向老一套用3.x反而容易把自己卡住。我的建議是如果不追求版本號(hào)好看2.7.x是當(dāng)下兼容性最好、踩坑信息最全的選擇。2.2 關(guān)于要不要自己寫(xiě)前端這個(gè)平臺(tái)的前端部分我最終采用了服務(wù)端模板加少量原生JavaScript的方案。原因有三第一這是畢設(shè)核心評(píng)分點(diǎn)在業(yè)務(wù)邏輯和技術(shù)棧覆蓋把大量精力花在Vue或React腳手架搭建上性價(jià)比不高第二后端渲染對(duì)于權(quán)限控制、登錄態(tài)校驗(yàn)這些場(chǎng)景天然友好頁(yè)面跳轉(zhuǎn)時(shí)后端攔截器直接把關(guān)不容易出現(xiàn)接口裸露的越權(quán)問(wèn)題第三Thymeleaf和JSP這類模板技術(shù)的學(xué)習(xí)曲線平緩改起來(lái)快出現(xiàn)問(wèn)題時(shí)腦子里能完整還原請(qǐng)求到響應(yīng)的鏈路。如果你前端能力比較強(qiáng)用前后端分離加Vue會(huì)是個(gè)加分項(xiàng)API文檔寫(xiě)到Swagger里答辯時(shí)展示接口測(cè)試截圖也好看。但要注意一個(gè)現(xiàn)實(shí)問(wèn)題前后端分離意味著你在處理跨域、Token刷新、接口鑒權(quán)這些環(huán)節(jié)都要額外花時(shí)間而且答辯時(shí)老師可能會(huì)盯著前端源碼問(wèn)雙向綁定原理。我自己見(jiàn)過(guò)不少同學(xué)前后端分離做了兩個(gè)月最后卡在nginx部署環(huán)節(jié)反而得不償失。2.3 我的標(biāo)準(zhǔn)工程結(jié)構(gòu)清單一個(gè)清晰的分層結(jié)構(gòu)是這個(gè)項(xiàng)目后面不失控的關(guān)鍵。我的目錄組織如下com.example.travel ├── controller // 控制層只做參數(shù)接收與結(jié)果封裝 │ ├── admin // 后臺(tái)管理接口 │ ├── user // 用戶端接口 │ └── order // 訂單相關(guān)接口 ├── service // 業(yè)務(wù)層核心邏輯全部寫(xiě)在這里 │ ├── impl // 接口實(shí)現(xiàn) ├── mapper // MyBatis的Mapper接口 ├── entity // 數(shù)據(jù)庫(kù)實(shí)體類也可叫pojo/domain ├── dto // 數(shù)據(jù)傳輸對(duì)象接收前端參數(shù) ├── vo // 視圖對(duì)象返回前端數(shù)據(jù) ├── config // 配置類攔截器、跨域、上傳配置等 ├── common // 通用返回結(jié)果、異常處理、工具類 └── TravelApplication.java這里我特別想強(qiáng)調(diào)一點(diǎn)不要為了圖省事把業(yè)務(wù)邏輯直接寫(xiě)在Controller里。我見(jiàn)過(guò)很多人寫(xiě)一人端項(xiàng)目所有代碼堆在Controller里兩三行搞定一個(gè)方法看起來(lái)很快但等你寫(xiě)訂單狀態(tài)流轉(zhuǎn)、退款邏輯、多人報(bào)名費(fèi)用分?jǐn)傔@些復(fù)雜業(yè)務(wù)時(shí)沒(méi)有Service層兜底代碼會(huì)迅速膨脹到完全無(wú)法維護(hù)。一個(gè)實(shí)用的判斷標(biāo)準(zhǔn)是Controller方法里如果出現(xiàn)了if-else分支超過(guò)三層或者需要連續(xù)調(diào)用三次以上mapper方法這段邏輯就該下沉到Service。3. 一站式定制的核心鏈路從需求采集到訂單落地這個(gè)平臺(tái)叫一站式定制那它到底定制了什么口頭說(shuō)一個(gè)概念很容易但落到系統(tǒng)功能上必須把定制流程拆成一條用戶能感知到的主干鏈路。我最終把它拆成了四個(gè)環(huán)節(jié)發(fā)起需求、智能推薦、方案確認(rèn)、支付成團(tuán)。3.1 需求采集模塊的業(yè)務(wù)模型畢業(yè)旅行需求不是一張簡(jiǎn)單的姓名手機(jī)號(hào)想去哪表單。我的需求表travel_demand字段設(shè)計(jì)為出行天數(shù)、出發(fā)城市、預(yù)算范圍、偏好主題海邊/古鎮(zhèn)/爬山/城市漫游、成團(tuán)人數(shù)、期望出行日期段、特殊要求備注。之所以把出發(fā)城市單獨(dú)拎出來(lái)是因?yàn)楫厴I(yè)旅行的集合出發(fā)地高度集中在學(xué)校所在城市服務(wù)商在設(shè)計(jì)路線時(shí)必須從指定城市出發(fā)才能談成團(tuán)。這個(gè)模塊最容易忽略的是成團(tuán)人數(shù)字段。個(gè)人可以一個(gè)人發(fā)起定制但服務(wù)商能否接單取決于人數(shù)是否達(dá)到可盈利的成團(tuán)線。所以我給系統(tǒng)加入了一個(gè)規(guī)則需求提交后進(jìn)入待匹配狀態(tài)后臺(tái)服務(wù)商可以瀏覽需求池符合條件則報(bào)價(jià)接單如果需求在72小時(shí)內(nèi)無(wú)人接單狀態(tài)自動(dòng)變?yōu)槲雌ヅ溆脩艨梢允盏教崾静⒄{(diào)整參數(shù)重新提交。這個(gè)邏輯讓定制服務(wù)不是一句空話而是變成了系統(tǒng)里真實(shí)跑得通的狀態(tài)流轉(zhuǎn)。3.2 路線推薦權(quán)重評(píng)分而不是猜你喜歡很多同學(xué)做推薦功能一上來(lái)就寫(xiě)協(xié)同過(guò)濾但畢業(yè)旅行平臺(tái)的場(chǎng)景下數(shù)據(jù)稀疏是硬傷——新用戶沒(méi)有行為歷史新路線沒(méi)有評(píng)分?jǐn)?shù)據(jù)你拿什么算相似度這個(gè)平臺(tái)上我更傾向于做一個(gè)基于規(guī)則的路線匹配引擎。具體做法是給每條路線打上屬性標(biāo)簽主題、天數(shù)、預(yù)算檔位、出發(fā)城市、人均價(jià)格用戶提交需求后按以下規(guī)則計(jì)分主題匹配權(quán)重50分天數(shù)落在期望區(qū)間內(nèi)權(quán)重30分預(yù)算差值最小權(quán)重15分價(jià)格比期望高太多直接淘汰近30天下單人數(shù)權(quán)重5分最后按總分排序推薦Top5。這個(gè)方案實(shí)現(xiàn)簡(jiǎn)單、解釋性強(qiáng)答辯的時(shí)候你能跟老師講清楚每一分是怎么來(lái)的比黑盒式推薦算法更容易獲得認(rèn)可。而且畢業(yè)旅行本來(lái)就帶有很強(qiáng)的社交屬性用戶更看重跟誰(shuí)去而不是平臺(tái)推什么算法在這里的位置本來(lái)就應(yīng)該輕一些。3.3 團(tuán)體行程的組裝邏輯團(tuán)體項(xiàng)目和個(gè)人項(xiàng)目的根本區(qū)別在于個(gè)人項(xiàng)目選好路線直接下單即可團(tuán)體項(xiàng)目則需要先有團(tuán)再往團(tuán)里加人最后才談路線定制和費(fèi)用。我在系統(tǒng)里設(shè)計(jì)了旅行團(tuán)表travel_group和成員表group_member前者存團(tuán)長(zhǎng)ID、成團(tuán)人數(shù)上限、當(dāng)前狀態(tài)招募中/定制中/已成團(tuán)/已出行/已完成后者記錄每個(gè)成員的報(bào)名狀態(tài)和繳費(fèi)狀態(tài)。這里有個(gè)細(xì)節(jié)值得展開(kāi)團(tuán)體報(bào)名是允許部分成員先報(bào)名、其他人后續(xù)加入的所以成員表里必須有個(gè)獨(dú)立的報(bào)名字段而不是用訂單狀態(tài)去隱式推斷。我把每個(gè)成員的參與狀態(tài)做成獨(dú)立枚舉待確認(rèn)、已確認(rèn)、已繳費(fèi)、已退款、已退出。這樣團(tuán)長(zhǎng)看到的數(shù)據(jù)就是一張誰(shuí)還沒(méi)繳費(fèi)列表系統(tǒng)的催繳通知可以根據(jù)這張表精準(zhǔn)發(fā)送到人而不是群發(fā)全團(tuán)造成困惑。3.4 訂單狀態(tài)機(jī)與實(shí)際金額計(jì)算訂單表我把狀態(tài)設(shè)計(jì)成待付款PENDING、已付款PAID、定制中CUSTOMIZING、待出行UPCOMING、已完成COMPLETED、已取消CANCELLED、已退款REFUNDED。后端不是用一堆散落的if判斷處理這些狀態(tài)的而是抽出了一個(gè)狀態(tài)機(jī)工具類統(tǒng)一維護(hù)狀態(tài)流轉(zhuǎn)的合法性/** * 訂單狀態(tài)流轉(zhuǎn)校驗(yàn) * key: 當(dāng)前狀態(tài), value: 允許流轉(zhuǎn)到的目標(biāo)狀態(tài)集合 */ private static final MapOrderStatus, SetOrderStatus TRANSITIONS new EnumMap(OrderStatus.class); static { TRANSITIONS.put(OrderStatus.PENDING, EnumSet.of(OrderStatus.PAID, OrderStatus.CANCELLED)); TRANSITIONS.put(OrderStatus.PAID, EnumSet.of(OrderStatus.CUSTOMIZING, OrderStatus.REFUNDED)); TRANSITIONS.put(OrderStatus.CUSTOMIZING, EnumSet.of(OrderStatus.UPCOMING, OrderStatus.REFUNDED)); TRANSITIONS.put(OrderStatus.UPCOMING, EnumSet.of(OrderStatus.COMPLETED, OrderStatus.REFUNDED)); TRANSITIONS.put(OrderStatus.COMPLETED, EnumSet.of()); TRANSITIONS.put(OrderStatus.CANCELLED, EnumSet.of()); TRANSITIONS.put(OrderStatus.REFUNDED, EnumSet.of()); }實(shí)際金額計(jì)算里坑最多的是團(tuán)體單的人均價(jià)格乘以人數(shù)這個(gè)看似簡(jiǎn)單的邏輯。我遇到的情況是路線方案調(diào)整了比如把三星酒店升級(jí)成四星服務(wù)商重新報(bào)價(jià)后已經(jīng)繳費(fèi)的成員應(yīng)該補(bǔ)差價(jià)還沒(méi)繳費(fèi)的成員直接按新價(jià)格繳。這個(gè)在表結(jié)構(gòu)上不能只改訂單總價(jià)需要一個(gè)報(bào)價(jià)變更記錄表quote_change_log把每次改價(jià)前后的價(jià)格、影響成員、變更原因都記下來(lái)否則結(jié)算對(duì)賬時(shí)根本說(shuō)不清。4. 數(shù)據(jù)庫(kù)設(shè)計(jì)畢業(yè)季場(chǎng)景下的核心表結(jié)構(gòu)與索引選擇數(shù)據(jù)庫(kù)設(shè)計(jì)這個(gè)環(huán)節(jié)可以說(shuō)直接決定了項(xiàng)目后期是越寫(xiě)越順還是越寫(xiě)越崩。我的經(jīng)驗(yàn)是先想清楚業(yè)務(wù)中最核心的實(shí)體是哪些再把實(shí)體之間的關(guān)聯(lián)關(guān)系理順最后才去畫(huà)表、定字段。4.1 九張核心表的組織邏輯整個(gè)平臺(tái)我最終沉淀出九張核心業(yè)務(wù)表它們之間的關(guān)系如下用戶表user包含用戶ID、昵稱、手機(jī)號(hào)、密碼、頭像、角色標(biāo)識(shí)角色區(qū)分為普通用戶、服務(wù)商、管理員用整數(shù)字段存枚舉值。密碼存儲(chǔ)用BCrypt加密絕對(duì)不允許明文。路線表route路線名稱、封面圖片、主題標(biāo)簽、出發(fā)城市、目的地、天數(shù)、人均價(jià)格、庫(kù)存名額、路線描述、狀態(tài)上架/下架。需求表travel_demand用戶ID、出行天數(shù)、預(yù)算、主題偏好、出發(fā)城市、成團(tuán)人數(shù)、特殊要求、狀態(tài)。訂單表order訂單號(hào)唯一業(yè)務(wù)編號(hào)、用戶ID、團(tuán)體ID可空、路線ID、訂單金額、支付狀態(tài)、訂單狀態(tài)、創(chuàng)建時(shí)間、支付時(shí)間。旅行團(tuán)表travel_group團(tuán)長(zhǎng)ID、團(tuán)名稱、成團(tuán)人數(shù)上限、當(dāng)前人數(shù)、出發(fā)日期、狀態(tài)、備注。成員表group_member團(tuán)體ID、用戶ID、成員角色、參與狀態(tài)、繳費(fèi)金額、繳費(fèi)時(shí)間、退出時(shí)間。評(píng)價(jià)表review訂單ID、用戶ID、評(píng)分、內(nèi)容、出行后審核標(biāo)記。報(bào)價(jià)變更表quote_change_log訂單ID、舊金額、新金額、變更原因、操作人ID、變更時(shí)間。公告表notice標(biāo)題、內(nèi)容、類型、發(fā)布狀態(tài)、發(fā)布時(shí)間。這套設(shè)計(jì)的核心思想是路線與訂單分離、訂單與團(tuán)體松耦合關(guān)聯(lián)。路線是靜態(tài)資源可以被多個(gè)訂單引用訂單記錄的是交易行為團(tuán)體是人與組織的關(guān)系載體與訂單通過(guò)團(tuán)體ID關(guān)聯(lián)但不在訂單表里冗余太多團(tuán)體細(xì)節(jié)。4.2 容易被忽視的索引優(yōu)化數(shù)據(jù)量小的時(shí)候索引可有可無(wú)但答辯老師一定會(huì)問(wèn)這個(gè)表字段建索引了嗎你的查詢會(huì)不會(huì)全表掃描。我在實(shí)踐中加了這些索引邏輯也說(shuō)得通訂單表的user_id, status聯(lián)合索引支撐我的訂單頁(yè)面按用戶和狀態(tài)篩選。訂單表的group_id, status支撐某團(tuán)體的訂單查詢。路線表的status, theme支撐首頁(yè)按主題篩選上架路線。需求表的status支撐后臺(tái)需求池的待匹配查詢。另外要注意電話號(hào)碼字段如果用varchar存建議單獨(dú)建普通索引。手機(jī)上號(hào)頻繁用于登錄查詢每次全表掃描在演示環(huán)境不覺(jué)得慢但如果老師現(xiàn)場(chǎng)導(dǎo)入了上萬(wàn)條模擬數(shù)據(jù)查詢響應(yīng)延遲會(huì)非常明顯。4.3 一對(duì)多關(guān)系下的批量查詢優(yōu)化一個(gè)常見(jiàn)的性能問(wèn)題是查詢訂單列表時(shí)需要同時(shí)顯示每個(gè)訂單關(guān)聯(lián)的路線名稱和用戶昵稱。很多人的寫(xiě)法是查完訂單列表后循環(huán)再查路線和用戶這樣一次頁(yè)面請(qǐng)求輕松發(fā)出幾十條SQL這在答辯現(xiàn)場(chǎng)如果數(shù)據(jù)量一大就會(huì)卡頓。我用MyBatis的collection標(biāo)簽做了一次性關(guān)聯(lián)查詢r(jià)esultMap idOrderWithDetailMap typeOrderVo id propertyid columnorder_id/ result propertyorderNo columnorder_no/ collection propertyitems ofTypeOrderItemVo id propertyitemId columnitem_id/ result propertyrouteName columnroute_name/ result propertyprice columnprice/ /collection /resultMap select idselectOrderWithDetail resultMapOrderWithDetailMap SELECT o.id AS order_id, o.order_no, oi.id AS item_id, r.route_name, oi.price FROM order o LEFT JOIN order_item oi ON o.id oi.order_id LEFT JOIN route r ON oi.route_id r.id WHERE o.user_id #{userId} ORDER BY o.create_time DESC /select這條SQL執(zhí)行完內(nèi)存里就能拼出完整的訂單-明細(xì)樹(shù)結(jié)構(gòu)避免N1查詢問(wèn)題。注意order是MySQL保留關(guān)鍵字建表時(shí)要加上反引號(hào)否則SQL直接報(bào)錯(cuò)這是我實(shí)際踩過(guò)的坑。5. 權(quán)限控制與安全細(xì)節(jié)答辯時(shí)的高頻問(wèn)點(diǎn)5.1 登錄態(tài)管理與自定義攔截器畢設(shè)級(jí)別的系統(tǒng)不需要做到Spring Security級(jí)別但基本的登錄態(tài)校驗(yàn)、角色權(quán)限隔離、接口防繞過(guò)是必須的。我用了Session加自定義攔截器的方式思路是登錄成功后把user對(duì)象放進(jìn)Session。定義一個(gè)權(quán)限攔截器注入Spring容器注冊(cè)到WebMvcConfigurer的addInterceptors方法中。配置URL規(guī)則攔截什么路徑放過(guò)什么路徑。例如/admin/**必須管理員角色/user/**必須登錄用戶/route/list和首頁(yè)瀏覽可以放行。這里有個(gè)重要的坑靜態(tài)資源要放行否則頁(yè)面樣式全掛。我見(jiàn)過(guò)不止一個(gè)人把攔截器配成/*全攔結(jié)果JS和CSS都被攔截了頁(yè)面打開(kāi)是裸HTML排查半天才發(fā)現(xiàn)是攔截器把靜態(tài)資源攔了。建議放行規(guī)則寫(xiě)成registry.addInterceptor(authInterceptor) .addPathPatterns(/**) .excludePathPatterns( /, /route/list, /route/detail/**, /user/login, /user/register, /css/**, /js/**, /images/**, /error );自定義注解加攔截器校驗(yàn)權(quán)限的做法——定義一個(gè)RequireRole注解標(biāo)注在Controller方法上攔截器里讀取注解并校驗(yàn)當(dāng)前用戶角色。思路不復(fù)雜但答辯時(shí)你可以說(shuō)我通過(guò)注解實(shí)現(xiàn)了聲明式權(quán)限控制這比我每個(gè)方法開(kāi)頭都判斷一下角色要有說(shuō)服力得多。5.2 密碼處理與敏感信息防護(hù)密碼存儲(chǔ)用了BCrypt加密Spring Security的crypto包里有現(xiàn)成的BCryptPasswordEncoder不需要把整個(gè)Spring Security引進(jìn)來(lái)。注冊(cè)時(shí)加密存儲(chǔ)登錄時(shí)用matches方法校驗(yàn)。這里要提醒Session里只放用戶ID、昵稱、頭像這些必要信息絕對(duì)不要把密碼放進(jìn)Session即使加密過(guò)也別放。另一個(gè)安全細(xì)節(jié)是手機(jī)號(hào)脫敏。展示用戶信息列表時(shí)對(duì)手機(jī)號(hào)中間四位打碼138****1234需要在VO層做處理而不是改數(shù)據(jù)庫(kù)數(shù)據(jù)。我專門(mén)寫(xiě)了一個(gè)工具方法處理這個(gè)既滿足了頁(yè)面展示需求又不破壞原始數(shù)據(jù)。文件上傳這個(gè)環(huán)節(jié)也要注意安全。頭像上傳和路線圖片上傳都涉及文件類型校驗(yàn)千萬(wàn)不要只信任前端傳來(lái)的后綴名。我用Content-Type加文件頭校驗(yàn)雙重檢查并限制文件大小上傳目錄放到了項(xiàng)目外部路徑而不是項(xiàng)目classpath里。這樣一個(gè)是防止上傳路徑被覆蓋另一個(gè)是把上傳文件與運(yùn)行代碼物理隔離部署時(shí)也更靈活。6. 訂單支付與退款邏輯沒(méi)有真支付環(huán)境怎么辦畢業(yè)設(shè)計(jì)要展示一個(gè)完整電商閉環(huán)支付環(huán)節(jié)繞不開(kāi)但你又不能在答辯現(xiàn)場(chǎng)真的用商用支付。我的處理方案是模擬支付通道。6.1 模擬支付的三種可行方案第一個(gè)方案是直接用數(shù)據(jù)庫(kù)事務(wù)模擬——點(diǎn)擊立即支付時(shí)前端彈窗展示模擬收銀臺(tái)確認(rèn)后前端請(qǐng)求后端接口后端開(kāi)啟事務(wù)執(zhí)行余額扣減訂單狀態(tài)變更資金流水記錄然后提交事務(wù)。這個(gè)方案代碼量少事務(wù)一致性校驗(yàn)也能展示出來(lái)。第二個(gè)方案是接入PayPal沙箱或者支付寶沙箱環(huán)境。沙箱環(huán)境是真實(shí)支付網(wǎng)關(guān)的測(cè)試環(huán)境可以展示完整的跳轉(zhuǎn)、回調(diào)和驗(yàn)簽流程。如果導(dǎo)師更看重商業(yè)完整性這個(gè)方案更硬核。但缺點(diǎn)是配置流程復(fù)雜而且沙箱環(huán)境有時(shí)不穩(wěn)定答辯現(xiàn)場(chǎng)如果網(wǎng)絡(luò)出問(wèn)題就尷尬了。第三個(gè)方案是混合方案——系統(tǒng)里做一個(gè)支付渠道標(biāo)識(shí)字段正常走模擬支付預(yù)留真實(shí)支付接口擴(kuò)展位。我最終選了這個(gè)方案既展示了接口設(shè)計(jì)的可擴(kuò)展性又不會(huì)在演示時(shí)翻車。6.2 退款邏輯與資金流水退款邏輯里最容易漏掉的是部分退款。團(tuán)體訂單里如果兩個(gè)人退出服務(wù)商同意退款那么退款金額不是訂單總額而是這兩個(gè)人各自已繳納的金額。因此資金流水表fund_flow必須記錄退款是針對(duì)order的哪個(gè)明細(xì)、退給了哪個(gè)用戶、金額多少、剩余待退金額是多少。我的實(shí)現(xiàn)要點(diǎn)訂單資金操作全部通過(guò)一個(gè)資金服務(wù)類處理每個(gè)操作同步生成一條fund_flow流水。這樣可以保證無(wú)論什么時(shí)候?qū)~流水表里的資金進(jìn)出總和等于訂單金額差不會(huì)出現(xiàn)錢(qián)對(duì)不上賬的問(wèn)題。這筆賬如果不對(duì)齊答辯現(xiàn)場(chǎng)老師問(wèn)一句退款后總金額怎么驗(yàn)證你就容易卡殼。7. 從Demo到可演示系統(tǒng)部署與效果優(yōu)化的實(shí)戰(zhàn)經(jīng)驗(yàn)代碼寫(xiě)完只是第一步能讓它在別人電腦上穩(wěn)定跑起來(lái)才是關(guān)鍵。7.1 打包部署的踩坑記錄Spring Boot的打包默認(rèn)是jar包內(nèi)置Tomcat。但我在打包時(shí)遇到過(guò)三個(gè)問(wèn)題第一個(gè)是打包后靜態(tài)資源404。原因是Thymeleaf模板打包進(jìn)了BOOT-INF/classes目錄而靜態(tài)資源的路徑匹配規(guī)則打在classpath下沒(méi)問(wèn)題但如果用了src/main/webapp目錄下的資源打jar包時(shí)不會(huì)自動(dòng)帶進(jìn)去。正確做法是把靜態(tài)資源放在src/main/resources/static下。第二個(gè)是application.properties里的連接串問(wèn)題。本地跑的時(shí)候數(shù)據(jù)庫(kù)地址是localhost到了演示環(huán)境可能數(shù)據(jù)庫(kù)在另一臺(tái)機(jī)器密碼也不同。我的做法是使用profile配置分別維護(hù)application-dev.properties和application-prod.properties啟動(dòng)時(shí)用--spring.profiles.activeprod指定環(huán)境避免現(xiàn)場(chǎng)改配置文件。第三個(gè)是端口占用。我遇到過(guò)打包后啟動(dòng)直接報(bào)端口被占用最后發(fā)現(xiàn)是本地跑了兩個(gè)實(shí)例。用server.port8081換端口解決同時(shí)順手配置了server.servlet.context-path/travel給項(xiàng)目加了統(tǒng)一前綴這樣后續(xù)部署到nginx做反向代理也更規(guī)范。7.2 演示數(shù)據(jù)的準(zhǔn)備策略答辯時(shí)系統(tǒng)里空蕩蕩的大列表非常減分。我提前準(zhǔn)備了兩套演示數(shù)據(jù)一套是路線數(shù)據(jù)每個(gè)主題類別放3到5條路線配上合適的圖片圖片記得用本地文件不要依賴外部圖床現(xiàn)場(chǎng)沒(méi)網(wǎng)就全掛了另一套是訂單數(shù)據(jù)構(gòu)造出已付款、定制中、已完成、已取消狀態(tài)齊全的列表方便現(xiàn)場(chǎng)演示不同狀態(tài)下的操作流程。這里有個(gè)經(jīng)驗(yàn)演示數(shù)據(jù)的時(shí)間區(qū)間要合理比如當(dāng)前日期是6月訂單的出行日期安排在6月底到7月初才算自然如果出行日期顯示在去年老師一眼就看出是假數(shù)據(jù)。而且最好準(zhǔn)備一個(gè)模擬團(tuán)體團(tuán)長(zhǎng)賬號(hào)登錄后能看到團(tuán)里的成員名單有人已繳費(fèi)有人未繳費(fèi)這樣展示催繳功能時(shí)有真實(shí)感比現(xiàn)場(chǎng)新創(chuàng)建一個(gè)空白團(tuán)體更有說(shuō)服力。7.3 列表分頁(yè)與查詢性能管理端的訂單列表、路線列表都做了分頁(yè)用的MyBatis-Plus的分頁(yè)插件。分頁(yè)這件事看似簡(jiǎn)單但有個(gè)隱藏細(xì)節(jié)前端傳頁(yè)碼時(shí)頁(yè)碼從1開(kāi)始而后臺(tái)分頁(yè)插件內(nèi)部計(jì)算offset是page-1如果前后端約定的邊界不一致會(huì)出現(xiàn)第一頁(yè)數(shù)據(jù)空白的情況。我在自定義分頁(yè)對(duì)象里統(tǒng)一處理了這個(gè)偏移邏輯并且前端頁(yè)面確認(rèn)從1開(kāi)始傳參。首頁(yè)的路線篩選用了多條件動(dòng)態(tài)SQLMyBatis的if標(biāo)簽在where條件后拼接注意每個(gè)條件都要帶上and前綴且第一個(gè)條件不能有多余and。這里有個(gè)規(guī)范寫(xiě)法where標(biāo)簽配合trim prefixWHERE prefixOverridesAND|OR可以自動(dòng)處理多余and問(wèn)題避免SQL語(yǔ)法錯(cuò)誤。8. 關(guān)于這個(gè)項(xiàng)目我想最后補(bǔ)充的幾個(gè)認(rèn)知做完整個(gè)項(xiàng)目我最想分享的其實(shí)不是某個(gè)技術(shù)點(diǎn)而是幾個(gè)底層認(rèn)知。第一個(gè)認(rèn)知是畢業(yè)設(shè)計(jì)項(xiàng)目的評(píng)分下限由功能完整性決定上限由你對(duì)業(yè)務(wù)邏輯的解釋能力決定。功能齊全、頁(yè)面能跑、流程順暢這是能過(guò)的基礎(chǔ)但如果你想拿優(yōu)秀必須能在答辯時(shí)把一個(gè)業(yè)務(wù)決策的前因后果講清楚——為什么訂單狀態(tài)要設(shè)計(jì)成這幾個(gè)而不是兩個(gè)為什么團(tuán)體和個(gè)人要分表為什么要設(shè)計(jì)報(bào)價(jià)變更記錄表這些問(wèn)題的答案就是你這篇論文或項(xiàng)目的靈魂。第二個(gè)認(rèn)知是做項(xiàng)目時(shí)想清楚再動(dòng)手比邊做邊想省的時(shí)間多得多。我前期在表結(jié)構(gòu)設(shè)計(jì)上花了大約一半的開(kāi)發(fā)時(shí)間后面真正寫(xiě)代碼反而很快因?yàn)樽侄侮P(guān)系理清了ServiceImpl里的每個(gè)方法基本就是按業(yè)務(wù)流程一條龍寫(xiě)下來(lái)。如果你發(fā)現(xiàn)自己寫(xiě)著寫(xiě)著頻繁回去改表加字段停下來(lái)想一想很可能是前面業(yè)務(wù)建模就沒(méi)立住。第三個(gè)認(rèn)知是從一次演示中得來(lái)的。當(dāng)時(shí)我給老師演示團(tuán)體費(fèi)用分?jǐn)偣δ芮『冒岩粋€(gè)繳費(fèi)狀態(tài)演示得很清楚老師順著問(wèn)了句如果一個(gè)人支付成功但系統(tǒng)突然斷電你怎么保證不會(huì)重復(fù)扣款。這個(gè)問(wèn)題提醒我支付相關(guān)的核心操作必須用事務(wù)加冪等鍵保護(hù)。我在模擬支付的接收接口里做了一個(gè)請(qǐng)求冪等鍵的表單字段后端根據(jù)訂單號(hào)加操作類型生成唯一冪等記錄重復(fù)提交直接拒絕。這種細(xì)節(jié)平時(shí)不起眼但它是整個(gè)系統(tǒng)可信度的支撐。最后一個(gè)建議是不要只把項(xiàng)目當(dāng)成作業(yè)把每個(gè)模塊的設(shè)計(jì)決策記錄下來(lái)哪怕只是簡(jiǎn)單的文檔。這會(huì)幫你在答辯時(shí)快速回憶起當(dāng)初為什么這么做也會(huì)讓整個(gè)項(xiàng)目顯得有思考、有沉淀。我當(dāng)初把開(kāi)發(fā)日志寫(xiě)在項(xiàng)目根目錄的README里包括每個(gè)階段的改動(dòng)原因最后寫(xiě)設(shè)計(jì)文檔的時(shí)候發(fā)現(xiàn)最值錢(qián)的素材早就在那里等著了。