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