花兩周時(shí)間把一個(gè)前后端分離的旅游平臺(tái)從零跑到部署上線是什么體驗(yàn)說(shuō)實(shí)話這和網(wǎng)上那些只教你某個(gè)局部功能的教程完全不同——你面對(duì)的是數(shù)據(jù)庫(kù)建模、接口設(shè)計(jì)、Vue頁(yè)面開(kāi)發(fā)、前后端聯(lián)調(diào)、服務(wù)器部署一整條鏈路任何一個(gè)環(huán)節(jié)出問(wèn)題整個(gè)項(xiàng)目就卡住。我做的這個(gè)桂林旅游景點(diǎn)導(dǎo)游平臺(tái)用的是SpringBootVueMyBatisMySQL這套經(jīng)典組合前后端完全分離源碼和部署流程都整理好了。如果你正在找畢業(yè)設(shè)計(jì)題目或者想通過(guò)一個(gè)完整項(xiàng)目把前后端分離開(kāi)發(fā)整個(gè)流程徹底打通這篇可以當(dāng)你的參考路線圖里面包含了我實(shí)際踩過(guò)的坑和調(diào)通的細(xì)節(jié)不是那種只貼代碼不解釋的筆記。1. 為什么拿桂林旅游景點(diǎn)導(dǎo)游平臺(tái)做實(shí)戰(zhàn)項(xiàng)目——選題邏輯與需求拆解1.1 旅游類業(yè)務(wù)為什么適合練前后端分離做項(xiàng)目練手或畢業(yè)設(shè)計(jì)最怕兩件事一是業(yè)務(wù)太抽象邊界不清楚做著做著不知道該寫(xiě)什么功能二是業(yè)務(wù)太復(fù)雜比如電商下單加庫(kù)存加支付物流一個(gè)人根本扛不住。旅游景點(diǎn)導(dǎo)游平臺(tái)恰好處在一個(gè)非常合適的區(qū)間。它的核心業(yè)務(wù)就是展示景點(diǎn)、規(guī)劃線路、下單預(yù)訂、用戶互動(dòng)天然分成游客端和管理端兩塊。游客端需要的是景點(diǎn)瀏覽、搜索篩選、查看詳情、預(yù)訂門(mén)票、收藏和評(píng)論管理端需要的是維護(hù)景點(diǎn)數(shù)據(jù)、管理訂單、審核內(nèi)容。這種雙端結(jié)構(gòu)就是前后端分離開(kāi)發(fā)最常見(jiàn)的業(yè)務(wù)形態(tài)前端界面偏展示型后端接口偏數(shù)據(jù)管理型兩邊各自的復(fù)雜度都不算高但加在一起能把整套開(kāi)發(fā)流程完整覆蓋。從技術(shù)角度講它涵蓋的知識(shí)點(diǎn)非常典型列表查詢、條件檢索、分頁(yè)、詳情展示、表單提交、登錄狀態(tài)管理、文件上傳景點(diǎn)圖片、關(guān)聯(lián)表查詢、一對(duì)多數(shù)據(jù)組裝。這些技能幾乎是所有后端開(kāi)發(fā)崗位的日常做完這個(gè)項(xiàng)目再去接觸電商、外賣(mài)、預(yù)約類系統(tǒng)你會(huì)發(fā)現(xiàn)業(yè)務(wù)變了但套路完全一樣基本可以平移。另外桂林景區(qū)的數(shù)據(jù)模型有天然的可擴(kuò)展性比如漓江、陽(yáng)朔、龍脊梯田這些景點(diǎn)可以掛多個(gè)分類、多條線路、若干圖片這為設(shè)計(jì)多對(duì)多關(guān)系和復(fù)雜的查詢條件提供了真實(shí)場(chǎng)景不用為了演示而硬造需求。1.2 功能模塊與頁(yè)面流轉(zhuǎn)先畫(huà)清楚再寫(xiě)代碼我動(dòng)手之前先把功能邊界列了一張表避免開(kāi)發(fā)中途加需求導(dǎo)致返工。這里分享我當(dāng)時(shí)整理的核心模塊清單游客端景點(diǎn)列表按分類篩選、關(guān)鍵詞搜索、景點(diǎn)詳情圖片輪播、介紹、評(píng)論、線路推薦一日游/兩日游、門(mén)票預(yù)訂下單、個(gè)人中心我的訂單、我的收藏管理端登錄校驗(yàn)、景點(diǎn)管理增刪改查圖片上傳、分類管理、線路管理、訂單管理查看和狀態(tài)更新、評(píng)論管理頁(yè)面流轉(zhuǎn)是這樣的用戶進(jìn)入首頁(yè)看到輪播圖和推薦景點(diǎn)點(diǎn)擊景點(diǎn)進(jìn)入詳情頁(yè)可以收藏、評(píng)論、選擇線路進(jìn)行預(yù)訂下單后進(jìn)入個(gè)人中心查看訂單狀態(tài)管理員通過(guò)獨(dú)立端口登錄進(jìn)入后臺(tái)操作維護(hù)數(shù)據(jù)前端把操作結(jié)果通過(guò)API同步到數(shù)據(jù)庫(kù)。整個(gè)流程走下來(lái)前后端能覆蓋到的交互模式基本都有了。1.3 技術(shù)選型的實(shí)際取舍沒(méi)有微服務(wù)也沒(méi)有盲目上全家桶技術(shù)選型上我堅(jiān)持一個(gè)原則能用簡(jiǎn)單方案解決的問(wèn)題不引入額外復(fù)雜度。后端用SpringBoot做基礎(chǔ)框架MyBatis做持久層MySQL存數(shù)據(jù)前端用Vue寫(xiě)頁(yè)面配合Vue Router做路由、Axios做請(qǐng)求管理端和游客端放在同一個(gè)前端工程里用路由和權(quán)限去區(qū)分而不是拆成兩個(gè)獨(dú)立應(yīng)用。沒(méi)有引入微服務(wù)的原因很直接這個(gè)體量的業(yè)務(wù)單體應(yīng)用完全夠用拆微服務(wù)只會(huì)增加服務(wù)注冊(cè)、配置中心、網(wǎng)關(guān)這些和學(xué)習(xí)目標(biāo)無(wú)關(guān)的負(fù)擔(dān)。沒(méi)用MyBatis-Plus而用原生的MyBatis是我刻意的選擇——原生MyBatis能讓你理解Mapper接口、XML映射、動(dòng)態(tài)SQL、結(jié)果映射這些底層機(jī)制一旦換成MyBatis-Plus這些細(xì)節(jié)會(huì)被封裝掉大半寫(xiě)起來(lái)爽了但底層理解容易留下盲區(qū)。當(dāng)然項(xiàng)目后期我也嘗試過(guò)換MyBatis-Plus來(lái)做對(duì)比確實(shí)省事不少這個(gè)放到后面擴(kuò)展部分細(xì)說(shuō)。如果你參考過(guò)若依框架會(huì)發(fā)現(xiàn)它的前后端分離版也是SpringBootVue但若依更像是一個(gè)快速開(kāi)發(fā)腳手架帶了一整套代碼生成器和管理系統(tǒng)模板對(duì)于學(xué)習(xí)來(lái)說(shuō)容易迷失在框架自帶的功能里自己從零搭一遍反而對(duì)每個(gè)環(huán)節(jié)的理解更扎實(shí)。2. 后端落地SpringBootMyBatisMySQL的數(shù)據(jù)模型與接口設(shè)計(jì)2.1 數(shù)據(jù)庫(kù)表設(shè)計(jì)九張表如何撐起整個(gè)業(yè)務(wù)后端開(kāi)發(fā)的第一步永遠(yuǎn)是數(shù)據(jù)庫(kù)設(shè)計(jì)。表結(jié)構(gòu)沒(méi)想清楚后面寫(xiě)接口會(huì)處處別扭。我最終設(shè)計(jì)了九張表這里把核心表的結(jié)構(gòu)和設(shè)計(jì)考慮講一下。表名用途關(guān)鍵字段設(shè)計(jì)說(shuō)明t_user用戶信息id, username, password, nickname, phone, avatar, role, create_time角色字段區(qū)分普通用戶和管理員密碼存的是BCrypt加密后的密文不能明文存儲(chǔ)t_category景點(diǎn)分類id, name, sort, statusstatus控制分類是否在前端展示方便下架不刪除t_scenic景點(diǎn)信息id, category_id, name, summary, detail, cover_image, images, price, address, status, create_timeimages字段用逗號(hào)分隔存多張圖片簡(jiǎn)單場(chǎng)景下比建子表更實(shí)用t_route旅游線路id, name, days, description, cover_image, price, statusdays表示游玩天數(shù)用于前端展示一日游/兩日游t_route_scenic線路景點(diǎn)關(guān)聯(lián)id, route_id, scenic_id, sort多對(duì)多關(guān)系表給線路里的景點(diǎn)排順序t_order訂單表id, order_no, user_id, scenic_id, route_id, quantity, total_price, status, create_time訂單號(hào)用時(shí)間戳加隨機(jī)數(shù)生成狀態(tài)字段用數(shù)字表示待支付/已支付/已完成/已取消t_comment評(píng)論表id, scenic_id, user_id, content, score, create_time冗余了nickname字段避免聯(lián)查用戶表這是常見(jiàn)的空間換時(shí)間優(yōu)化t_favorite收藏表id, user_id, scenic_id, create_time加唯一索引(user_id, scenic_id)防止重復(fù)收藏t_banner首頁(yè)輪播圖id, image, url, sort, status首頁(yè)運(yùn)營(yíng)位后臺(tái)可維護(hù)這里說(shuō)幾個(gè)設(shè)計(jì)要點(diǎn)。第一所有表都帶create_time字段而且由數(shù)據(jù)庫(kù)默認(rèn)值填充這樣插入數(shù)據(jù)時(shí)不用手動(dòng)傳第二景點(diǎn)表的status字段很重要景點(diǎn)下架用的是狀態(tài)而不是物理刪除避免訂單、收藏等關(guān)聯(lián)數(shù)據(jù)失效第三線路景點(diǎn)關(guān)聯(lián)表里的sort字段很多人會(huì)省略但實(shí)際線路中先到哪個(gè)景點(diǎn)、后到哪個(gè)景點(diǎn)是需要排序的沒(méi)有這個(gè)字段后期補(bǔ)數(shù)據(jù)會(huì)非常痛苦。我當(dāng)時(shí)花了一天時(shí)間建模和調(diào)整實(shí)際開(kāi)發(fā)中發(fā)現(xiàn)前期表設(shè)計(jì)多花的時(shí)間完全值得后面寫(xiě)Mapper幾乎沒(méi)出現(xiàn)字段不夠用、要改表結(jié)構(gòu)的情況。2.2 MyBatis的Mapper層設(shè)計(jì)動(dòng)態(tài)SQL才是效率關(guān)鍵MyBatis的配置我用了最標(biāo)準(zhǔn)的XML方式這也是面試?yán)锍１蛔穯?wèn)的寫(xiě)法。SpringBoot中需要兩步在application.yml配置數(shù)據(jù)源和MyBatis掃描路徑然后在啟動(dòng)類上加上MapperScan注解讓MyBatis掃描到Mapper接口。application.yml里的關(guān)鍵配置大概長(zhǎng)這樣spring: datasource: url: jdbc:mysql://localhost:3306/guilin_travel?useUnicodetruecharacterEncodingutf-8useSSLfalseserverTimezoneAsia/Shanghai username: root password: yourpassword driver-class-name: com.mysql.cj.jdbc.Driver mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.guilin.travel.entity configuration: map-underscore-to-camel-case: true這里兩個(gè)比較容易踩的細(xì)節(jié)。第一個(gè)是數(shù)據(jù)庫(kù)連接串里的serverTimezone參數(shù)MySQL 8默認(rèn)時(shí)區(qū)不是中國(guó)時(shí)區(qū)不配會(huì)報(bào)時(shí)間相關(guān)的錯(cuò)誤第二個(gè)是map-underscore-to-camel-case一定要開(kāi)啟這樣數(shù)據(jù)庫(kù)的create_time才能自動(dòng)映射到Java實(shí)體里的createTime不用手寫(xiě)一堆ResultMap。景點(diǎn)列表查詢是典型的動(dòng)態(tài)SQL場(chǎng)景用戶可能按分類過(guò)濾、按關(guān)鍵詞搜索、按價(jià)格排序、還要分頁(yè)。如果用MyBatis-Plus直接QueryWrapper搞定但原生MyBatis需要自己寫(xiě)動(dòng)態(tài)標(biāo)簽我實(shí)際寫(xiě)出來(lái)的Mapper XML片段如下select idfindByCondition resultTypecom.guilin.travel.entity.Scenic SELECT * FROM t_scenic where if testcategoryId ! null AND category_id #{categoryId} /if if testkeyword ! null and keyword ! AND (name LIKE CONCAT(%, #{keyword}, %) OR summary LIKE CONCAT(%, #{keyword}, %)) /if if teststatus ! null AND status #{status} /if /where if testsort ! null and sort ! ORDER BY ${sort} /if /select這里where標(biāo)簽會(huì)自動(dòng)處理第一個(gè)條件前面的AND問(wèn)題這個(gè)細(xì)節(jié)是原生態(tài)MyBatis最常用的技巧。注意ORDER BY后面用的是${sort}而不是#{sort}因?yàn)榕判蜃侄问菙?shù)據(jù)庫(kù)列名不能參數(shù)化但這里有SQL注入風(fēng)險(xiǎn)我在前端傳參時(shí)做了白名單校驗(yàn)只允許傳price_asc、price_desc等固定值而不是直接把前端傳的字符串拼進(jìn)去。分頁(yè)我用的是PageHelper分頁(yè)插件引入依賴后在查詢前調(diào)用PageHelper.startPage(pageNum, pageSize)查詢后拿到PageInfo里面已經(jīng)封裝好了總記錄數(shù)、總頁(yè)數(shù)這些分頁(yè)數(shù)據(jù)。返回給前端的數(shù)據(jù)結(jié)構(gòu)我已經(jīng)把列表和總數(shù)都包好前端表格組件直接用total字段渲染分頁(yè)器即可。2.3 Controller統(tǒng)一返回結(jié)構(gòu)和全局異常處理少走半天彎路寫(xiě)接口第二天我就發(fā)現(xiàn)一個(gè)問(wèn)題如果不統(tǒng)一返回結(jié)構(gòu)每個(gè)接口返回的JSON格式都不一樣前端Axios攔截器根本沒(méi)辦法做通用處理。于是我定義了一個(gè)Result類作為所有接口的統(tǒng)一返回體。public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.code 200; result.message 操作成功; result.data data; return result; } public static T ResultT error(String message) { ResultT result new Result(); result.code 500; result.message message; return result; } }與之配套的是一個(gè)RestControllerAdvice全局異常處理器把業(yè)務(wù)異常、參數(shù)校驗(yàn)異常、系統(tǒng)異常分別處理統(tǒng)一包裝成Result返回。這樣做的好處是前端只需要判斷code是不是200其余情況直接彈出message即可不會(huì)因?yàn)槟硞€(gè)接口的返回格式不一致導(dǎo)致前端解析崩潰。實(shí)際開(kāi)發(fā)中我發(fā)現(xiàn)很多新手項(xiàng)目里Controller直接返回實(shí)體類或者M(jìn)ap表面上省了封裝代碼但一旦前端需要區(qū)分成功但數(shù)據(jù)為空和請(qǐng)求異常這兩種情況就會(huì)非常被動(dòng)。再配合Valid注解做參數(shù)校驗(yàn)后端在入口處就攔截掉空參數(shù)、非法參數(shù)不用在每個(gè)Service里寫(xiě)一堆if判斷。2.4 圖片上傳與存儲(chǔ)先本地后對(duì)象存儲(chǔ)景點(diǎn)圖片的上傳管理我第一版用的是最簡(jiǎn)單的本地存儲(chǔ)方案后端接收MultipartFile文件重命名為時(shí)間戳加隨機(jī)數(shù)保存到服務(wù)器指定的upload目錄再把訪問(wèn)路徑存到數(shù)據(jù)庫(kù)。SpringBoot里需要配置靜態(tài)資源映射讓上傳的圖片可以通過(guò)URL直接訪問(wèn)Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceHandler(file: uploadPath /); }這樣前端只需要用/upload/xxx.jpg就能拿到圖片。這個(gè)方案在本地開(kāi)發(fā)和單機(jī)部署完全夠用代碼量少理解也直觀。如果將來(lái)要上云可以把上傳邏輯替換為MinIO或OSS前端訪問(wèn)路徑完全不用變因?yàn)楹蠖朔祷亟o前端的始終是一個(gè)URL字符串。3. Vue前端從零搭建路由、API封裝與頁(yè)面編碼3.1 前端工程化用Vite還是Vue CLI前端這部分我糾結(jié)了一下是用Vue CLI還是Vite。考慮到Vite在開(kāi)發(fā)環(huán)境下的啟動(dòng)速度明顯更快而且Vue官方已經(jīng)將Vite作為默認(rèn)推薦我直接用Vite初始化了一個(gè)Vue 3項(xiàng)目搭配Element Plus組件庫(kù)做后臺(tái)管理界面游客端頁(yè)面則用了手寫(xiě)的樣式保持個(gè)性化。如果你更習(xí)慣Vue 2的寫(xiě)法用Vue CLI腳手架也是一樣的思路核心技術(shù)點(diǎn)不沖突。安裝依賴和啟動(dòng)開(kāi)發(fā)服務(wù)器這步我在環(huán)境配置那篇筆記里踩過(guò)一次坑Vite需要Node.js 16以上版本版本太老會(huì)直接報(bào)錯(cuò)。建議先用node -v確認(rèn)一下當(dāng)前版本再?zèng)Q定是否升級(jí)。3.2 路由設(shè)計(jì)游客端和管理端如何共存一個(gè)工程里同時(shí)容納游客端和管理端最核心的是路由規(guī)劃。游客端是公開(kāi)訪問(wèn)的管理端需要登錄后才有權(quán)限所以我拆了兩套路由一套是基礎(chǔ)路由包括首頁(yè)、景點(diǎn)列表、景點(diǎn)詳情、登錄頁(yè)另一套是管理端路由統(tǒng)一掛在/layout組件下用路由守衛(wèi)校驗(yàn)登錄狀態(tài)。核心路由表長(zhǎng)這樣const routes [ { path: /, component: Home }, { path: /scenic, component: ScenicList }, { path: /scenic/:id, component: ScenicDetail }, { path: /login, component: Login }, { path: /admin, component: AdminLayout, meta: { requiresAuth: true }, children: [ { path: scenic, component: AdminScenic }, { path: order, component: AdminOrder }, { path: comment, component: AdminComment } ] } ]; router.beforeEach((to, from, next) { const token localStorage.getItem(token); if (to.meta.requiresAuth !token) { next(/login); } else { next(); } });這里的關(guān)鍵點(diǎn)是meta里的requiresAuth標(biāo)記。我一開(kāi)始把權(quán)限判斷寫(xiě)死在每個(gè)頁(yè)面的created里結(jié)果發(fā)現(xiàn)每個(gè)頁(yè)面都要粘貼一遍判斷代碼后來(lái)統(tǒng)一收斂到路由守衛(wèi)里代碼干凈很多。3.3 Axios封裝請(qǐng)求攔截器和響應(yīng)攔截器的分工幾乎所有前端請(qǐng)求都要做兩件事自動(dòng)攜帶token、統(tǒng)一處理錯(cuò)誤提示。我封裝了一個(gè)request.js核心邏輯如下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 result response.data; if (result.code 200) { return result.data; } if (result.code 401) { localStorage.removeItem(token); router.push(/login); return Promise.reject(new Error(登錄已過(guò)期)); } ElMessage.error(result.message); return Promise.reject(new Error(result.message)); }, error { ElMessage.error(網(wǎng)絡(luò)請(qǐng)求異常); return Promise.reject(error); } );baseURL用的是/api配合前端開(kāi)發(fā)環(huán)境的代理配置把請(qǐng)求轉(zhuǎn)發(fā)到后端的localhost:8080。響應(yīng)攔截器先判斷Result.code只有200才把data返回給頁(yè)面其他情況直接彈出錯(cuò)誤提示頁(yè)面里的業(yè)務(wù)代碼就不用再重復(fù)寫(xiě)錯(cuò)誤處理了。這種方式讓頁(yè)面的請(qǐng)求代碼從十幾行縮減到幾行而且審查得很清楚。3.4 核心頁(yè)面實(shí)現(xiàn)列表頁(yè)、詳情頁(yè)和下單流程景點(diǎn)列表頁(yè)是典型的查詢條件表格/卡片布局。頁(yè)面加載時(shí)調(diào)用getScenicList方法傳入分類篩選條件和搜索關(guān)鍵詞const getList async () { loading.value true; try { const result await getScenicList({ categoryId: categoryId.value || null, keyword: keyword.value, pageNum: pageNum.value, pageSize: 10 }); scenicList.value result.list; total.value result.total; } finally { loading.value false; } };景點(diǎn)詳情頁(yè)要展示的是基本信息圖片輪播評(píng)論列表收藏按鈕預(yù)訂入口。數(shù)據(jù)來(lái)源分別是景點(diǎn)詳情接口、評(píng)論接口和收藏接口。詳情接口一次返回景點(diǎn)基本信息評(píng)論和收藏分別在頁(yè)面掛載時(shí)并行請(qǐng)求用Promise.all控制并發(fā)請(qǐng)求結(jié)束狀態(tài)避免一個(gè)接口阻塞整個(gè)頁(yè)面渲染。下單流程我簡(jiǎn)化成了訂單創(chuàng)建邏輯前端先拉取景點(diǎn)和線路信息用戶選擇游玩日期和數(shù)量點(diǎn)擊提交后調(diào)用createOrder接口后端生成訂單對(duì)象并寫(xiě)入數(shù)據(jù)庫(kù)前端帶著返回的訂單編號(hào)跳轉(zhuǎn)到我的訂單頁(yè)面展示支付狀態(tài)占位。整個(gè)流程雖然簡(jiǎn)化了但訂單表的狀態(tài)機(jī)設(shè)計(jì)保留了完整邏輯以后接支付網(wǎng)關(guān)可以平滑擴(kuò)展。3.5 后臺(tái)管理頁(yè)面表格加彈窗是標(biāo)配管理端頁(yè)面沒(méi)有做太多創(chuàng)新設(shè)計(jì)就是扎實(shí)的表格加彈窗表單左側(cè)導(dǎo)航固定右側(cè)內(nèi)容區(qū)用Element Plus的el-table展示數(shù)據(jù)頂部的工具欄放新增和條件搜索行內(nèi)放編輯和刪除按鈕。新增和編輯共用一個(gè)彈窗表單通過(guò)判斷row參數(shù)是否存在來(lái)區(qū)分模式。景點(diǎn)管理頁(yè)是管理端里最復(fù)雜的因?yàn)樯婕皥D片上傳。上傳邏輯是先調(diào)upload接口把圖片存到后端拿到返回的URL后再把這個(gè)URL作為表單字段提交。如果先提交表單再上傳圖片會(huì)出現(xiàn)圖片還沒(méi)傳完表單已經(jīng)提交的情況處理起來(lái)很別扭。調(diào)整順序之后整個(gè)流程穩(wěn)定多了。4. 聯(lián)調(diào)階段值得記錄的四個(gè)問(wèn)題——CORS、JWT、日期格式與空值前后端分離開(kāi)發(fā)必然要面對(duì)聯(lián)調(diào)這一階段我實(shí)際遇到的問(wèn)題比開(kāi)發(fā)階段多得多挑了四個(gè)典型記錄在這都是常規(guī)文檔不太會(huì)細(xì)講的內(nèi)容。4.1 跨域問(wèn)題的完整排查鏈路開(kāi)發(fā)模式下前端跑在5173端口后端跑在8080端口瀏覽器直接發(fā)請(qǐng)求必然觸發(fā)跨域。我在后端項(xiàng)目里加了一個(gè)CorsConfig的Bean用WebMvcConfigurer配置允許跨域指定允許的路徑、域名和方法。但如果你的前端請(qǐng)求帶Authorization頭還需要單獨(dú)考慮Header暴露否則前端Axios拿不到響應(yīng)頭里的狀態(tài)信息。我實(shí)際排查時(shí)發(fā)現(xiàn)了一個(gè)隱蔽問(wèn)題后端雖然配置了CORS但Spring Security如果存在它的攔截器優(yōu)先級(jí)更高跨域配置可能被Security的過(guò)濾器提前攔截掉。好在我的項(xiàng)目沒(méi)有引入Spring Security用自定義攔截器做鑒權(quán)跨域配置直接生效。如果你的項(xiàng)目同時(shí)有Spring Security需要額外配置Security的CorsConfigurationSource。4.2 JWT登錄鑒權(quán)的實(shí)現(xiàn)細(xì)節(jié)和放行規(guī)則登錄態(tài)管理我選了JWT原因很簡(jiǎn)單服務(wù)端不需要存session適合前后端分離的分布式場(chǎng)景。后端在用戶登錄時(shí)生成token返回給前端前端存儲(chǔ)到localStorage請(qǐng)求時(shí)通過(guò)Authorization頭攜帶后端寫(xiě)一個(gè)攔截器統(tǒng)一校驗(yàn)。JWT的關(guān)鍵實(shí)現(xiàn)邏輯不算復(fù)雜用jjwt依賴生成tokensub放用戶IDexp設(shè)置過(guò)期時(shí)間為24小時(shí)。真正容易出問(wèn)題的是攔截器里哪些路徑要放行。如果攔截器配置成所有接口都要驗(yàn)證那么登錄接口自身也被攔截了因?yàn)榈卿洉r(shí)根本沒(méi)有token。我的配置方式是登錄接口、景點(diǎn)列表接口、景點(diǎn)詳情接口這些公開(kāi)接口放行管理端接口全部要求登錄個(gè)人中心和訂單相關(guān)接口必須登錄。用攔截器的時(shí)候注意放行規(guī)則應(yīng)該寫(xiě)成白名單形式而不是黑名單——只明確列出不需要登錄的路徑其余全部攔截這樣更安全。4.3 日期格式和null值的隱形坑排查過(guò)兩個(gè)坑。第一個(gè)是前端傳2025-06-01給后端后端用LocalDateTime接收直接報(bào)格式錯(cuò)誤。原因是Jackson默認(rèn)只認(rèn)識(shí)ISO格式需要全局配置日期格式我在application.yml里加了spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8第二個(gè)坑是數(shù)據(jù)庫(kù)的date字段傳到前端后顯示成2025-06-01T00:00:00.00000:00這樣的UTC格式前端要再轉(zhuǎn)換一次。后來(lái)我在實(shí)體類的日期字段上加了JsonFormat注解指定輸出格式前端直接拿到2025-06-01 00:00:00就省事了。null值的問(wèn)題體現(xiàn)在分頁(yè)接口上當(dāng)列表為空時(shí)后端返回的list是null還是空數(shù)組直接影響前端v-for渲染。我統(tǒng)一處理為只要數(shù)據(jù)庫(kù)沒(méi)查到數(shù)據(jù)返回空數(shù)組而不是null前端不用寫(xiě)一堆空值防御代碼。4.4 MyBatis動(dòng)態(tài)SQL里if判斷等于0的問(wèn)題這是我在寫(xiě)篩選功能時(shí)真正踩過(guò)的坑。定義用戶的角色字段時(shí)我一開(kāi)始判斷條件寫(xiě)了if testrole ! null and role ! 結(jié)果前端傳role0管理員時(shí)條件不生效因?yàn)镸yBatis的OGNL表達(dá)式把數(shù)字0當(dāng)成了false空值處理。排查半天才定位到問(wèn)題不是SQL邏輯而是MyBatis對(duì)整數(shù)類型的if判斷有個(gè)特殊規(guī)則數(shù)值為0時(shí)非空判斷不成立。解決方式有兩種一是改用String類型傳參傳0而不是0二是判斷條件寫(xiě)全if testrole ! null and role ! 并在Service層把0轉(zhuǎn)換成字符串。我最后選擇在后端把篩選參數(shù)的類型統(tǒng)一調(diào)整避免這類隱蔽問(wèn)題再次出現(xiàn)。5. 從開(kāi)發(fā)機(jī)到云服務(wù)器完整部署流程與配置清單項(xiàng)目在本地跑通只是第一步部署到服務(wù)器才是完整閉環(huán)。我用的是一臺(tái)Linux云服務(wù)器配置是2核4G對(duì)這套系統(tǒng)來(lái)說(shuō)完全夠用。5.1 服務(wù)器基礎(chǔ)環(huán)境準(zhǔn)備JDK、MySQL8、Nginx部署環(huán)境三件套JDK、MySQL、Nginx。我的服務(wù)器是CentOS系統(tǒng)JDK用tar包解壓安裝MySQL用官方rpm源安裝Nginx用yum直接裝。具體步驟不贅述但有幾個(gè)關(guān)鍵點(diǎn)必須提醒。MySQL裝完一定要執(zhí)行mysql_secure_installation做基礎(chǔ)安全配置否則root空密碼裸露在公網(wǎng)上很快會(huì)被掃描爆破。另外MySQL 8的密碼策略比5.7嚴(yán)格設(shè)置密碼時(shí)要滿足長(zhǎng)度和復(fù)雜度要求否則會(huì)報(bào)錯(cuò)。數(shù)據(jù)庫(kù)導(dǎo)入就是把本地導(dǎo)出的SQL文件用source命令執(zhí)行一遍注意在導(dǎo)入前先創(chuàng)建好數(shù)據(jù)庫(kù)并指定默認(rèn)字符集utf8mb4否則中文會(huì)亂碼。5.2 后端打包發(fā)布Maven打包與Systemd守護(hù)進(jìn)程后端工程是標(biāo)準(zhǔn)的Maven項(xiàng)目打包命令非常簡(jiǎn)單mvn clean package -DskipTests打包后在target目錄生成一個(gè)jar包。上傳到服務(wù)器后我一開(kāi)始用java -jar前臺(tái)啟動(dòng)但關(guān)掉SSH窗口進(jìn)程就死了。后來(lái)寫(xiě)了一個(gè)Systemd服務(wù)文件讓后端作為守護(hù)進(jìn)程運(yùn)行[Unit] DescriptionGuilin Travel Backend Afternetwork.target [Service] Userroot WorkingDirectory/opt/guilin ExecStart/usr/bin/java -Xms512m -Xmx512m -jar /opt/guilin/guilin-backend.jar SuccessExitStatus143 Restartalways RestartSec10 [Install] WantedBymulti-user.target配置好之后執(zhí)行systemctl enable設(shè)為開(kāi)機(jī)自啟用systemctl start啟動(dòng)用journalctl -u guilin-backend查看日志。啟動(dòng)參數(shù)里Xms和Xmx設(shè)置一樣大避免了JVM動(dòng)態(tài)擴(kuò)展內(nèi)存帶來(lái)的性能抖動(dòng)2G內(nèi)存的服務(wù)器運(yùn)行很平穩(wěn)。5.3 前端構(gòu)建與Nginx反向代理配置前端構(gòu)建相對(duì)簡(jiǎn)單npm run build會(huì)生成dist目錄里面是純靜態(tài)文件。把這個(gè)目錄上傳到服務(wù)器配置Nginx指向它同時(shí)把/api路徑反向代理到后端8080端口這是前后端分離項(xiàng)目部署最核心的一步。server { listen 80; server_name your_domain_or_ip; root /opt/guilin/dist; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location /upload/ { proxy_pass http://127.0.0.1:8080; } }location /里的try_files配置很關(guān)鍵它把前端路由的刷新請(qǐng)求都指向index.html否則在頁(yè)面里點(diǎn)路由刷新會(huì)出現(xiàn)404。如果不加這個(gè)Vue Router的history模式部署后刷新就白屏這是前后端分離部署最常見(jiàn)的坑之一。5.4 部署上線后必須檢查的性能隱患上線后我做了幾項(xiàng)檢查。第一是MySQL連接串里的useSSL參數(shù)部署環(huán)境如果MySQL配了SSL但連接串是useSSLfalse會(huì)一直報(bào)SSL連接錯(cuò)誤排查方式是看后端日志里at com.mysql.cj.jdbc的報(bào)錯(cuò)堆棧非常典型。第二是MySQL最大連接數(shù)默認(rèn)151如果前端并發(fā)不高還好但測(cè)試階段用壓測(cè)工具一跑就會(huì)把連接池打滿建議配置到300以上。第三是JVM的GC日志觀察Full GC頻率如果太高說(shuō)明堆內(nèi)存設(shè)置不合理。我把這些檢查項(xiàng)整理成了一個(gè)部署檢查清單每次部署新項(xiàng)目都按這個(gè)順序過(guò)一遍防火墻端口是否放行、數(shù)據(jù)庫(kù)是否可遠(yuǎn)程訪問(wèn)、后端進(jìn)程是否守護(hù)運(yùn)行、Nginx是否配置反向代理、靜態(tài)資源能否訪問(wèn)、接口能否通過(guò)域名請(qǐng)求。6. 項(xiàng)目復(fù)盤(pán)這套系統(tǒng)還能怎么擴(kuò)展6.1 換用MyBatis-Plus到底能省多少事項(xiàng)目完成之后我把Mapper層整體換成了MyBatis-Plus做了一個(gè)對(duì)比實(shí)驗(yàn)。同樣的分頁(yè)查詢用MyBatis-Plus的Page對(duì)象加LambdaQueryWrapper代碼量確實(shí)減少了大概四成不再需要手寫(xiě)XML里的動(dòng)態(tài)SQL標(biāo)簽簡(jiǎn)單查詢一句lambda表達(dá)式搞定。如果你追求開(kāi)發(fā)效率MyBatis-Plus確實(shí)值得用。但如果你還在學(xué)習(xí)階段我強(qiáng)烈建議先用原生MyBatis把動(dòng)態(tài)SQL、ResultMap、多表查詢這些底子打好再切換效率方案否則出了問(wèn)題都不知道從哪排查。6.2 進(jìn)階方向地圖、Redis和對(duì)象存儲(chǔ)這套系統(tǒng)繼續(xù)擴(kuò)展的方向很清晰。第一是接地圖SDK在景點(diǎn)詳情頁(yè)展示景點(diǎn)位置在旅游線路頁(yè)展示線路軌跡這個(gè)只要申請(qǐng)地圖開(kāi)放平臺(tái)的密鑰前端引入對(duì)應(yīng)的JavaScript庫(kù)就能實(shí)現(xiàn)數(shù)據(jù)模型已經(jīng)預(yù)留了經(jīng)緯度字段。第二是引入Redis做緩存和熱點(diǎn)數(shù)據(jù)加速比如首頁(yè)輪播圖、景點(diǎn)列表熱門(mén)數(shù)據(jù)緩存起來(lái)后數(shù)據(jù)庫(kù)壓力會(huì)明顯下降。第三是把本地圖片存儲(chǔ)替換為MinIO或云對(duì)象存儲(chǔ)解決單機(jī)磁盤(pán)容量和訪問(wèn)帶寬的問(wèn)題。如果要做視頻類內(nèi)容也可以參考Vue播放m3u8這類視頻流方案的集成方式把景區(qū)宣傳視頻嵌進(jìn)詳情頁(yè)。6.3 給準(zhǔn)備復(fù)用源碼的朋友的建議如果你打算在這個(gè)項(xiàng)目源碼基礎(chǔ)上做二次開(kāi)發(fā)或改造我有幾條實(shí)際建議。第一數(shù)據(jù)庫(kù)SQL文件和Redis的配置項(xiàng)都在源碼目錄里有導(dǎo)入后記得修改application.yml里的數(shù)據(jù)庫(kù)密碼和IP地址。第二前端管理端的賬號(hào)是初始化時(shí)手動(dòng)寫(xiě)入數(shù)據(jù)庫(kù)的登錄時(shí)密碼經(jīng)過(guò)BCrypt加密不要直接用明文SQL插入否則登錄會(huì)失敗。第三運(yùn)行項(xiàng)目前最好先按照我前面說(shuō)的流程把環(huán)境確認(rèn)一遍JDK版本、Maven版本、Node版本、MySQL版本每一步都用命令行驗(yàn)證避免浪費(fèi)一下午在環(huán)境配置上。我在實(shí)際運(yùn)行中發(fā)現(xiàn)前后端分離項(xiàng)目真正花時(shí)間的不是寫(xiě)代碼而是調(diào)通鏈路從瀏覽器發(fā)請(qǐng)求到Nginx到SpringBoot到MyBatis到MySQL數(shù)據(jù)再原路返回渲染整個(gè)過(guò)程每個(gè)環(huán)節(jié)都可能出問(wèn)題而多數(shù)問(wèn)題不在你自己的代碼里而在配置和環(huán)境的默認(rèn)設(shè)置中。所以調(diào)試時(shí)一定要習(xí)慣看完整報(bào)錯(cuò)堆棧一層層往下追而不是只看最上面那段異常描述。多踩幾次坑把每一個(gè)問(wèn)題的排查路徑記下來(lái)你的排錯(cuò)速度會(huì)隨著項(xiàng)目數(shù)量增長(zhǎng)得越來(lái)越快。