前后端分離健身俱樂部網(wǎng)站系統(tǒng)這個(gè)項(xiàng)目我做過類似的好幾個(gè)學(xué)員和粉絲也拿這類選題當(dāng)畢業(yè)設(shè)計(jì)或者練手項(xiàng)目。說(shuō)實(shí)話SpringBoot Vue MyBatis MySQL這一套組合放在今天依然是前后端分離項(xiàng)目里最有代表性的技術(shù)棧之一。它不像微服務(wù)那套那么重但麻雀雖小五臟俱全RESTful API、數(shù)據(jù)持久化、JWT鑒權(quán)、跨域處理、前端路由守衛(wèi)、反向代理這些核心概念全都能覆蓋到。如果你正準(zhǔn)備搞一個(gè)能寫進(jìn)簡(jiǎn)歷、能跑起來(lái)演示的完整系統(tǒng)這個(gè)方向非常合適。這篇就圍繞健身俱樂部這個(gè)業(yè)務(wù)場(chǎng)景把整個(gè)系統(tǒng)的設(shè)計(jì)思路、核心模塊、關(guān)鍵實(shí)現(xiàn)和部署過程全拆開來(lái)講。包括后端接口怎么組織、數(shù)據(jù)庫(kù)表怎么設(shè)計(jì)、前端頁(yè)面怎么對(duì)接、打包部署要注意哪些坑每一步我都會(huì)把選擇背后的理由說(shuō)清楚。不管你是有一定基礎(chǔ)的開發(fā)者想找參考還是剛學(xué)完框架想做實(shí)戰(zhàn)項(xiàng)目這篇都能幫你省下不少?gòu)澛贰?. 項(xiàng)目整體設(shè)計(jì)與思路拆解1.1 為什么選健身俱樂部這個(gè)業(yè)務(wù)場(chǎng)景做項(xiàng)目最怕的就是業(yè)務(wù)太抽象比如“電商系統(tǒng)”“管理系統(tǒng)”這種邊界模糊做著做著就不知道自己該實(shí)現(xiàn)什么了。健身俱樂部這個(gè)場(chǎng)景好在業(yè)務(wù)閉環(huán)非常清晰核心鏈條就是會(huì)員注冊(cè) - 查看課程 - 預(yù)約課程 - 教練排課 - 上課簽到 - 消費(fèi)結(jié)算。這個(gè)閉環(huán)涵蓋了最常見的CRUD操作還牽扯到一對(duì)多、多對(duì)多關(guān)系以及訂單狀態(tài)流轉(zhuǎn)這類稍微進(jìn)階一點(diǎn)的數(shù)據(jù)處理。另外健身俱樂部的業(yè)務(wù)天然適合做權(quán)限區(qū)分。會(huì)員看到的是課程列表和自己預(yù)約記錄教練看到的是自己的排課和學(xué)員列表管理員則需要管理會(huì)員、審核課程、查看營(yíng)收統(tǒng)計(jì)。有了三種角色JWT鑒權(quán)、路由守衛(wèi)、按鈕級(jí)權(quán)限控制這些技術(shù)點(diǎn)就能全部落地上而不是空談概念。1.2 前后端分離架構(gòu)的優(yōu)勢(shì)在哪里早年的Java Web項(xiàng)目是JSP Servlet那一套前端頁(yè)面寫在Java項(xiàng)目里模板渲染交給服務(wù)端技術(shù)和業(yè)務(wù)耦合得非常緊。換個(gè)前端樣式要?jiǎng)雍蠖舜a前端工程師和后端工程師經(jīng)常在一個(gè)項(xiàng)目里互相踩腳。前后端分離的本質(zhì)是把“展示邏輯”和“業(yè)務(wù)邏輯”徹底拆成兩個(gè)獨(dú)立工程中間只通過JSON格式的HTTP接口通信。這種架構(gòu)帶來(lái)的直接好處有三個(gè)。第一前端可以獨(dú)立部署Vue打包出來(lái)就是一堆靜態(tài)文件扔給Nginx托管就行完全不需要Java運(yùn)行環(huán)境。第二后端接口可以被多個(gè)客戶端復(fù)用同一套API既給Web用以后要做小程序或者App也能直接用。第三團(tuán)隊(duì)協(xié)作效率高前端用Mock數(shù)據(jù)開發(fā)后端用Postman調(diào)試接口兩邊只要約定好接口文檔就能并行開工。1.3 技術(shù)選型的理由和替代方案SpringBoot MyBatis MySQL在這個(gè)項(xiàng)目里是最順手的組合。SpringBoot不用多說(shuō)自動(dòng)裝配和Starter機(jī)制大幅簡(jiǎn)化了配置一個(gè)可運(yùn)行的Web服務(wù)幾行代碼就能起來(lái)。MyBatis的優(yōu)勢(shì)在于SQL可控復(fù)雜查詢可以手寫SQL優(yōu)化而且動(dòng)態(tài)SQL在按條件篩選這種場(chǎng)景下非常好用。MySQL穩(wěn)定可靠學(xué)習(xí)成本低部署簡(jiǎn)單作為中小型項(xiàng)目的數(shù)據(jù)庫(kù)完全沒有壓力。前端選Vue是因?yàn)樗臐u進(jìn)式框架特性很契合這類項(xiàng)目。從Vue 2到Vue 3Composition API的引入讓邏輯復(fù)用更清晰腳手架項(xiàng)目默認(rèn)幫你配好了Vite或者Webpack路由和狀態(tài)管理都有官方的配套方案。當(dāng)然你完全可以用MyBatis-Plus替代MyBatis單表CRUD幾乎不用寫SQL或者用Spring Data JPA那是另一套風(fēng)格。這些不是誰(shuí)比誰(shuí)好關(guān)鍵是你對(duì)哪套更熟。我建議學(xué)習(xí)階段盡量用原生MyBatis把SQL和映射關(guān)系親手寫一遍理解了底層后再用增強(qiáng)框架認(rèn)知會(huì)扎實(shí)很多。提示既然是做完整系統(tǒng)別只把它當(dāng)練習(xí)。如果你打算寫進(jìn)簡(jiǎn)歷一定要把業(yè)務(wù)模塊梳理清楚并且保證項(xiàng)目能在新環(huán)境下一鍵跑起來(lái)。跑不起來(lái)的項(xiàng)目寫再多技術(shù)點(diǎn)都白搭。2. 數(shù)據(jù)庫(kù)設(shè)計(jì)與后端核心實(shí)現(xiàn)2.1 數(shù)據(jù)庫(kù)表結(jié)構(gòu)怎么規(guī)劃健身俱樂部系統(tǒng)的表設(shè)計(jì)重點(diǎn)在于把業(yè)務(wù)核心鏈路的數(shù)據(jù)模型理清楚。我一般會(huì)分三組來(lái)設(shè)計(jì)基礎(chǔ)信息組、業(yè)務(wù)流轉(zhuǎn)組、訂單支付組。基礎(chǔ)信息組包括用戶表、會(huì)員信息表、教練信息表、課程表。用戶表保存登錄賬號(hào)、密碼加密存儲(chǔ)、角色類型這三要素角色用int型字段區(qū)分0是管理員1是教練2是會(huì)員。會(huì)員信息表關(guān)聯(lián)用戶表擴(kuò)展存身高、體重、體脂率、會(huì)員等級(jí)這些健身屬性。課程表主要字段是課程名稱、封面圖、分類、簡(jiǎn)介、價(jià)格、上課地點(diǎn)。業(yè)務(wù)流轉(zhuǎn)組是重點(diǎn)包括課程預(yù)約表和教練排課表。預(yù)約表要和課程表、用戶表建立關(guān)聯(lián)記錄約課時(shí)間、狀態(tài)。狀態(tài)字段也是用int表示0待上課、1已上課、2已取消。教練排課表則需要設(shè)置每個(gè)時(shí)間段的可約人數(shù)上限這個(gè)字段在后續(xù)實(shí)現(xiàn)預(yù)約校驗(yàn)時(shí)很關(guān)鍵。訂單支付組負(fù)責(zé)消費(fèi)記錄訂單表包含訂單號(hào)、用戶ID、商品類型、金額、支付狀態(tài)、支付時(shí)間、支付方式。另外再加一個(gè)操作日志表記錄誰(shuí)在什么時(shí)間改了什么數(shù)據(jù)后臺(tái)管理時(shí)能看到操作痕跡。創(chuàng)建表的時(shí)候有幾個(gè)細(xì)節(jié)容易忽略。第一所有表都建議加create_time和update_time字段用datetime類型后面做排序和分析數(shù)據(jù)都方便。第二邏輯刪除字段del_flag建議加上物理刪除對(duì)運(yùn)營(yíng)類系統(tǒng)來(lái)說(shuō)風(fēng)險(xiǎn)太高。第三金額字段強(qiáng)烈建議用decimal而不是float用float存金額做加減運(yùn)算會(huì)出現(xiàn)精度丟失。2.2 SpringBoot項(xiàng)目結(jié)構(gòu)怎么組織才清晰后端工程的結(jié)構(gòu)直接影響后續(xù)維護(hù)體驗(yàn)。按模塊分包是最常規(guī)的約定但很多人習(xí)慣把所有東西都塞到controller和service兩個(gè)包下面結(jié)果就是類越來(lái)越多后期自己都找不到。這里貼一下我用下來(lái)的結(jié)構(gòu)com.example.fitness ├── config # 配置類跨域配置、JWT攔截器注冊(cè)、全局異常處理 ├── controller # 接口層接收參數(shù)返回統(tǒng)一響應(yīng)體 ├── service # 業(yè)務(wù)層接口 實(shí)現(xiàn)類 ├── mapper # MyBatis的Mapper接口 ├── entity # 數(shù)據(jù)庫(kù)對(duì)應(yīng)的實(shí)體類 ├── dto # 數(shù)據(jù)傳輸對(duì)象接收請(qǐng)求參數(shù) ├── vo # 視圖對(duì)象返回給前端的數(shù)據(jù)結(jié)構(gòu) ├── utils # 工具類JWT工具、密碼加密工具 └── common # 公共枚舉、常量、統(tǒng)一返回結(jié)果封裝entity、dto、vo分開這一點(diǎn)很多人會(huì)忽略。直接用entity接收前端參數(shù)、再直接返回給前端圖省事一時(shí)爽后面改需求就是災(zāi)難。舉個(gè)例子前端傳登錄參數(shù)需要的是用戶名和密碼但user表有十幾個(gè)字段直接拿實(shí)體接收會(huì)有一些安全隱患多傳字段也容易出問題。只暴露出需要的字段接口安全性和可讀性都好很多。統(tǒng)一返回結(jié)果也要在一開始就做好。我習(xí)慣定義一個(gè)Result對(duì)象里面有code、message、data三個(gè)字段。code為200表示成功401表示未登錄或token失效500表示服務(wù)器異常。所有接口都返回這個(gè)對(duì)象前端axios封裝時(shí)只需處理一種數(shù)據(jù)結(jié)構(gòu)。2.3 MyBatis中幾個(gè)會(huì)踩坑的細(xì)節(jié)MyBatis看似簡(jiǎn)單但用不好真會(huì)讓人頭疼兩三天這里把最容易踩的幾個(gè)點(diǎn)挨個(gè)說(shuō)。2.3.1 Mapper接口掃描配置Mapper接口和XML文件能否被正確識(shí)別取決于兩處配置。第一處是在啟動(dòng)類上加MapperScan(com.example.fitness.mapper)或者每個(gè)Mapper接口上單獨(dú)加注解二選一即可。第二處是XML文件的存放位置如果你把Mapper XML放在java目錄下需要在pom.xml里加配置把xml文件打包進(jìn)去否則構(gòu)建后運(yùn)行就會(huì)報(bào)“Invalid bound statement (not found)”這個(gè)錯(cuò)在部署時(shí)非常常見。build resources resource directorysrc/main/java/directory includes include**/*.xml/include /includes /resource /resources /build如果XML放在src/main/resources目錄下的mapper子目錄則要在application.yml里配置mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.fitness.entity configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImplmap-underscore-to-camel-case這個(gè)配置強(qiáng)烈建議開啟這樣數(shù)據(jù)庫(kù)的create_time字段就能自動(dòng)映射到實(shí)體的createTime屬性少寫很多resultMap。2.3.2 動(dòng)態(tài)SQL怎么避免誤更新空字段更新操作是動(dòng)態(tài)SQL最容易出問題的場(chǎng)景。如果用set標(biāo)簽更新用戶信息前端只傳了昵稱結(jié)果把密碼、手機(jī)號(hào)也更新成null了這種事故幾乎每個(gè)新手都遇到過。解決方法是更新接口單獨(dú)設(shè)計(jì)DTO并且使用MyBatis的if標(biāo)簽做非空判斷update idupdateMemberInfo parameterTypecom.example.fitness.dto.MemberUpdateDTO update member set if testheight ! nullheight #{height},/if if testweight ! nullweight #{weight},/if if testbodyFat ! nullbody_fat #{bodyFat},/if if testmemberLevel ! nullmember_level #{memberLevel},/if /set where id #{id} /update這樣前端傳什么字段就更新什么字段不傳的字段保持原狀。要注意set標(biāo)簽會(huì)自動(dòng)處理最后一個(gè)逗號(hào)別畫蛇添足去寫, where。2.3.3 循環(huán)插入用foreach還是單條insert批量添加課程排期、批量導(dǎo)入會(huì)員這類場(chǎng)景很多人會(huì)寫一個(gè)for循環(huán)調(diào)用單條insert數(shù)據(jù)量大了效率就很差。正確做法是用foreach一次批量插入insert idbatchInsertSchedule insert into coach_schedule (coach_id, course_id, start_time, end_time, max_people, create_time) values foreach collectionlist itemitem separator, (#{item.coachId}, #{item.courseId}, #{item.startTime}, #{item.endTime}, #{item.maxPeople}, now()) /foreach /insertMySQL默認(rèn)的max_allowed_packet大小足夠容納幾千條數(shù)據(jù)的批量插入一般不用擔(dān)心超出限制。加rewriteBatchedStatementstrue到數(shù)據(jù)庫(kù)連接串還能進(jìn)一步提升批量執(zhí)行效率。2.4 JWT登錄鑒權(quán)的完整邏輯登錄鑒權(quán)是前后端分離項(xiàng)目的核心環(huán)節(jié)。因?yàn)榻涌谑菬o(wú)狀態(tài)的所以需要用一種機(jī)制讓服務(wù)端能識(shí)別“你是誰(shuí)”。我用的是JWT方案流程是這樣用戶登錄后后端校驗(yàn)用戶名密碼校驗(yàn)通過就生成一個(gè)JWT令牌返回給前端。這個(gè)令牌由三部分組成Header、Payload、Signature核心信息放在Payload里。我習(xí)慣把userId和role兩個(gè)字段放進(jìn)去這樣后續(xù)接口里從token中解析出userId就知道當(dāng)前請(qǐng)求是哪個(gè)用戶在操作。令牌設(shè)置兩小時(shí)過期前端在axios攔截器里發(fā)現(xiàn)返回401就跳回登錄頁(yè)。生成JWT的核心代碼邏輯參考String token Jwts.builder() .setSubject(user.getUsername()) .claim(userId, user.getId()) .claim(role, user.getRole()) .setExpiration(new Date(System.currentTimeMillis() 2 * 60 * 60 * 1000)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact();有了令牌攔截器在SpringBoot中通過實(shí)現(xiàn)HandlerInterceptor接口在preHandle方法里校驗(yàn)token。要記得把注冊(cè)登錄接口排除在攔截范圍外配置攔截路徑時(shí)用excludePathPatterns把公開接口放行。這個(gè)過程中最大的坑是前后端對(duì)token的命名要完全一致。有的項(xiàng)目后端返回token字段前端卻存在access_token里結(jié)果所有請(qǐng)求都帶不上token全是401。盡量在一開始就約定好response里的字段叫token前端storage里存的key也叫fitness_token。注意密碼存儲(chǔ)絕對(duì)不能明文。使用BCrypt加密有兩點(diǎn)好處一是每個(gè)用戶生成的哈希值不同即使密碼相同存庫(kù)結(jié)果也不同二是BCrypt自帶鹽值暴力碰撞成本極高。Spring Security的BCryptPasswordEncoder可以直接單獨(dú)拿來(lái)用不用引入完整的安全框架。3. 前端Vue工程搭建與聯(lián)調(diào)細(xì)節(jié)3.1 初始化一個(gè)Vue項(xiàng)目并配好路由搭建前端工程有兩個(gè)方式Vue CLI和Vite。新項(xiàng)目我更推薦Vite構(gòu)建速度快開發(fā)體驗(yàn)好。初始化命令npm create vitelatest fitness-admin -- --template vue創(chuàng)建完成后按照需要安裝路由、狀態(tài)管理和HTTP庫(kù)npm install vue-router4 pinia axios element-plusElement Plus是這套系統(tǒng)里非常好用的UI組件庫(kù)表格、表單、對(duì)話框、分頁(yè)這些后臺(tái)管理常用的組件都封裝好了。整套后臺(tái)頁(yè)面如果不用組件庫(kù)手寫樣式的工作量至少翻三倍。路由設(shè)計(jì)是前端最需要提前規(guī)劃的部分。我習(xí)慣在路由配置文件里把整個(gè)布局拆成兩層外層是Layout包含側(cè)邊欄和頂欄內(nèi)層是具體頁(yè)面。所有需要登錄的頁(yè)面都放在一個(gè)父路由下通過路由守衛(wèi)控制訪問權(quán)限。// src/router/index.js const routes [ { path: /login, component: Login }, { path: /, component: Layout, redirect: /dashboard, children: [ { path: dashboard, name: Dashboard, component: Dashboard }, { path: course, name: Course, component: CourseList, meta: { roles: [1, 2] } }, { path: member, name: Member, component: MemberList, meta: { roles: [0] } } ] } ]路由守衛(wèi)的作用是在跳轉(zhuǎn)前檢查登錄態(tài)和角色權(quán)限。用戶沒登錄去訪問需要鑒權(quán)的頁(yè)面直接路由跳轉(zhuǎn)到登錄頁(yè)并帶上redirect參數(shù)登錄成功后跳回原來(lái)想去的頁(yè)面router.beforeEach((to, from, next) { const token localStorage.getItem(fitness_token) if (!token to.path ! /login) { next({ path: /login, query: { redirect: to.fullPath } }) } else { next() } })3.2 axios封裝與跨域處理axios封裝做得好不好直接決定后面聯(lián)調(diào)是否痛苦。我在項(xiàng)目里封裝了一個(gè)request模塊統(tǒng)一處理三件事請(qǐng)求頭自動(dòng)帶上token、響應(yīng)數(shù)據(jù)統(tǒng)一解包、錯(cuò)誤提示統(tǒng)一彈窗。// src/utils/request.js import axios from axios const service axios.create({ baseURL: /api, timeout: 10000 }) service.interceptors.request.use(config { const token localStorage.getItem(fitness_token) if (token) { config.headers[token] token } return config }) service.interceptors.response.use( response { const res response.data if (res.code 401) { localStorage.removeItem(fitness_token) window.location.href /login return Promise.reject(new Error(未登錄或登錄已過期)) } return res }, error { ElMessage.error(error.response?.data?.message || 網(wǎng)絡(luò)異常請(qǐng)稍后重試) return Promise.reject(error) } )開發(fā)環(huán)境直接請(qǐng)求后端地址會(huì)遇到跨域問題?？缬虻谋举|(zhì)是瀏覽器的同源策略前端跑在8080端口后端跑在8081端口兩者源不同瀏覽器就會(huì)攔截響應(yīng)數(shù)據(jù)。開發(fā)環(huán)境下最簡(jiǎn)單的方案是在vite.config.js里配置代理讓前端請(qǐng)求走自己的域名然后轉(zhuǎn)發(fā)到后端// vite.config.js export default defineConfig({ server: { port: 3000, proxy: { /api: { target: http://localhost:8081, changeOrigin: true, rewrite: path path.replace(/^\/api/, ) } } } })這樣前端代碼里請(qǐng)求/api/course/list實(shí)際轉(zhuǎn)發(fā)到后端的是http://localhost:8081/course/list。生產(chǎn)環(huán)境部署時(shí)同樣用Nginx處理轉(zhuǎn)發(fā)原理是一樣的。3.3 頁(yè)面開發(fā)時(shí)如何高效對(duì)接接口頁(yè)面聯(lián)調(diào)最怕的就是沒有接口文檔全靠猜。建議后端在寫接口時(shí)順手把參數(shù)和返回值整理清楚。前端拿到接口先別急著寫頁(yè)面花10分鐘把接口返回的數(shù)據(jù)結(jié)構(gòu)看明白再設(shè)計(jì)表格列和表單字段效率會(huì)高很多。以課程管理為例前端調(diào)用課程列表接口后數(shù)據(jù)結(jié)構(gòu)一般是這樣的{ code: 200, message: success, data: { total: 35, rows: [ { id: 1, name: 燃脂操, category: 團(tuán)操, price: 29.9, status: 1, createTime: 2024-05-12 10:30:00 } ] } }前端拿到這個(gè)結(jié)構(gòu)后Element Plus的Table組件直接用prop綁定字段名就能渲染。要注意時(shí)間字段后端返回的是字符串還是時(shí)間戳如果返回的是2024-05-12 10:30:00這樣的格式前端可以直接展示如果是時(shí)間戳需要做一次格式化轉(zhuǎn)換。我踩過的坑是后端把時(shí)間字段統(tǒng)一做成了字符串拼接導(dǎo)致日期排序完全亂掉。后面改成返回時(shí)間戳前端再統(tǒng)一格式化問題就解決了。建議后端時(shí)間格式約定成ISO字符串或者時(shí)間戳并且保證項(xiàng)目中所有接口風(fēng)格一致否則前端處理成本很高。3.4 關(guān)鍵業(yè)務(wù)頁(yè)面怎么設(shè)計(jì)和實(shí)現(xiàn)課程預(yù)約是核心頁(yè)面用戶看到的是一個(gè)課程卡片列表加預(yù)約按鈕。點(diǎn)擊預(yù)約按鈕后前端彈出一個(gè)對(duì)話框展示課程詳情包括上課時(shí)間、授課教練、可約人數(shù)、價(jià)格。用戶確認(rèn)后調(diào)用預(yù)約接口后端校驗(yàn)是否已滿、時(shí)間是否沖突、用戶是否重復(fù)預(yù)約?？紤]到真實(shí)場(chǎng)景里用戶可能一次預(yù)約多節(jié)課課程卡片上要標(biāo)注當(dāng)前剩余名額。剩余名額怎么計(jì)算每次預(yù)約成功時(shí)減少名額取消預(yù)約時(shí)增加名額同時(shí)預(yù)約時(shí)再校驗(yàn)一次余量。這個(gè)邏輯聽起來(lái)簡(jiǎn)單但并發(fā)場(chǎng)景下需要注意兩個(gè)人同時(shí)約最后一個(gè)名額如果先查詢?cè)俑戮蜁?huì)超賣。穩(wěn)妥做法是在更新時(shí)帶上條件update coach_schedule set booked_count booked_count 1 where id #{scheduleId} and booked_count max_people受影響行數(shù)為1表示預(yù)約成功為0表示名額已滿。這種原子操作比先查再更靠譜得多。教練端頁(yè)面主要展示課程日歷每個(gè)教練可以看到自己的工作安排。這個(gè)功能其實(shí)就是把某個(gè)教練的排課表查詢出來(lái)按日期分組顯示。前端用日歷組件渲染對(duì)應(yīng)日期顯示課程信息。管理端頁(yè)面是重頭戲會(huì)員列表需要支持條件搜索和分頁(yè)課程管理需要支持上下架操作訂單管理需要導(dǎo)出Excel營(yíng)收統(tǒng)計(jì)需要展示圖表。建議這些頁(yè)面按模塊獨(dú)立開發(fā)先列表再表單再操作按鈕逐步完善。實(shí)操心得開發(fā)順序有個(gè)技巧。先做后端接口用Postman驗(yàn)證通過后再寫前端頁(yè)面或者先定好接口用Mock數(shù)據(jù)跑通前端再對(duì)接真實(shí)后端。千萬(wàn)別兩邊同時(shí)開工邊寫邊改不然兩邊互相等排錯(cuò)時(shí)也搞不清問題在前端還是后端。4. 環(huán)境準(zhǔn)備與項(xiàng)目部署全流程4.1 本地開發(fā)環(huán)境需要裝哪些東西很多新手卡在環(huán)境配置上這里列一個(gè)完整的清單。JDK推薦裝JDK 8或者JDK 11。選JDK 8的原因是穩(wěn)定SpringBoot 2.x系列完全兼容網(wǎng)上搜問題也容易找到答案。JDK 17也不是不行但要確認(rèn)和SpringBoot版本兼容SpringBoot 2.x對(duì)JDK 17的支持會(huì)遇到模塊化限制建議直接用JDK 8省心。Maven裝最新版或者3.6都可以重點(diǎn)是要在IDEA里把Maven的settings.xml指到國(guó)內(nèi)鏡像否則下載依賴慢得讓人想放棄。鏡像我這里就不寫具體地址了你在搜索引擎搜“Maven國(guó)內(nèi)鏡像”就有很多現(xiàn)成的配置。MySQL建議裝5.7或者8.0。安裝時(shí)要注意編碼設(shè)置成utf8mb4數(shù)據(jù)庫(kù)排序規(guī)則選utf8mb4_general_ci。用utf8mb4而不是utf8的原因很簡(jiǎn)單utf8mb4能存儲(chǔ)emoji和生僻字utf8存不了。連接串里再加一行參數(shù)保證高版本MySQL的SSL連接不會(huì)報(bào)錯(cuò)。Node.js裝16.20 LTS或者18 LTS版本都可以Vite 4要求Node 14.18以上。安裝完以后把npm的registry切換成淘寶源執(zhí)行命令npm config set registry https://registry.npmmirror.com就行。這些環(huán)境裝完后建議先各自驗(yàn)證一遍JDK用java -versionMaven用mvn -vNode用node -vMySQL用mysql -u root -p登錄測(cè)試。確認(rèn)都沒問題再開始跑項(xiàng)目不然環(huán)境出問題會(huì)干擾你判斷項(xiàng)目本身的Bug。4.2 前端打包與Nginx部署Vue項(xiàng)目開發(fā)完成后構(gòu)建生產(chǎn)產(chǎn)物npm run build構(gòu)建完會(huì)在項(xiàng)目目錄下生成dist文件夾里面就是打包好的靜態(tài)文件。把dist文件夾里的內(nèi)容復(fù)制到Nginx的html目錄然后配置Nginx。配置Nginx做兩件事托管靜態(tài)文件反向代理API請(qǐng)求。先看一個(gè)最小可用的配置server { listen 80; server_name your-domain.com; root /usr/share/nginx/html/fitness; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8081/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }try_files $uri $uri/ /index.html;這行是前端路由模式的關(guān)鍵配置。Vue Router默認(rèn)使用history模式頁(yè)面地址看起來(lái)是/course/list這種真實(shí)路徑。如果刷新頁(yè)面Nginx會(huì)根據(jù)路徑找文件找不到就返回404。加上這行配置后所有請(qǐng)求兜底返回index.html再由Vue路由接管頁(yè)面就正常了。location /api/塊把前端發(fā)往/api/的請(qǐng)求反向代理到后端服務(wù)。注意proxy_pass http://127.0.0.1:8081/;末尾的斜杠作用是把/api前綴去掉再轉(zhuǎn)發(fā)保證后端收到的地址和本地開發(fā)時(shí)一致。前端有兩種路由模式剛才說(shuō)的history模式在部署時(shí)需要Nginx配合還有一種hash模式URL地址里帶#號(hào)部署簡(jiǎn)單但不好看。如果你用的是hash模式不需要try_files那行也能正常工作。什么場(chǎng)景用哪種如果域名是給外部訪問的正式項(xiàng)目建議history模式配好Nginx如果是本地演示或者測(cè)試環(huán)境hash模式省事不折騰。4.3 后端工程打包與運(yùn)行全流程后端SpringBoot項(xiàng)目打包前先確認(rèn)application-prod.yml配置正確。數(shù)據(jù)庫(kù)地址、用戶名、密碼換成了生產(chǎn)環(huán)境的值日志輸出級(jí)別調(diào)整成info去掉打印SQL的配置。然后執(zhí)行Maven打包命令mvn clean package -Dmaven.test.skiptrue打包成功后在target目錄下會(huì)生成一個(gè)xxx.jar文件。把這個(gè)jar上傳到服務(wù)器運(yùn)行指令java -jar fitness-server.jar默認(rèn)是在前臺(tái)運(yùn)行關(guān)掉終端服務(wù)就停了。正式環(huán)境用后臺(tái)運(yùn)行方式nohup java -jar fitness-server.jar fitness.log 21 日志輸出重定向到fitness.log文件里排查問題的時(shí)候直接看這個(gè)文件。nohup的意思是忽略掛斷信號(hào)加上符號(hào)讓進(jìn)程在后臺(tái)運(yùn)行。要停止服務(wù)先查進(jìn)程號(hào)再殺掉ps -ef | grep fitness-server kill -9 pid繼承標(biāo)題里提到的“Tomcat部署前后端分離項(xiàng)目”這里多說(shuō)一句。如果是用SpringBoot內(nèi)嵌Tomcat打成jar直接運(yùn)行就行壓根不用單獨(dú)裝Tomcat。如果你自己用SpringBoot打的是war包就需要裝一個(gè)外置Tomcat把war包丟到webapps目錄下啟動(dòng)Tomcat后項(xiàng)目自動(dòng)解壓部署。但既然用SpringBoot了沒必要退回傳統(tǒng)做法內(nèi)置Tomcat的jar包部署方式更簡(jiǎn)單也更好維護(hù)。4.4 服務(wù)器端運(yùn)行環(huán)境的快速搭建在Linux服務(wù)器上搭建整個(gè)運(yùn)行環(huán)境核心要做這么幾件事# 安裝JDK 8以通用方式為例 yum install java-1.8.0-openjdk # 檢查安裝 java -version # 安裝Nginx yum install nginx systemctl start nginx # 安裝MySQL yum install mysql-server systemctl start mysqld # 設(shè)置MySQL開機(jī)自啟 systemctl enable mysqld # 導(dǎo)入項(xiàng)目數(shù)據(jù)庫(kù) mysql -u root -p fitness.sqlJDK、Nginx、MySQL都裝好并啟動(dòng)后按照前面說(shuō)的方法啟動(dòng)后端jar再把前端dist目錄放到Nginx的站點(diǎn)目錄整個(gè)系統(tǒng)就通了。驗(yàn)證方式很簡(jiǎn)單瀏覽器訪問服務(wù)器IP地址看到登錄頁(yè)面說(shuō)明前端通了輸入賬號(hào)密碼能登錄說(shuō)明前后端聯(lián)調(diào)沒問題。有一個(gè)經(jīng)常被忽視的點(diǎn)服務(wù)器的防火墻端口。如果前端頁(yè)面能打開但接口請(qǐng)求不通十有八九是8081端口沒開或者說(shuō)Nginx轉(zhuǎn)發(fā)沒配好。檢查端口監(jiān)聽情況用命令netstat -tlnp | grep 8081如果是8080和8081這類非80端口還需確認(rèn)安全組規(guī)則里放行了對(duì)應(yīng)端口。4.5 演示環(huán)境的完整驗(yàn)證清單項(xiàng)目部署完成后不能只看頁(yè)面能打開就算交付。我會(huì)按業(yè)務(wù)主流程完整走一遍確認(rèn)每個(gè)模塊都在真實(shí)環(huán)境跑通。驗(yàn)證清單大概是這樣的注冊(cè)一個(gè)新會(huì)員看看登錄后角色是否正確管理員創(chuàng)建課程、添加教練排課會(huì)員瀏覽課程列表預(yù)約一門課程教練端查看預(yù)約名單和排課表管理員查看預(yù)約統(tǒng)計(jì)和營(yíng)收訂單會(huì)員取消預(yù)約后名額是否正常釋放所有頁(yè)面刷新后不出現(xiàn)404退出登錄后訪問受限頁(yè)面自動(dòng)跳登錄頁(yè)每個(gè)環(huán)節(jié)都走一遍發(fā)現(xiàn)問題就修掉確認(rèn)全通后才能把這個(gè)項(xiàng)目交付出去。很多人項(xiàng)目做完沒驗(yàn)證就直接提交了答辯現(xiàn)場(chǎng)演示時(shí)突然崩了那場(chǎng)面確實(shí)是災(zāi)難。注意部署到服務(wù)器和本地環(huán)境是有差異的。本地跑通的項(xiàng)目到服務(wù)器上很可能因?yàn)槟夸浡窂健?shù)據(jù)庫(kù)名、端口占用等原因出問題務(wù)必按上面的清單在服務(wù)器環(huán)境完整驗(yàn)證一遍。不要想當(dāng)然認(rèn)為“本地通了服務(wù)器肯定也通”。5. 常見問題與排查技巧實(shí)錄5.1 后端啟動(dòng)失敗的幾個(gè)高頻坑啟動(dòng)后端口被占用是出現(xiàn)頻率最高的問題。有時(shí)候是上次的進(jìn)程沒殺掉有時(shí)候是另一個(gè)項(xiàng)目占用了同一端口。排查辦法lsof -i :8081找到占用端口的進(jìn)程號(hào)殺完之后再重新啟動(dòng)。如果8081端口被系統(tǒng)進(jìn)程占用了最簡(jiǎn)單的辦法是換一個(gè)端口在application.yml里改server.port同時(shí)把Nginx的代理地址同步改掉。數(shù)據(jù)庫(kù)連接失敗也比較常見SpringBoot啟動(dòng)時(shí)報(bào)錯(cuò)Communications link failure。絕大多數(shù)原因是MySQL沒啟動(dòng)、密碼錯(cuò)誤、或者連接串寫錯(cuò)。逐個(gè)排查# 確認(rèn)MySQL在運(yùn)行 systemctl status mysqld # 確認(rèn)能登錄MySQL mysql -u root -p # 確認(rèn)連接串里的端口號(hào) mysql -h localhost -P 3306 -u root -pMySQL 8.0啟動(dòng)出錯(cuò)還要檢查連接串里有沒有加useSSLfalse。默認(rèn)會(huì)啟用SSL連接而本地MySQL實(shí)例沒有正確配置SSL證書時(shí)就會(huì)報(bào)錯(cuò)。連接串這樣寫保證沒問題url: jdbc:mysql://localhost:3306/fitness?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai5.2 MyBatis相關(guān)報(bào)錯(cuò)與排查“Invalid bound statement (not found)”是我在后端項(xiàng)目里遇到頻率最高的報(bào)錯(cuò)。這個(gè)報(bào)錯(cuò)的意思是Mapper接口的方法和XML里對(duì)應(yīng)的id對(duì)不上或者XML文件根本沒被加載進(jìn)來(lái)。排查順序如下確認(rèn)Mapper接口方法名和XML的id完全一致包括大小寫確認(rèn)XML文件被Maven打進(jìn)了jar包檢查target目錄下有沒有對(duì)應(yīng)的XML文件確認(rèn)application.yml里的mapper-locations路徑配置正確“TooManyResultsException”也偶爾碰到意思是查詢結(jié)果有多條記錄但方法返回值寫的單對(duì)象。這個(gè)錯(cuò)誤一般是SQL寫的條件不準(zhǔn)查出了多條記錄排查SQL條件和數(shù)據(jù)或者改方法返回值為L(zhǎng)ist。分頁(yè)時(shí)的坑也要說(shuō)一下。如果用了PageHelper分頁(yè)插件注意查詢結(jié)果的類型是PageInfo要用new PageInfo(list)拿到總條數(shù)直接list.getTotal()會(huì)提示找不到getTotal方法。另外PageHelper的分頁(yè)參數(shù)只在緊跟著的下一條SQL生效想分頁(yè)哪個(gè)查詢就要在它前面緊貼著設(shè)置分頁(yè)中間不能夾雜其他SQL。5.3 前端常見報(bào)錯(cuò)與解決思路前端代碼運(yùn)行報(bào)錯(cuò)最多的地方首推跨域。報(bào)錯(cuò)信息通常長(zhǎng)這樣Access to XMLHttpRequest at http://localhost:8081/... from origin http://localhost:3000 has been blocked by CORS policy。出現(xiàn)這個(gè)錯(cuò)誤第一個(gè)要確認(rèn)的是你有沒有走代理。如果你在代碼里把baseURL寫死了http://localhost:8081那請(qǐng)求根本沒有走vite代理而是瀏覽器直接跨域調(diào)用代理配置就白寫了。正確做法是baseURL寫/api由代理轉(zhuǎn)發(fā)到后端。前端另一個(gè)常見問題是打包后頁(yè)面白屏控制臺(tái)報(bào)錯(cuò)Failed to fetch dynamically imported module。這個(gè)一般是路由懶加載的文件路徑寫錯(cuò)了或者構(gòu)建產(chǎn)物沒上傳完整。先看瀏覽器Network面板里面哪個(gè)js文件404了再對(duì)著修正路徑或者重新構(gòu)建一次再上傳。Vue 3 Element Plus還有一個(gè)經(jīng)典問題就是圖標(biāo)點(diǎn)擊不顯示。Element Plus從1.x版本開始圖標(biāo)庫(kù)單獨(dú)拆成了element-plus/icons-vue包你沒有安裝或者沒有全局注冊(cè)圖標(biāo)就是空白的。在main.js里面注冊(cè)import * as ElementPlusIconsVue from element-plus/icons-vue for (const [key, component] of Object.entries(ElementPlusIconsVue)) { app.component(key, component) }5.4 登錄后跳回登錄頁(yè)的排查思路前后端分離項(xiàng)目里“點(diǎn)擊按鈕后莫名其妙跳回登錄頁(yè)”也是高頻問題。先判斷是不是所有請(qǐng)求都跳登錄頁(yè)還是個(gè)別接口跳。如果所有請(qǐng)求都跳大概率是token寫入不一致。比如后端要求請(qǐng)求頭參數(shù)叫token前端卻用Authorization去傳后端解析不到統(tǒng)一返回401路由守衛(wèi)就把頁(yè)面重定向到登錄頁(yè)了?；蛘遲oken過期也有同樣效果。如果是個(gè)別接口跳那就是后端某些接口的攔截配置有問題。比如你登錄接口動(dòng)態(tài)更新用戶信息后沒把新token返回給前端用舊token訪問新接口時(shí)就過期了?；蛘吣硞€(gè)接口路徑不小心被排除在攔截范圍外了導(dǎo)致該鑒權(quán)的接口沒有鑒權(quán)。排查這類問題最快的辦法是把瀏覽器Network面板打開看接口返回的狀態(tài)碼和響應(yīng)體。是401還是403響應(yīng)信息提示是“未登錄”還是“無(wú)權(quán)限”看準(zhǔn)了再動(dòng)手改不要瞎調(diào)代碼。5.5 部署環(huán)節(jié)設(shè)計(jì)一個(gè)快速自查表結(jié)合上述經(jīng)驗(yàn)整理一張排查速查表按順序檢查能解決90%的部署問題?，F(xiàn)象可能原因排查命令/操作頁(yè)面打不開Nginx未啟動(dòng)或配置錯(cuò)誤systemctl status nginxnginx -t 檢查配置前端頁(yè)面能開但接口404反向代理路徑配置錯(cuò)誤檢查location /api塊的proxy_pass配置接口請(qǐng)求跨域前端沒走代理直接請(qǐng)求后端檢查baseURL是否為/api瀏覽器Network看請(qǐng)求URL后端啟動(dòng)報(bào)端口被占用端口被其他進(jìn)程占用lsof -i 查看占用進(jìn)程并處理后端啟動(dòng)報(bào)數(shù)據(jù)庫(kù)連接失敗MySQL未啟動(dòng)或密碼錯(cuò)誤systemctl status mysqldmysql -u root -p 測(cè)試登錄登錄后接口401/跳登錄頁(yè)token傳參名稱不一致或過期檢查前端請(qǐng)求攔截器headers配置刷新頁(yè)面404前端路由history模式?jīng)]配try_filesNginx中l(wèi)ocation /增加try_files配置這張表你在部署時(shí)對(duì)照著排查能省下大量查資料的時(shí)間。我自己第一次部署前后端分離項(xiàng)目時(shí)因?yàn)镹ginx沒配try_files所有頁(yè)面刷新都404查了半天才想到是這個(gè)問題。有了這張表后來(lái)再部署就順手多了。結(jié)尾這個(gè)健身俱樂部網(wǎng)站系統(tǒng)整套做下來(lái)覆蓋了前后端分離開發(fā)的全部核心環(huán)節(jié)業(yè)務(wù)建模、數(shù)據(jù)庫(kù)設(shè)計(jì)、RESTful API開發(fā)、JWT鑒權(quán)、Vue組件化開發(fā)、Nginx部署。如果你正在找畢業(yè)設(shè)計(jì)選題或者想豐富項(xiàng)目經(jīng)歷按這套思路把代碼寫透收獲會(huì)遠(yuǎn)遠(yuǎn)超過看一遍教程。個(gè)人經(jīng)驗(yàn)中最深的體會(huì)是環(huán)境準(zhǔn)備和部署環(huán)節(jié)看似不起眼但坑最多。寧可開工前多花半天把JDK、MySQL、Node、Nginx這些環(huán)境都弄利索也不要寫到一半再來(lái)查環(huán)境問題那樣非常打斷思路。另一個(gè)建議是保留一份部署自查文檔每次換機(jī)器部署都照著跑出了問題時(shí)排查效率會(huì)高很多。最后再分享一個(gè)實(shí)用的小技巧整個(gè)系統(tǒng)跑通之后建議用Postman把主要接口整理成一份接口集合導(dǎo)出成JSON存到項(xiàng)目倉(cāng)庫(kù)里。后面不管是自己重構(gòu)還是別人接手都能快速看懂接口定義不用費(fèi)力去代碼里翻。項(xiàng)目交付的世界里“文檔完善”這件事的分?jǐn)?shù)占比可能比你想象中高很多。