這段時(shí)間來(lái)問(wèn)畢業(yè)設(shè)計(jì)選題的人特別多一年里總有好幾波。要問(wèn)哪個(gè)方向最不容易翻車我會(huì)把基于SpringBoot Vue的旅游網(wǎng)系統(tǒng)排在很靠前的位置。技術(shù)棧主流、前后端分離結(jié)構(gòu)清晰、業(yè)務(wù)場(chǎng)景貼近真實(shí)產(chǎn)品無(wú)論用來(lái)應(yīng)付開(kāi)題報(bào)告、中期檢查、畢業(yè)答辯還是之后放進(jìn)求職作品集里這套系統(tǒng)都有足夠的底氣撐住場(chǎng)面。本文就以這套旅游網(wǎng)系統(tǒng)為主線把從選題邏輯、技術(shù)選型、數(shù)據(jù)庫(kù)設(shè)計(jì)、核心實(shí)現(xiàn)到踩坑排查的完整過(guò)程一次講透你可以把這份內(nèi)容當(dāng)成項(xiàng)目復(fù)盤也可以當(dāng)成一份帶避坑指路的實(shí)操筆記。技術(shù)細(xì)節(jié)我都盡量寫出為什么這樣做免得你只抄到表面答辯時(shí)一追問(wèn)就露餡。1. 為什么旅游網(wǎng)系統(tǒng)是畢業(yè)設(shè)計(jì)里的萬(wàn)金油選題1.1 一套系統(tǒng)把主流技術(shù)點(diǎn)全部串起來(lái)旅游網(wǎng)系統(tǒng)對(duì)學(xué)生最友好的一點(diǎn)是它的功能邊界特別清晰但又不會(huì)單薄。用戶端有注冊(cè)登錄、景點(diǎn)展示、線路推薦、酒店預(yù)訂、訂單管理、個(gè)人收藏這些常規(guī)功能管理端有內(nèi)容維護(hù)、訂單處理、用戶管理和數(shù)據(jù)概覽。這些功能覆蓋了Web開(kāi)發(fā)里幾乎所有高頻考點(diǎn)前后端交互、數(shù)據(jù)庫(kù)表設(shè)計(jì)、權(quán)限控制、事務(wù)處理、狀態(tài)管理、文件上傳稍微深入一點(diǎn)還能帶上緩存、定時(shí)任務(wù)和權(quán)限框架?，F(xiàn)在高校的畢業(yè)設(shè)計(jì)指導(dǎo)老師普遍不看新奇炫更看重項(xiàng)目完整度和技術(shù)深度。你用一個(gè)旅游網(wǎng)站把SpringBoot、Vue、MySQL這些主流技術(shù)全部落進(jìn)真實(shí)業(yè)務(wù)里比做一個(gè)花哨但邏輯破碎的演示Demo可靠得多。很多同學(xué)選題時(shí)喜歡追新詞比如大數(shù)據(jù)、區(qū)塊鏈、人工智能但扎進(jìn)去發(fā)現(xiàn)光是數(shù)據(jù)來(lái)源和環(huán)境配置就能花掉一大半時(shí)間。旅游網(wǎng)這類系統(tǒng)數(shù)據(jù)模型規(guī)整業(yè)務(wù)邏輯不繞技術(shù)點(diǎn)卻一樣都不少非常適合在有限的項(xiàng)目周期里做出一個(gè)講得清、跑得動(dòng)、說(shuō)得通的完整作品。1.2 業(yè)務(wù)場(chǎng)景貼近真實(shí)產(chǎn)品答辯時(shí)有話可說(shuō)答辯環(huán)節(jié)最怕的不是代碼寫不好而是老師一句你這個(gè)項(xiàng)目解決什么實(shí)際問(wèn)題把你問(wèn)懵。旅游網(wǎng)天然自帶答案用戶可以快速瀏覽景點(diǎn)信息、預(yù)訂旅游線路、完成在線住宿下單管理員可以在后臺(tái)維護(hù)內(nèi)容、跟進(jìn)訂單。這套流程本身就是實(shí)際業(yè)務(wù)的數(shù)字化映射你不需要憑空編造價(jià)值。再往深一層說(shuō)旅游系統(tǒng)的訂單、庫(kù)存、價(jià)格、狀態(tài)流轉(zhuǎn)這些概念是從電商系統(tǒng)脫胎出來(lái)的簡(jiǎn)化版。你在旅游網(wǎng)上設(shè)計(jì)的訂單邏輯、支付狀態(tài)機(jī)、庫(kù)存扣減方案將來(lái)做商城、做外賣平臺(tái)、做任何交易類系統(tǒng)都能遷移復(fù)用。這也是為什么很多求職面試官看到這類項(xiàng)目簡(jiǎn)歷時(shí)不會(huì)反感——他們一眼就能判斷出這個(gè)人有沒(méi)有真正理解交易系統(tǒng)的運(yùn)轉(zhuǎn)邏輯而不只是會(huì)調(diào)接口。1.3 功能邊界可控工作量合適一個(gè)完整畢業(yè)設(shè)計(jì)的工期拋開(kāi)畢業(yè)論文不算純代碼開(kāi)發(fā)通?？刂圃谌轿逯鼙容^合理。旅游網(wǎng)系統(tǒng)正好落在舒適區(qū)里核心模塊四個(gè)到五個(gè)每個(gè)模塊的CRUD都有清晰邊界。不像大型電商系統(tǒng)那樣要對(duì)接支付渠道、處理高并發(fā)、設(shè)計(jì)復(fù)雜的促銷規(guī)則也不用像數(shù)據(jù)中臺(tái)項(xiàng)目那樣考慮離線和實(shí)時(shí)兩條鏈路。更重要的是旅游系統(tǒng)的功能可以進(jìn)行梯度化擴(kuò)展。基礎(chǔ)版做景點(diǎn)和線路的展示加一個(gè)簡(jiǎn)單的預(yù)訂流程進(jìn)階版可以加入酒店模塊、收藏評(píng)論模塊高階版還能加分布式會(huì)話、緩存熱點(diǎn)數(shù)據(jù)、使用消息隊(duì)列處理訂單超時(shí)。這表示你的項(xiàng)目天花板足夠高完全可以根據(jù)自己時(shí)間安排和技術(shù)水平來(lái)調(diào)配深度這是很多畢業(yè)設(shè)計(jì)選題做不到的靈活性。2. 技術(shù)選型SpringBoot Vue的組合邏輯2.1 后端為什么首選SpringBootSpringBoot到今天已經(jīng)是Java后端開(kāi)發(fā)的默認(rèn)起點(diǎn)幾乎找不到不用它的理由。它最大的貢獻(xiàn)是消滅了Spring早期繁瑣的XML配置。你要整合數(shù)據(jù)庫(kù)、做接口、接權(quán)限框架SpringBoot用一套自動(dòng)配置機(jī)制全部約定好了開(kāi)發(fā)者只要把依賴加進(jìn)Maven在配置文件里寫好參數(shù)跑起來(lái)就是一套可用的服務(wù)。我用SpringBoot做過(guò)好幾次腳手架搭建實(shí)測(cè)最舒服的是以下幾點(diǎn)第一內(nèi)嵌Tomcat打包成JAR直接執(zhí)行不用單獨(dú)裝容器第二spring-boot-starter-web、spring-boot-starter-data-redis這類起步依賴能把常用組件一鍵引進(jìn)第三配合spring-boot-starter-validation可以非常方便地做參數(shù)校驗(yàn)第四項(xiàng)目結(jié)構(gòu)約定成熟分包規(guī)范一看就懂。對(duì)于畢業(yè)設(shè)計(jì)來(lái)說(shuō)選SpringBoot還意味著遇到問(wèn)題時(shí)社區(qū)解決方案最多隨便搜一個(gè)報(bào)錯(cuò)基本都能找到可復(fù)現(xiàn)的解決路徑這比選冷門框架能省下大量時(shí)間。2.2 前端為什么選VueVue在前端框架里屬于那種順手但不搶戲的選擇。它沒(méi)有太多強(qiáng)制性的工程約束模板語(yǔ)法溫和響應(yīng)式機(jī)制自動(dòng)處理視圖更新配合生態(tài)里的Vue Router做頁(yè)面路由、Pinia管理共享狀態(tài)很快就能搭出一個(gè)像模像樣的單頁(yè)應(yīng)用。尤其適合畢業(yè)設(shè)計(jì)的一點(diǎn)是Vue理順了前后端分離的開(kāi)發(fā)模式后端只提供JSON接口前端負(fù)責(zé)渲染和數(shù)據(jù)交互。調(diào)試時(shí)后端用Postman測(cè)接口前端直接調(diào)后端地址兩邊可以并行開(kāi)工。相比傳統(tǒng)的模板渲染模式Vue讓整個(gè)項(xiàng)目的代碼組織更清晰分工也更明確這對(duì)寫畢業(yè)論文里的系統(tǒng)實(shí)現(xiàn)章節(jié)很有幫助你可以理直氣壯地把架構(gòu)圖拆成前端展示層、后端服務(wù)層和數(shù)據(jù)層來(lái)分析。2.3 版本搭配與基礎(chǔ)工具版本選擇上我沒(méi)有追最新選的是穩(wěn)定且資料多的組合。后端SpringBoot用2.7.x對(duì)應(yīng)Java 8或Java 11注意Java 8雖然年頭久但恰恰是兼容性最好的版本很多本地環(huán)境都默認(rèn)指向它。數(shù)據(jù)庫(kù)用MySQL 8.0ORM用MyBatis-Plus查詢構(gòu)造器確實(shí)能省很多重復(fù)SQL。前端Vue用3.x組件庫(kù)選Element Plus年末時(shí)很多教程都更新到了這套組合遇到問(wèn)題容易查到答案。開(kāi)發(fā)工具方面后端用IDEA前端VSCode數(shù)據(jù)庫(kù)用Navicat或DBeaver接口調(diào)試用Postman版本管理用Git。這些工具不需要你在開(kāi)題報(bào)告里全部點(diǎn)一遍但實(shí)際開(kāi)發(fā)時(shí)缺一不可。如果你是在校學(xué)生建議買一個(gè)云服務(wù)器用于后期部署展示不會(huì)很貴但對(duì)答辯演示和簡(jiǎn)歷上上線部署四個(gè)字的含金量提升非常明顯。3. 功能模塊拆解與數(shù)據(jù)庫(kù)設(shè)計(jì)3.1 用戶端功能用戶端是游客和注冊(cè)用戶直接接觸的部分在設(shè)計(jì)上要盡量貼近常見(jiàn)的旅游類產(chǎn)品交互不能做成純粹的數(shù)據(jù)表格展示。我把用戶端功能拆分成了六個(gè)核心模塊用戶注冊(cè)與登錄支持用戶名密碼注冊(cè)密碼使用加密存儲(chǔ)登錄后簽發(fā)token。首頁(yè)內(nèi)容聚合輪播圖、熱門景點(diǎn)推薦、精品線路推薦按瀏覽量或權(quán)重排序。景點(diǎn)模塊景點(diǎn)列表篩選、關(guān)鍵詞搜索、景點(diǎn)詳情和圖片集展示。線路模塊多日游線路展示、線路詳情查看、線路預(yù)訂入口。酒店模塊按城市和價(jià)格篩選酒店查看房型與設(shè)施支持在線預(yù)訂。個(gè)人中心個(gè)人信息修改、我的訂單、我的收藏、我的評(píng)論。這六個(gè)模塊的功能深度不用完全一致一般把景點(diǎn)和線路做成重點(diǎn)模塊搜索、排序、分頁(yè)、詳情頁(yè)都要做扎實(shí)酒店模塊可以簡(jiǎn)化成列表加詳情個(gè)人中心則重點(diǎn)把訂單狀態(tài)流轉(zhuǎn)做清楚。這種有主有次的粒度也是答辯時(shí)的加分項(xiàng)體現(xiàn)的是需求分析和資源分配能力。3.2 管理端功能管理端面向運(yùn)營(yíng)人員也就是管理員。它的功能設(shè)計(jì)要站在內(nèi)容可維護(hù)、訂單可跟蹤、數(shù)據(jù)可感知這個(gè)角度來(lái)思考。如果只給學(xué)生端做一個(gè)后臺(tái)管理頁(yè)面代碼量確實(shí)能少很多但論文篇幅和答辯說(shuō)服力都會(huì)明顯縮水。我將管理端分成以下模塊登錄與權(quán)限管理員單獨(dú)表登錄后走獨(dú)立token或直接使用同套用戶體系加角色字段。數(shù)據(jù)看板統(tǒng)計(jì)用戶總數(shù)、景點(diǎn)數(shù)量、訂單總數(shù)展示最近一周訂單趨勢(shì)。景點(diǎn)管理景點(diǎn)信息的增刪改查、上下架狀態(tài)設(shè)置、圖片上傳。線路管理線路內(nèi)容的維護(hù)包含行程安排、天數(shù)、價(jià)格、庫(kù)存數(shù)。酒店管理酒店的增刪改查支持按城市歸類。訂單管理訂單列表、狀態(tài)篩選、訂單詳情、發(fā)貨/取消操作。用戶管理啟用禁用賬號(hào)、重置密碼。對(duì)于管理端我的建議是優(yōu)先保證核心CRUD齊全、操作閉環(huán)順暢。你在論文里可以這樣描述管理端的價(jià)值通過(guò)后臺(tái)實(shí)現(xiàn)對(duì)核心業(yè)務(wù)數(shù)據(jù)的統(tǒng)一管理提升內(nèi)容發(fā)布和訂單處理效率這也是最標(biāo)準(zhǔn)的答辯話術(shù)。3.3 核心表結(jié)構(gòu)設(shè)計(jì)數(shù)據(jù)庫(kù)設(shè)計(jì)是這類項(xiàng)目中老師最愛(ài)深挖的部分。表結(jié)構(gòu)設(shè)計(jì)得好業(yè)務(wù)流程自然順設(shè)計(jì)得亂后續(xù)每個(gè)功能都寫不順心。我把旅游網(wǎng)系統(tǒng)的關(guān)鍵表列出來(lái)并說(shuō)明各表的設(shè)計(jì)意圖表名核心字段設(shè)計(jì)意圖usersid, username, password, nickname, phone, avatar, status用戶基礎(chǔ)信息status控制賬號(hào)啟停adminsid, username, password, role管理員獨(dú)立表職責(zé)分離scenic_spotsid, name, summary, address, cover_image, price, open_time, status景點(diǎn)表圖片路徑存相對(duì)地址travel_routesid, name, days, itinerary, price, stock, status線路表庫(kù)存字段支撐預(yù)訂庫(kù)存扣減hotelsid, name, city, address, price, star, facilities酒店表facilities用逗號(hào)分隔或JSON存儲(chǔ)ordersid, order_no, user_id, total_price, status, pay_time, create_time訂單主表狀態(tài)用數(shù)字字典order_itemsid, order_id, goods_type, goods_id, goods_name, price, quantity訂單明細(xì)表快照關(guān)鍵信息favoritesid, user_id, scenic_id, create_time用戶收藏表commentsid, user_id, scenic_id, content, rating, create_time景點(diǎn)評(píng)論關(guān)聯(lián)用戶和景點(diǎn)在旅游網(wǎng)的項(xiàng)目里我特別建議把訂單主表和訂單明細(xì)表分開(kāi)。很多人做畢業(yè)設(shè)計(jì)圖省事直接在訂單表里放一個(gè)goods_name加price結(jié)果一個(gè)訂單買多條線路的時(shí)候就非常尷尬。比如用戶一次下單預(yù)訂了兩條線路一條是三日游套餐一條是當(dāng)?shù)鼐频陜赏砣绻唵伪砝镏挥幸粋€(gè)商品字段這條訂單的數(shù)據(jù)根本無(wú)法完整表達(dá)。拆成訂單明細(xì)表后一個(gè)訂單可以對(duì)應(yīng)多條明細(xì)既符合真實(shí)業(yè)務(wù)模型也方便后續(xù)擴(kuò)展多類商品混合下單。3.4 表關(guān)系與關(guān)鍵字段補(bǔ)充核心表之間的關(guān)系并不復(fù)雜我用文字直接描述用戶表與訂單表是一對(duì)多訂單表與訂單明細(xì)表是一對(duì)多用戶表與收藏表、評(píng)論表都是一對(duì)多景點(diǎn)與評(píng)論是一對(duì)多。這些關(guān)系映射到MyBatis-Plus里不需要設(shè)計(jì)復(fù)雜的XML映射用簡(jiǎn)單的關(guān)聯(lián)查詢或者業(yè)務(wù)層組裝就能完成。幾個(gè)關(guān)鍵字段的設(shè)計(jì)細(xì)節(jié)值得單獨(dú)說(shuō)。第一個(gè)是order_no訂單編號(hào)我建議不要用數(shù)據(jù)庫(kù)自增ID直接展示給用戶而是用時(shí)間戳 隨機(jī)數(shù)或者日期 用戶ID后綴的方式生成。比如20250612103015 用戶ID 4位隨機(jī)數(shù)這樣訂單號(hào)有業(yè)務(wù)含義也方便排查問(wèn)題。第二個(gè)是狀態(tài)字段統(tǒng)一用Integer類型加字典注釋0待支付、1已支付、2已取消、3已完成、4退款中。答辯時(shí)如果被問(wèn)為什么不用字符串你可以答數(shù)字類型存儲(chǔ)占用小索引效率更高程序里用常量或枚舉統(tǒng)一管理展示層再翻譯成文字。第三個(gè)是金額字段不建議使用double或float涉及財(cái)務(wù)數(shù)據(jù)一般用DECIMAL(10,2)避免二進(jìn)制浮點(diǎn)誤差。外鍵我建議不物理創(chuàng)建只保留邏輯關(guān)聯(lián)。原因很簡(jiǎn)單物理外鍵雖然能保證數(shù)據(jù)一致性但會(huì)拖慢插入和更新性能MyBatis-Plus的實(shí)體映射也不需要外鍵約束存在。在項(xiàng)目文檔里說(shuō)明外鍵由應(yīng)用層保證邏輯一致性是一種非常受認(rèn)可的做法。4. 核心實(shí)現(xiàn)細(xì)節(jié)與關(guān)鍵代碼4.1 后端工程結(jié)構(gòu)與認(rèn)證體系后端工程采用標(biāo)準(zhǔn)的SpringBoot分層結(jié)構(gòu)包名按業(yè)務(wù)邊界劃分com.travel ├── controller // 接口層 ├── service // 業(yè)務(wù)層 ├── mapper // 數(shù)據(jù)訪問(wèn)層 ├── entity // 實(shí)體類 ├── dto // 傳輸對(duì)象 ├── config // 配置類 ├── common // 通用返回、異常處理、常量 └── utils // 工具類認(rèn)證體系我采用的是無(wú)狀態(tài)JWT方案。用戶在登錄接口提交用戶名和密碼后端校驗(yàn)通過(guò)后生成一個(gè)帶過(guò)期時(shí)間的token字符串返回給前端。前端將其存在本地存儲(chǔ)中后續(xù)每個(gè)請(qǐng)求在Header里帶上Authorization: Bearer token。后端通過(guò)攔截器校驗(yàn)token解析出用戶信息并放入請(qǐng)求上下文。public class JwtUtil { private static final SecretKey KEY Keys.hmacShaKeyFor(travel-system-secret-key-please-change.getBytes()); public static String createToken(Long userId, String username) { return Jwts.builder() .setSubject(String.valueOf(userId)) .claim(username, username) .setExpiration(new Date(System.currentTimeMillis() 1000 * 60 * 60 * 24)) .signWith(KEY, SignatureAlgorithm.HS256) .compact(); } }為什么選JWT而不是傳統(tǒng)的Session一是前后端分離部署時(shí)后端接口要同時(shí)服務(wù)Web頁(yè)面和可能的移動(dòng)端無(wú)狀態(tài)token天然適合這種多端場(chǎng)景二是JWT的過(guò)期時(shí)間在服務(wù)端不用額外存儲(chǔ)減少內(nèi)存依賴三是畢業(yè)答辯提到無(wú)狀態(tài)會(huì)話設(shè)計(jì)本身就是體現(xiàn)技術(shù)深度的話題。當(dāng)然JWT不能用來(lái)存放敏感數(shù)據(jù)它只是身份憑證這點(diǎn)在論文里最好能寫一句。4.2 首頁(yè)數(shù)據(jù)聚合接口首頁(yè)功能不復(fù)雜但比較考驗(yàn)接口設(shè)計(jì)思維。一個(gè)常見(jiàn)錯(cuò)誤是把首頁(yè)拆成十幾個(gè)接口前端一次打開(kāi)頁(yè)面要并發(fā)請(qǐng)求五六次。更好的做法是基于聚合的思想用一個(gè)接口返回首頁(yè)所需的全部數(shù)據(jù)塊。比如設(shè)計(jì)一個(gè)/api/home/aggregation接口一次返回輪播圖列表、熱門景點(diǎn)列表、精品線路列表和推薦酒店列表。public class HomeAggregationVO { private ListScenicSpotVO hotScenicList; private ListTravelRouteVO recommendRouteList; private ListHotelVO recommendHotelList; private ListString bannerUrls; }接口實(shí)現(xiàn)時(shí)每個(gè)列表的查詢都可以獨(dú)立方法化。熱門景點(diǎn)可以按瀏覽量排序取前6條精品線路按權(quán)重排序取前4條酒店則按評(píng)分排序取前6條。這里有一個(gè)細(xì)節(jié)首頁(yè)數(shù)據(jù)是為游客準(zhǔn)備的性能敏感數(shù)據(jù)查詢頻率高但變化不大很適合加一層緩存。我推薦引入spring-boot-starter-data-redis把聚合結(jié)果緩存五到十分鐘可以有效降低數(shù)據(jù)庫(kù)壓力。不過(guò)緩存引入會(huì)帶來(lái)一致性問(wèn)題如果你不想在項(xiàng)目中增加復(fù)雜度也可以不加緩存單純用索引優(yōu)化查詢答辯一樣能站得住。4.3 訂單流程的實(shí)現(xiàn)要點(diǎn)訂單功能是整個(gè)項(xiàng)目的業(yè)務(wù)核心。無(wú)論前端頁(yè)面做得多么精美老師最關(guān)心的還是下單時(shí)數(shù)據(jù)怎么保證正確的。學(xué)生做訂單容易偷懶直接把金額和商品信息插入數(shù)據(jù)庫(kù)就算完成但真實(shí)業(yè)務(wù)需要考慮幾個(gè)關(guān)鍵點(diǎn)。第一是庫(kù)存控制。用戶下單時(shí)不僅要判斷庫(kù)存是否充足還要防止超賣。在單機(jī)場(chǎng)景下最簡(jiǎn)單有效的方案是在SQL更新語(yǔ)句里帶上庫(kù)存條件例如UPDATE travel_routes SET stock stock - 1 WHERE id ? AND stock 0只要更新影響行數(shù)為1說(shuō)明扣減成功為0說(shuō)明庫(kù)存不足。這種做法比先查詢?cè)俑乱煽恳?guī)避了并發(fā)條件下超賣問(wèn)題。第二是事務(wù)邊界。下單這個(gè)操作涉及插入訂單主表、插入訂單明細(xì)表、扣減庫(kù)存、如果有優(yōu)惠還要修改優(yōu)惠券狀態(tài)這些操作必須處于同一個(gè)事務(wù)中。SpringBoot里的做法是在Service方法上加Transactional(rollbackFor Exception.class)注意rollbackFor Exception.class一定要寫否則遇到運(yùn)行時(shí)異常之外的情況可能導(dǎo)致事務(wù)不生效。第三是重復(fù)提交控制。前端下單按鈕點(diǎn)擊一次后就應(yīng)該禁用并顯示處理中后端也可以做冪等處理。我的建議是在訂單創(chuàng)建接口里要求前端傳一個(gè)本次操作的流水號(hào)requestId后端用數(shù)據(jù)庫(kù)唯一索引約束防止用戶瘋狂點(diǎn)擊按鈕造成同一條訂單被創(chuàng)建多次。這套技巧講出來(lái)通常會(huì)讓答辯老師眼前一亮。4.4 前端工程與請(qǐng)求封裝前端項(xiàng)目用Vite創(chuàng)建Vue3工程后就引入Element Plus組件庫(kù)通常只需做必要配置即可開(kāi)始開(kāi)發(fā)。我建議在項(xiàng)目里做兩層統(tǒng)一封裝一層是HTTP請(qǐng)求封裝一層是接口方法封裝。Axios實(shí)例的創(chuàng)建可以這樣組織import axios from axios import { ElMessage } from element-plus const request axios.create({ baseURL: /api, timeout: 10000 }) request.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Bearer ${token} } return config }) request.interceptors.response.use( response { const res response.data if (res.code ! 200) { ElMessage.error(res.message || 請(qǐng)求失敗) return Promise.reject(new Error(res.message)) } return res.data }, error { ElMessage.error(error.message || 網(wǎng)絡(luò)異常) return Promise.reject(error) } )封裝請(qǐng)求層最直接的價(jià)值是所有調(diào)接口的地方都不需要重復(fù)寫token注入和錯(cuò)誤彈窗邏輯。你也可以統(tǒng)一在攔截器里處理401狀態(tài)碼比如判斷token失效后直接跳轉(zhuǎn)登錄頁(yè)。項(xiàng)目里所有的請(qǐng)求都通過(guò)request實(shí)例發(fā)出保持代碼的整潔度這種規(guī)范對(duì)論文的代碼質(zhì)量論證很有幫助。5. 實(shí)操過(guò)程從空工程到能跑通5.1 環(huán)境準(zhǔn)備清單動(dòng)手開(kāi)發(fā)之前先把環(huán)境統(tǒng)一好。我把這套項(xiàng)目多次使用的環(huán)境版本列成清單工具版本說(shuō)明JDK8或11兩者都兼容SpringBoot 2.7Maven3.6依賴管理MySQL8.0數(shù)據(jù)庫(kù)Node.js16前端環(huán)境IDEA任意近期版本后端開(kāi)發(fā)VSCode任意近期版本前端開(kāi)發(fā)環(huán)境安裝時(shí)最容易出錯(cuò)的是JDK和Maven的版本匹配問(wèn)題。如果你本機(jī)裝了多個(gè)Java版本記得在IDEA的項(xiàng)目結(jié)構(gòu)里顯式指定項(xiàng)目的JDK否則Maven編譯時(shí)經(jīng)常報(bào)錯(cuò)或者依賴解析混亂。另外MySQL安裝時(shí)字符集要選擇utf8mb4很多同學(xué)一開(kāi)始用默認(rèn)字符集插入中文時(shí)出現(xiàn)亂碼排查起來(lái)特別浪費(fèi)時(shí)間。5.2 后端搭建順序后端工程我推薦直接用IDEA的Spring Initializr生成不必手動(dòng)一個(gè)個(gè)建目錄。生成時(shí)需要選擇的依賴有Spring WebMySQL DriverMyBatis Framework后續(xù)可以替換為MyBatis-PlusLombokValidation生成完成后在pom.xml里額外引入MyBatis-Plus和JWT相關(guān)的依賴。數(shù)據(jù)庫(kù)連接配置放在application.yml中server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/travel_db?useUnicodetruecharacterEncodingutf8mb4useSSLfalseserverTimezoneAsia/Shanghai username: root password: your_password jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8 mybatis-plus: configuration: map-underscore-to-camel-case: true global-config: db-config: logic-delete-field: deleted數(shù)據(jù)庫(kù)連接串里的serverTimezone必須配置否則MySQL驅(qū)動(dòng)會(huì)因時(shí)區(qū)設(shè)置報(bào)錯(cuò)。map-underscore-to-camel-case: true讓數(shù)據(jù)庫(kù)字段create_time自動(dòng)映射為Java屬性createTime這是MyBatis-Plus的一個(gè)高頻便捷開(kāi)關(guān)。后端開(kāi)發(fā)順序建議是先從entity開(kāi)始再寫mapper接口接著是service層最后是controller。這樣每一層的數(shù)據(jù)流向都清楚寫完一個(gè)模塊立即用Postman驗(yàn)證接口不要等全部寫完再聯(lián)調(diào)那樣出了問(wèn)題很難定位。5.3 前端搭建順序前端用Vite創(chuàng)建npm create vitelatest travel-web -- --template vue創(chuàng)建完進(jìn)入目錄安裝核心依賴npm install npm install vue-router4 pinia axios element-plus前端建議按照路由 - 布局 - 頁(yè)面組件 - 請(qǐng)求對(duì)接 - 聯(lián)調(diào)的順序進(jìn)行。路由負(fù)責(zé)定義頁(yè)面路徑與組件的對(duì)應(yīng)關(guān)系布局把頂部導(dǎo)航欄和底部區(qū)域做成公共組件頁(yè)面組件再分別實(shí)現(xiàn)首頁(yè)、景點(diǎn)列表、景點(diǎn)詳情、線路詳情、酒店列表、訂單中心、登錄注冊(cè)等視圖。這里有一個(gè)經(jīng)驗(yàn)先搭好不受接口影響的部分比如頁(yè)面布局和靜態(tài)樣式之后再把接口數(shù)據(jù)逐步填進(jìn)去。如果你一上來(lái)就急著對(duì)接真實(shí)接口頁(yè)面上到處報(bào)錯(cuò)排查起來(lái)很難受。先給靜態(tài)頁(yè)面餓幾天把視覺(jué)和路由跑順再讓數(shù)據(jù)進(jìn)來(lái)兩邊的邊界就非常清楚。5.4 前后端聯(lián)調(diào)與部署聯(lián)調(diào)階段最常遇到的是跨域問(wèn)題。前端開(kāi)發(fā)環(huán)境跑在5173端口后端跑在8080端口直接被瀏覽器認(rèn)為是兩個(gè)源。解決辦法有兩個(gè)最簡(jiǎn)單后端加CORS配置或者前端在Vite配置代理。開(kāi)發(fā)階段我推薦Vite代理方案它不用改后端代碼生產(chǎn)環(huán)境也不影響// vite.config.js export default defineConfig({ server: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } })部署階段我通常采用的方式是后端打成JAR包在服務(wù)器上執(zhí)行java -jar travel-system.jar前端npm run build生成dist目錄交給Nginx托管。Nginx里需要配置一個(gè)關(guān)鍵項(xiàng)把訪問(wèn)/api的請(qǐng)求反向代理到后端服務(wù)端口同時(shí)解決Vue路由的history模式刷新404問(wèn)題后者通過(guò)try_files $uri $uri/ /index.html;來(lái)解決。6. 常見(jiàn)問(wèn)題與避坑記錄6.1 實(shí)際開(kāi)發(fā)中經(jīng)常出現(xiàn)的問(wèn)題這套項(xiàng)目我前后調(diào)試過(guò)多次下面幾個(gè)問(wèn)題幾乎每次都會(huì)遇到建議提前避開(kāi)問(wèn)題現(xiàn)象根本原因解決方案前端調(diào)接口報(bào)跨域開(kāi)發(fā)端口不一致Vite配置proxy或后端CORS刷新頁(yè)面404history路由模式未配置Nginx加try_filesMySQL插入中文亂碼字符集不是utf8mb4建庫(kù)時(shí)指定字符集返回的時(shí)間字段少8小時(shí)時(shí)區(qū)設(shè)置不一致配置文件加GMT8登錄后刷新token丟失token只存在內(nèi)存變量改存localStorageMyBatis-Plus分頁(yè)不生效缺少分頁(yè)插件配置注冊(cè)PaginationInnerInterceptorJAR包啟動(dòng)報(bào)端口占用8080端口被占用換端口或停止占用進(jìn)程這些坑在本地單機(jī)開(kāi)發(fā)時(shí)不一定都觸發(fā)但一到部署聯(lián)調(diào)就集中爆發(fā)。特別是Nginx配置里的try_files我記得第一次部署完前端頁(yè)面訪問(wèn)首頁(yè)一切正常一旦在景點(diǎn)詳情頁(yè)按下F5就報(bào)404折騰了很久才想到是history路由的回退問(wèn)題。6.2 答辯時(shí)容易被追問(wèn)的幾個(gè)點(diǎn)答辯復(fù)盤里我把老師最喜歡問(wèn)的問(wèn)題也整理了一下。第一個(gè)必問(wèn)的是為什么選這些技術(shù)你不能只答因?yàn)樗餍幸堰x型邏輯說(shuō)清楚SpringBoot生態(tài)成熟、Vue組件化開(kāi)發(fā)效率高、前后端分離便于后期擴(kuò)展。第二個(gè)高頻追問(wèn)是訂單超賣怎么處理哪怕你項(xiàng)目里根本沒(méi)做高并發(fā)測(cè)試也要能講出庫(kù)存更新采用樂(lè)觀鎖或條件更新的思路。第三個(gè)追問(wèn)方向是你的數(shù)據(jù)庫(kù)為什么這樣設(shè)計(jì)這時(shí)你需要把訂單主表和明細(xì)表分離、金額用DECIMAL、邏輯外鍵這些設(shè)計(jì)理由娓娓道來(lái)。還有一個(gè)容易被問(wèn)到但很多學(xué)生沒(méi)有準(zhǔn)備的點(diǎn)系統(tǒng)中有哪些不足。千萬(wàn)不要回答沒(méi)有不足這是典型的自我減分。你可以坦誠(chéng)指出幾個(gè)可優(yōu)化方向目前圖片存儲(chǔ)在本地目錄后續(xù)可以接入對(duì)象存儲(chǔ)現(xiàn)在沒(méi)有做消息隊(duì)列訂單超時(shí)取消可以使用延時(shí)隊(duì)列實(shí)現(xiàn)數(shù)據(jù)權(quán)限沒(méi)有細(xì)分到具體角色。這種回答同時(shí)體現(xiàn)了項(xiàng)目深度和自我認(rèn)知比強(qiáng)行吹噓效果好得多。6.3 對(duì)后來(lái)者的建議如果你的時(shí)間壓得很緊我建議按以下優(yōu)先級(jí)推進(jìn)先把用戶登錄注冊(cè)和景點(diǎn)模塊完整做通這兩塊涉及全鏈路做通以后整個(gè)系統(tǒng)的骨架就算立住了第二步做訂單模塊這是業(yè)務(wù)核心把庫(kù)存和狀態(tài)流想清楚第三步做管理端的數(shù)據(jù)看板這一塊代碼量不大但能顯著提升演示效果。酒店和評(píng)論模塊如果時(shí)間不夠可以保留為擴(kuò)展項(xiàng)不影響主流程演示。源碼、數(shù)據(jù)庫(kù)SQL腳本和開(kāi)發(fā)文檔這三樣?xùn)|西從項(xiàng)目第一天開(kāi)始就要保證和代碼同步。很多同學(xué)代碼寫完了SQL腳本卻還在本地的Navicat里沒(méi)有導(dǎo)出成文件這在畢業(yè)設(shè)計(jì)材料歸檔時(shí)會(huì)被扣分。每次修改表結(jié)構(gòu)都同步更新一份建表SQL文件放到工程根目錄的sql文件夾下這應(yīng)該成為肌肉記憶。7. 個(gè)人經(jīng)驗(yàn)補(bǔ)充我實(shí)際帶過(guò)的項(xiàng)目里好幾個(gè)學(xué)生照著類似的結(jié)構(gòu)做最后都能跑出一個(gè)像樣的大作業(yè)。但我必須說(shuō)一句大實(shí)話做這種畢業(yè)設(shè)計(jì)項(xiàng)目最大的難點(diǎn)從來(lái)不是某個(gè)單一功能寫不出來(lái)而是能不能把整個(gè)系統(tǒng)的業(yè)務(wù)邏輯串起來(lái)。今天聊的登錄注冊(cè)、景點(diǎn)展示、訂單流程每拆開(kāi)看都是常規(guī)套路但把它們整合在一個(gè)時(shí)序里出現(xiàn)問(wèn)題時(shí)鏈條會(huì)很長(zhǎng)。我自己最深的體會(huì)是源碼和數(shù)據(jù)庫(kù)腳本要勤快備份。這個(gè)項(xiàng)目開(kāi)發(fā)過(guò)程中我見(jiàn)過(guò)不止一次學(xué)生改錯(cuò)某個(gè)字段數(shù)據(jù)庫(kù)表結(jié)構(gòu)被搞亂備份文件因?yàn)闆](méi)及時(shí)導(dǎo)出一夜回到解放前。你可以簡(jiǎn)單一點(diǎn)每次大改動(dòng)之前用Git打一個(gè)tag數(shù)據(jù)庫(kù)定期導(dǎo)出.sql文件放到固定目錄成本極低但能救命。另一個(gè)實(shí)用的技巧是寫文檔時(shí)把數(shù)據(jù)庫(kù)設(shè)計(jì)表、接口清單和頁(yè)面原型圖盡早搭出來(lái)。開(kāi)發(fā)完成后補(bǔ)文檔往往會(huì)遺漏很多細(xì)節(jié)而前端頁(yè)面示意圖、接口參數(shù)說(shuō)明、數(shù)據(jù)庫(kù)表結(jié)構(gòu)說(shuō)明這三塊合在一起幾乎就是論文的系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)章節(jié)主體。前期稍微多花一點(diǎn)時(shí)間整理后期寫論文真的輕松不止一個(gè)量級(jí)。關(guān)于這套旅游網(wǎng)系統(tǒng)如果你已經(jīng)有商業(yè)想象力后面的擴(kuò)展方向其實(shí)挺多比如接入真實(shí)地圖API展示景點(diǎn)位置加入優(yōu)惠券和積分體系或者拓展成民宿預(yù)訂平臺(tái)。但這些都是后話先把眼前這版做扎實(shí)你就已經(jīng)贏過(guò)大部分人了。