做了這么多年軟件開發(fā)帶過的應屆生和實習生也不少每次到畢設季總有人拿著一堆某某管理系統(tǒng)的題目來問我哪個好做。我的答案一直很明確別選那種名字里只有信息管理四個字的要選業(yè)務場景具體、流程閉環(huán)的題目。面向高校的電動車租賃服務業(yè)務系統(tǒng)這種題目就是典型的畢設安全牌——校園場景夠真實、業(yè)務鏈條夠完整、技術點覆蓋夠全面用 Java SpringBoot 做技術底座前后端該有的東西一樣不缺工作量可大可小答辯的時候還有故事可講。這篇文章我打算按做畢設的真實順序來寫從選題判斷、需求梳理、技術選型到數(shù)據(jù)庫設計、核心代碼實現(xiàn)再到最后答辯演示怎么準備。全程會帶上我自己實際開發(fā)中踩過的坑和總結的經(jīng)驗尤其是SpringBoot版本、MyBatis Plus代碼生成這些容易卡住人的細節(jié)希望幫正在做類似題目的同學少走幾個月的彎路。不管你是剛拿到題目還沒頭緒還是已經(jīng)寫完一半卡在某個模塊這篇都能給你一些能直接落地的參考。1. 選題定調為什么高校電動車租賃系統(tǒng)是道安全牌1.1 業(yè)務場景真實需求來源不牽強先想一個問題你的畢設題目是XX管理系統(tǒng)還是XX業(yè)務系統(tǒng)這兩者在評委眼里的差別非常大。前者常常給人感覺是拿一個通用模板套了個名字頁面是員工管理、部門管理、公告管理換個標題就能當另一個題目交差。而校園電動車租借服務這個業(yè)務本身就有非常具體的現(xiàn)實場景——校區(qū)面積大、學生出行靠電動車、車輛需要調度和維護、租借需要計費和押金管理。我第一次接觸這個題目是在幫一個學生做開題報告的時候當時我們聊到一個細節(jié)高校電動車租賃和共享單車不同它是有固定取還車點、有押金、有小時/天兩種計價模式的。這很小但恰恰說明這個題目不是憑空捏造的它有真實的運營痛點可以挖。有痛點就有需求分析可寫有需求分析開題報告、中期檢查、論文正文才不會空洞。1.2 工作量可控邊界清晰畢設最怕什么最怕題目大到做不完。比如基于大數(shù)據(jù)的校園行為分析系統(tǒng)光數(shù)據(jù)采集就夠你喝一壺。而電動車租賃系統(tǒng)的核心業(yè)務鏈條非常清晰用戶選車、下單、取車、騎行、還車、結算管理員負責車輛上下架、處理訂單異常。這是一個可以完整跑通的閉環(huán)。以SpringBoot做后端前端不管是模板渲染還是Vue分離主體功能大概就這么幾塊用戶端注冊登錄、車輛瀏覽、租車下單、還車結算、訂單查詢、個人中心管理端車輛管理、用戶管理、訂單管理、計費規(guī)則配置、數(shù)據(jù)統(tǒng)計支撐功能登錄鑒權、異常訂單處理、租車時間校驗這套功能量對一個人來說大約一個半月到兩個月可以做得比較完整。你還能在這個基礎上做適度擴展比如車輛定位、超時提醒、Excel報表導出作為論文里的創(chuàng)新點和亮點而不是一上來就鋪一個大架子最后實現(xiàn)不了。1.3 答辯場上能講出業(yè)務感這一點容易被忽略。答辯的時候評委老師一天要聽幾十個題目記憶點都在你的業(yè)務細節(jié)上。我這個系統(tǒng)里有三個角色管理員、調度員、學生用戶調度員可以對異常車輛進行下架操作同時系統(tǒng)會自動生成一條維修記錄——這種話一出口評委就知道你是真做過需求分析不是在背概念。而且電動車租賃自帶兩個可深挖的話題一是計費規(guī)則怎么設計才合理二是并發(fā)場景下車輛被重復租借怎么辦。這兩個問題我后面會專門寫都是答辯必問的高頻點。2. 需求邊界梳理三類角色、兩條核心流程、一張狀態(tài)機2.1 角色與權限設計做系統(tǒng)之前先畫角色越簡單越好不推薦一上來就搞RBAC權限模型畢設項目用它屬于過度設計。我建議按三類角色去劃分學生/普通用戶瀏覽車輛、租車、還車、查看賬單、充值押金運營管理員車輛信息維護、審核處理訂單、配置計費參數(shù)、查看運營統(tǒng)計系統(tǒng)管理員在運營管理員基礎上增加用戶賬戶管理、菜單權限管理這一層量力而行在SpringBoot里可以用攔截器加注解的方式控制接口權限。我自己的做法是定義一個枚舉角色配合HandlerInterceptor做登錄態(tài)攔截然后對需要管理權限的路徑加一個角色校驗代碼量不大效果卻很清楚。2.2 核心業(yè)務流程整個系統(tǒng)的業(yè)務主干有兩條所有的表和接口都應該圍著它們轉用戶租車流程用戶登錄 - 瀏覽可用車輛 - 選擇車輛并提交租車訂單 - 系統(tǒng)校驗車輛狀態(tài)和用戶押金 - 凍結車輛狀態(tài)改為租借中 - 用戶取車 - 騎行 - 用戶還車 - 系統(tǒng)計算費用 - 扣除費用并解凍車輛 - 訂單完成。車輛管理流程管理員新增車輛 - 車輛上架可租 - 用戶租用 - 車輛歸還 - 管理員檢查車況 - 標記維修/繼續(xù)上架 - 維修完成后重新上架。這兩條流程有一個共同的靈魂車型和訂單的狀態(tài)流轉必須嚴格一致。租車就是車從空閑變租出還車就是車從租出變空閑中間任何一步斷掉整個系統(tǒng)就會出現(xiàn)臟數(shù)據(jù)。我的建議是寫代碼之前先用Excel或者手畫一張狀態(tài)表把所有狀態(tài)遷移路徑列出來再動手。2.3 訂單狀態(tài)機系統(tǒng)的定海神針這里不推薦用Mermaid畫復雜的圖但我強烈建議用一張狀態(tài)表把邏輯定死它可以作為論文里的關鍵圖或者表格出現(xiàn)同時也是你寫Service層代碼時的依據(jù)。訂單狀態(tài)含義可跳轉狀態(tài)觸發(fā)動作待取車已下單并凍結車輛等待用戶取車已取消、騎行中支付押金后生成訂單騎行中用戶已取車正在使用待還車、異常掃碼或點擊取車待還車用戶已發(fā)起還車等待管理員確認已完成、異常上傳還車信息已完成費用已結算流程結束無系統(tǒng)自動結算已取消用戶取消或超時未取車無用戶主動取消/定時任務異常車輛損壞、爭議訂單已完成、已退款管理員介入這個狀態(tài)機我在兩個不同的項目里都用過事實證明它是整個開發(fā)過程中省時間最多的設計。因為很多時候你糾結的不是怎么寫一個還車接口而是一個騎行中的訂單能不能被管理員直接關閉狀態(tài)表把這類問題提前回答了。2.4 功能清單哪些必做哪些量力而行我一般給學生的建議是把功能分成底線功能和加分功能。底線功能要保證流程閉環(huán)注冊登錄、車輛列表與詳情、租車下單、還車結算、訂單查詢、后臺車輛管理、后臺訂單管理、后臺用戶管理。沒有這些系統(tǒng)不成立。加分功能看時間和能力地圖展示車輛位置、掃碼租車、短信通知、微信支付模擬、押金充值、報表統(tǒng)計、定時任務自動取消超時未取車的訂單。其中我特別推薦定時任務超時訂單處理技術含量不高但業(yè)務價值明顯答辯時很加分。3. 技術選型的現(xiàn)實邏輯SpringBoot打底剩下的一樣樣說清3.1 SpringBoot版本怎么選別跟風升太高我看到系統(tǒng)提示里有一個熱搜詞是springboot版本太高這可能是我這個回答里最想展開的地方。網(wǎng)上很多教程一上來就是SpringBoot 3.x、JDK 17看著很新但對畢設項目來說這往往是災難的開始。問題出在哪SpringBoot 3.0是一次大版本重構底層從javax命名空間遷移到了jakarta很多老教程里的import javax.servlet.xxx在項目里會直接報錯。另外MyBatis Plus在早期對SpringBoot 3的適配并不完美你搜到的很多解決方案還是針對SpringBoot 2.x的照搬過來就是連環(huán)坑。我的建議是如果不是做新技術調研類的題目畢設老老實實用SpringBoot 2.7.x JDK 8 MyBatis Plus 3.5.x。這套組合穩(wěn)定到什么程度幾乎所有問題都有現(xiàn)成的答案網(wǎng)上的教程、論壇帖子、CSDN博客搜一個準一個。你花在調試上的時間會少很多多做點業(yè)務功能不香嗎提示如果你的學校規(guī)定必須用最新版本那也可以上SpringBoot 3但要做好心理準備——依賴要選兼容版本代碼里所有javax要換成jakarta遇到報錯別直接復制老代碼先看異常信息里提示的包名。3.2 ORM選型MyBatis Plus是畢設最優(yōu)解關于數(shù)據(jù)訪問層我這些年給畢設同學推薦得最多的就是MyBatis Plus幾乎沒有之一的說法。我知道有人會說Spring Data JPA也挺好但對畢設場景來說MyBatis Plus有它不可替代的優(yōu)勢單表CRUD不用寫XML和SQLBaseMapper接口直接給到selectById、insert、updateById這些現(xiàn)成方法LambdaQueryWrapper寫條件查詢非常自然比如查狀態(tài)為空閑并且時租價小于3元的車一行代碼的事分頁插件好用配合Page對象做列表頁幾乎零成本字段自動填充TableField(fill FieldFill.INSERT)能自動幫你填創(chuàng)建時間、更新時間而且它有官方提供的代碼生成器可以從數(shù)據(jù)庫表反向生成實體類、Mapper、Service、Controller配合我們后面講的數(shù)據(jù)庫設計開發(fā)效率能翻倍。3.3 數(shù)據(jù)庫和連接池MySQL搭配Druid數(shù)據(jù)庫選MySQL就夠了5.7或者8.0都行。如果只是想跑通功能不追求生產(chǎn)級配置application.yml里的數(shù)據(jù)源配置可以照下面這種來寫spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/campus_bike?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 你的密碼 type: com.alibaba.druid.pool.DruidDataSource這里要提醒一句URL里務必加上characterEncodingutf8和serverTimezoneAsia/Shanghai。前者解決中文亂碼后者解決MySQL 8.x時區(qū)報錯。這兩個小參數(shù)幾乎每次幫人排查問題都會遇到。3.4 前端方案模板引擎還是前后端分離這是畢設同學問得最多的問題之一。我的判斷標準很簡單看你學校給的評分標準里有沒有前后端分離架構這個明確加分項如果沒有就選Thymeleaf模板引擎。為什么因為Thymeleaf方案整個項目只有一個工程啟動一個SpringBoot應用就能看到完整頁面部署、答辯演示都非常省事。前端頁面放在templates目錄下共用Controller里的ModelAndView渲染對后端思路的同學來說最順手。如果學校明確要求前后端分離那前端可以選Vue3 Element Plus后端只寫RESTful接口。這個方案雖然更貼近真實企業(yè)開發(fā)但工作量至少多出20%而且需要處理跨域問題CORS配置打包后還得考慮前端靜態(tài)資源和后端接口怎么部署在一起對沒有前端基礎的同學是負擔。3.5 項目結構一個標準SpringBoot項目該有的樣子無論是單模塊還是多模塊我建議你至少把包結構按職責分清楚。一個我比較推薦的單模塊結構如下com.campus.bike ├── controller # 接口層用戶端/管理端各自獨立 ├── service # 業(yè)務層訂單、車輛、計費等核心邏輯 ├── mapper # 數(shù)據(jù)訪問層繼承BaseMapper ├── entity # 實體類User, Bike, Order, ... ├── dto # 前端交互對象下單請求、結算結果等 ├── config # 配置類MyBatis Plus分頁、攔截器等 ├── common # 通用工具統(tǒng)一返回結果、異常處理、常量 └── task # 定時任務超時訂單處理包名分層清晰的好處是答辯老師問你這個系統(tǒng)的分層結構你回答的時候邏輯是清清楚楚的而且網(wǎng)上絕大多數(shù)SpringBoot項目的代碼結構都是這個風格遇到問題去搜代碼時貼回來你也能看懂。4. 數(shù)據(jù)庫設計一張訂單表撐起租賃業(yè)務的脊梁4.1 核心表清單數(shù)據(jù)庫設計是整個系統(tǒng)的地基地基沒打好后面寫業(yè)務代碼處處別扭。圍繞租車業(yè)務我設計的核心表主要包括這幾張表名用途關鍵字段t_user用戶/學生信息id, username, password, phone, balance(余額), deposit_statust_bike車輛信息id, bike_no, model, battery_type, range_km, price_hour, price_day, status, locationt_order租借訂單id, order_no, user_id, bike_id, start_time, end_time, pay_amount, statust_payment支付流水id, order_id, user_id, amount, type(押金/租車費), statust_bike_maintain車輛維護記錄id, bike_id, maintain_type, description, cost, status一眼看過去可能覺得表少但對這個業(yè)務來說五到六張表已經(jīng)能覆蓋絕大多數(shù)功能了。你不需要為了顯得系統(tǒng)復雜硬加表表結構合理比表多更重要。4.2 車輛表字段設計里的門道車輛表是業(yè)務數(shù)據(jù)的載體字段設計直接決定你后面功能寫起來順不順。我趟過的一個坑是一開始只設計了車輛型號和狀態(tài)后來做到租車計費才發(fā)現(xiàn)缺少計費單價字段又回去改表加字段還涉及歷史數(shù)據(jù)遷移非常痛苦。一個相對完整的t_bike表字段應該包括bike_no車輛編號對外展示用可以做成條碼/二維碼model和brand品牌型號展示給用戶看的battery_type電池類型鉛酸/鋰電這直接影響續(xù)航和充電策略range_km滿電續(xù)航里程用戶租車前最關心的指標之一price_hour和price_day單小時租金和單天租金獨立字段而不是按天按小時×24打折因為真實業(yè)務里這兩種計價經(jīng)常是獨立設置的status車輛狀態(tài)。我建議用整數(shù)枚舉0空閑、1租借中、2維修中、3已下架location車輛所在校區(qū)分區(qū)比如東區(qū)停車場A區(qū)特別提醒像status這種狀態(tài)字段在Java實體里用Integer類型對應業(yè)務里定義常量或枚舉類盡量不要用字符串因為字符串比較容易寫錯而且數(shù)據(jù)庫索引和查詢的效率也不如整數(shù)。4.3 訂單表計費和狀態(tài)都靠它訂單表是整個系統(tǒng)最核心的表。它的字段設計決定了你計費邏輯、狀態(tài)流轉和后臺查詢是否順暢。核心字段如下order_no業(yè)務訂單號建議用時間戳隨機數(shù)生成不要直接拿數(shù)據(jù)庫自增id當前端訂單號展示user_id和bike_id外鍵關聯(lián)用戶和車輛查詢時關聯(lián)查出用戶名/車牌號start_time和end_time預計租借時間和實際結束時間。一個細節(jié)start_time是用戶真正取車的時間還是下單時間一定要在需求里明確。我偏向于下單即鎖定車輛但計費從取車開始算expect_return_time預計歸還時間用于超時提醒和超時費用計算actual_return_time實際歸還時間rent_type計價類型按小時/按天total_amount實際結算金額status訂單狀態(tài)對應前文的狀態(tài)機設計訂單表的時候應該想清楚一個核心問題一輛車被下單后訂單記錄和車輛狀態(tài)必須同時變化且要放在同一個數(shù)據(jù)庫事務里。這個我在代碼實現(xiàn)部分會再講。4.4 用MyBatis Plus代碼生成器反向生成建表SQL和實體系統(tǒng)熱搜詞里有一條mybatisplus根據(jù)java實體類生成創(chuàng)建表的sql語句這確實是很多人不知道的一個白嫖技巧。MyBatis Plus的代碼生成器mybatis-plus-generator有兩種用法一種是從數(shù)據(jù)庫表生成Java代碼另一種是反過來——你定義實體類它幫你生成建表SQL。畢設場景下我推薦后者因為你先用代碼把實體類的字段和注釋寫好生成SQL后建表表結構的一一對應關系就特別直觀。代碼生成器配置起來也不復雜。核心依賴加上之后用AutoGenerator寫個main方法配置數(shù)據(jù)庫連接、包名、表前綴就能一次性生成Entity、Mapper、Service、Controller四層代碼。省下的時間拿去打磨業(yè)務邏輯它不香嗎提示自動生成的Controller默認是空殼只繼承了簡單的CRUD接口業(yè)務邏輯還需要自己寫。把它當成腳手架用不要指望一個main方法跑完全部功能。4.5 字段類型與設計習慣再分享幾個基礎但重要的設計習慣金額字段一律用DECIMAL(10,2)別用double。這是血淚教訓double的浮點誤差在計費系統(tǒng)里是致命問題雖然畢設數(shù)據(jù)量小不容易暴露但答辯評委如果問到精度問題你答不上來會很尷尬。時間字段統(tǒng)一用datetimeJava側對應LocalDateTime在SpringBoot里用起來非常順手。每個表都要有主鍵id和創(chuàng)建時間、更新時間三個基礎字段。MyBatis Plus的字段自動填充可以幫你搞定后兩個但前提是你建表時預留出來了。邏輯刪除優(yōu)于物理刪除。用戶不小心刪錯一輛車如果沒有回收能力那后臺數(shù)據(jù)就永久錯了。用deleted字段標記簡單又安全。5. 核心功能實現(xiàn)租車、計費、還車這三個地方別寫砸5.1 租車下單并發(fā)校驗跟事務一個都不能少租車功能是系統(tǒng)的門面也是最容易出問題的。我見過不少同學的初版代碼是這么寫的Bike bike bikeMapper.selectById(bikeId); if (bike.getStatus() 0) { bike.setStatus(1); bikeMapper.updateById(bike); // 創(chuàng)建訂單... }這段代碼單看沒毛病但一旦有兩個人同時租同一輛車就會出大問題兩個請求都讀到status 0然后都認為是空閑車先后把狀態(tài)改成租借中結果一輛車被賣出去兩次。這就是經(jīng)典的并發(fā)超賣問題。解決辦法有兩個方向。**方案一數(shù)據(jù)庫層面加條件更新。**把查詢校驗狀態(tài)和更新狀態(tài)合并成一個原子操作UPDATE t_bike SET status 1 WHERE id ? AND status 0只有更新影響的行數(shù)為1時才說明這輛車被你成功搶到了后面的邏輯才繼續(xù)走。這個方案最簡單也能講清楚并發(fā)安全的道理推薦優(yōu)先采用。**方案二使用樂觀鎖。**在實體類上加Version注解更新時MyBatis Plus自動帶上版本號作為條件。這個方案是面試高頻題也容易在畢設中體現(xiàn)技術深度。另外別忘了事務。創(chuàng)建訂單、扣減車輛狀態(tài)、寫支付流水這三步必須在一個Transactional方法里。否則中途任何一個環(huán)節(jié)報錯都會留下訂單已生成但車還是空閑或者車已占用但沒訂單的臟數(shù)據(jù)。5.2 計費模型把按小時/按天/超時算明白計費是租賃系統(tǒng)里最容易被低估難度的模塊。樸素的算法是單價 × 時長但實際業(yè)務里牽扯到幾個邊界條件。我設計過一個相對完整的計費規(guī)則邏輯如下租借類型分為按小時和按天兩種下單時用戶選擇。按小時計費租借時長不足一小時按一小時算超出部分按小時累加。按天計費一天按24小時計算超過24小時按超時處理超時不足一小時按一小時計費。設置單日費用封頂避免用戶一天騎出天價訂單。寫代碼時的核心方法可以這樣組織public BigDecimal calculateAmount(Order order) { Duration duration Duration.between(order.getStartTime(), order.getActualReturnTime()); long minutes duration.toMinutes(); if (order.getRentType() 0) { // 按小時 long hours minutes 0 ? (minutes 59) / 60 : 0; // 向上取整 return bikeService.getHourPrice(order.getBikeId()) .multiply(BigDecimal.valueOf(hours)); } else { // 按天 long days minutes / (24 * 60); long remainMinutes minutes % (24 * 60); BigDecimal amount bikeService.getDayPrice(order.getBikeId()) .multiply(BigDecimal.valueOf(days)); if (remainMinutes 0) { long extraHours (remainMinutes 59) / 60; amount amount.add(bikeService.getHourPrice(order.getBikeId()) .multiply(BigDecimal.valueOf(extraHours))); } return amount; } }這個算法不是最優(yōu)的但把向上取整超時額外計費按天超時這幾個關鍵點都覆蓋到了答辯時可以跟評委講清楚自己的設計思路。注意全程用BigDecimal運算不要用double理由前面已經(jīng)講過。5.3 還車結算狀態(tài)、費用、余額三個動作聯(lián)動還車接口是系統(tǒng)里事務最密集的一個地方。用戶點還車后后端要同時做這幾件事根據(jù)訂單號查出訂單校驗訂單狀態(tài)確實是騎行中更新訂單的實際歸還時間計算費用從用戶余額扣除費用寫入支付流水把車輛狀態(tài)改回空閑如果車輛有損壞標記改成維修中插入維修記錄我習慣把它寫成一個帶Transactional的Service方法并且用狀態(tài)校驗作為第一步。實際操作中還發(fā)現(xiàn)一個坑還車時車輛位置的更新。用戶可能從A區(qū)騎到B區(qū)歸還所以還車時應該允許用戶/管理員修改車輛location。這個字段如果不更新后臺顯示的車輛位置就會一直是租賃起點時間長了數(shù)據(jù)就很離譜。5.4 管理端界面后臺功能別做太重管理端的功能以能管理、能看數(shù)、能處理異常為準不要過度美化。我用Thymeleaf做后臺的時候一般就這幾個頁面車輛管理列表頁增刪改查、訂單管理頁按狀態(tài)篩選、異常處理、用戶管理頁、計費規(guī)則配置頁。列表查詢強烈建議用MyBatis Plus的分頁插件。配置方式很簡單Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }配置好之后Service里直接page(new Page(current, size), queryWrapper)就能拿到分頁結果關聯(lián)的total和records都幫你算好了比自己寫LIMIT和COUNT省事太多。5.5 定時任務超時訂單的自動處理這個是我非常推薦加的加分功能。場景是這樣的用戶下單鎖定了車輛但一直不來取車車就一直被占用別人沒法租。解決辦法是SpringBoot內置的Scheduled定時任務每隔幾分鐘掃描一次待取車且超過15分鐘未取車的訂單自動取消訂單并釋放車輛。Component public class OrderTimeoutTask { Scheduled(cron 0 */5 * * * *) public void cancelTimeoutOrders() { LambdaQueryWrapperOrder wrapper new LambdaQueryWrapper(); wrapper.eq(Order::getStatus, OrderStatus.WAIT_PICK.getCode()) .lt(Order::getCreateTime, LocalDateTime.now().minusMinutes(15)); ListOrder orders orderMapper.selectList(wrapper); for (Order order : orders) { order.setStatus(OrderStatus.CANCELED.getCode()); orderMapper.updateById(order); Bike bike bikeMapper.selectById(order.getBikeId()); if (bike ! null bike.getStatus() 1) { bike.setStatus(0); bikeMapper.updateById(bike); } } } }這個功能實現(xiàn)難度不大但背后體現(xiàn)了異常訂單處理的業(yè)務思維是答辯時可以主動講給評委聽的一個亮點。6. 從開發(fā)到答辯演示安排、常見追問與加分項6.1 三分鐘演示腳本答辯時間有限不要從注冊頁面開始慢慢點評委沒那么多耐心。我建議的演示路徑是先用管理員賬號登錄在車輛管理頁展示車輛列表、新增一輛測試車說明后臺CRUD能力。切換到用戶端選擇剛才新增的車提交租車訂單展示下單成功和車輛狀態(tài)變化。模擬還車展示訂單結算頁面強調金額計算過程和用戶余額扣減。切回管理端展示這筆訂單的狀態(tài)從騎行中變?yōu)橐淹瓿绍囕v重新回到空閑。如果有定時任務功能可以補一句系統(tǒng)每分鐘會自動掃描超時訂單并取消不必現(xiàn)場等觸發(fā)。這套流程里每一步都同時展示了前端交互、后端接口、數(shù)據(jù)庫變化三個層次評委看完心里對你系統(tǒng)的完整性就有數(shù)了。6.2 評委高頻追問和應答思路答辯環(huán)節(jié)很多同學不是不會做是不會說。提前準備下面這些問題的應答思路會穩(wěn)很多問車輛狀態(tài)修改為什么不用普通update怎么防并發(fā)答我用的是條件更新UPDATE ... WHERE id? AND status0如果影響行數(shù)為0說明已被別人搶到就會拒絕訂單。也可以提樂觀鎖版本號。問計費金額怎么保證精度答金額字段用DECIMAL存儲Java側用BigDecimal計算不用double避免浮點誤差。問如果用戶超時還不還車怎么辦答系統(tǒng)有定時任務掃描超時訂單設置超時費用累加并且可以限制該用戶下次租車。問訂單狀態(tài)很多會不會出現(xiàn)狀態(tài)不一致答我們在設計階段用狀態(tài)機表約束了每個狀態(tài)下能跳轉到哪些狀態(tài)Service層每個狀態(tài)變更都做前置校驗并且關鍵操作放在事務里執(zhí)行。問密碼怎么存儲答使用MD5或BCrypt加鹽加密保存不存明文。別再說MD5不安全畢設場景用MD5可接受建議提BCrypt更好6.3 部署與演示環(huán)境準備演示環(huán)境最穩(wěn)妥的方式是本機演示提前把所有服務跑起來瀏覽器開好兩個頁面管理員端和用戶端。如果希望評委能自己上手體驗可以部署到云服務器或者學校機房服務器上。這里說一個常見的問題前后端分離項目部署時前端打包后的靜態(tài)資源和后端API怎么配合。如果是Vue項目構建后把dist目錄放到SpringBoot的static下再配一個路徑轉發(fā)規(guī)則就行如果是Thymeleaf模板就不用考慮這個問題這也是我推薦模板引擎的原因之一。提示演示當天記得關掉電腦的自動睡眠把數(shù)據(jù)庫密碼、服務啟動腳本都提前準備好。我見過太多同學現(xiàn)場演示時因為數(shù)據(jù)庫沒啟動、端口被占用、密碼忘了這些沒有技術含量的問題把幾分鐘答辯時間全耗在了環(huán)境上。6.4 我最后想提的幾個容易翻車的小細節(jié)最后的最后分享幾條自己整理的真實經(jīng)驗配置文件的密碼、連接串寫清楚但答辯演示時別把真實密碼投屏給全場看可以用一個演示專用的低權限賬號。開發(fā)過程中別忘了建索引。訂單表的user_id、bike_id、status這幾個字段是高頻查詢條件加索引后列表頁性能明顯不一樣這也是評委偶爾會問的點。異常處理別只靠try-catch空吞。做成統(tǒng)一異常處理器RestControllerAdvice把業(yè)務異常和系統(tǒng)異常區(qū)分開前端彈的錯誤提示會友好非常多代碼也干凈。提交代碼到Git倉庫時第一次就配好.gitignore把target、node_modules、application-local.yml這類文件排除掉。這是職業(yè)習慣問題雖然畢設不強制但養(yǎng)成好習慣不虧。論文里的系統(tǒng)截圖記得重新走一遍流程再截不要用開發(fā)調試時帶著斷點信息、系統(tǒng)時間不對的截圖這種細節(jié)很容易被評委一眼看出來。做這個項目我最大的體會是畢設系統(tǒng)不需要多炫的技術但一定要把業(yè)務閉環(huán)做完整、把關鍵問題想透。電動車的租借、計費、還車、狀態(tài)流轉每一步都不復雜但把它們串成一個可靠的整體你收獲的就不只是一個能答辯的系統(tǒng)而是一次完整的軟件工程訓練。希望這篇分享能幫你少踩幾個坑把時間花在真正有價值的地方。