1. 這個項目到底在做什么大學生租房平臺的業(yè)務定位與需求拆解每年畢業(yè)設計季被問得最多的題目類型之一就是“基于Spring Boot的某某平臺”其中“大學生租房平臺”是典型中的典型。這題目的價值在于它不只是一個增刪改查的演示系統(tǒng)它背后站著的是一整條真實的業(yè)務鏈路房源錄入、信息檢索、預約看房、簽約成交、評價反饋。稍微把每個環(huán)節(jié)做扎實一點就是一個能放在簡歷上講的完整項目。先說清楚題目里的兩個關鍵詞。第一是“springboot007”這個007更像是一個內(nèi)部編號或課程設計歸檔號真正決定項目形態(tài)的是后半句——大學生租房平臺的設計與實現(xiàn)文檔源碼。也就是說這個項目考核的不光是能跑的代碼還有配套的畢業(yè)設計文檔。很多同學只盯著源碼文檔草草拼湊最后答辯被問得無話可說這是我最想先提醒的一點。那為什么偏偏選“大學生租房”因為需求太真實了。高校周邊租房的核心場景是學生想找離學校近、價格合理、可以合租的房源房東手里有房但沒精力自己天天帶看中介收費高學生承受不起。這個三方矛盾天然需要一套在線平臺來撮合房東發(fā)布房源、學生篩選房源、雙方約定時間看房。它比純粹的“商品管理系統(tǒng)”多了一層社會關系和線下交互也更好寫出需求分析。再說適合誰。這個東西適合兩類人一類是做畢業(yè)設計或課程設計的學生需要快速理解一個Spring Boot完整項目的結構另一類是剛入門Java Web開發(fā)、想找一個能模擬真實業(yè)務場景來練手的自學者。不管屬于哪類看完這篇文章你至少能回答三個問題這個平臺有哪些功能、這些功能為什么這么設計、真把一個Spring Boot項目從零搭起來會踩哪些坑。1.1 為什么選“大學生租房”這個場景選題這件事很多同學想復雜了。要么選一個特別宏大的題目比如“智慧社區(qū)綜合服務平臺”結果自己根本說不清楚哪塊是智慧要么選一個特別空洞的題目比如“基于SSM的網(wǎng)上商城”做完發(fā)現(xiàn)和網(wǎng)上的教程Demo幾乎一模一樣。大學生租房平臺的好處在于它有一個非常明確、非常好解釋的“核心痛點”。這個痛點就是信息不對稱。學生找房時最怕三件事房源是假的、價格是虛的、房東聯(lián)系不上。平臺要解決的就是把房源信息結構化、把房東身份實名化、把看房流程線上化。換句話說這個選題從需求層面就保證了系統(tǒng)里必須有“房源管理”“用戶管理”“預約流程”這三塊內(nèi)容不會出現(xiàn)為了湊功能而硬加模塊的情況。另一種常見選法是做“二手交易平臺”但二手交易涉及支付、物流、售后復雜度很容易控制不住。租房平臺可以把簽約和付款做成線下環(huán)節(jié)線上只負責信息和預約這正好落在畢業(yè)設計的合適難度區(qū)間——比純CRUD高一點又不至于高到做不完。這就是我常說的選題原則業(yè)務閉環(huán)但復雜度可控。1.2 三類角色與核心功能清單租房平臺不可能只有一種用戶。最基礎的是三類角色學生租客、房東、管理員。如果再加一層就是“未登錄游客”游客只能瀏覽房源列表想看聯(lián)系方式或預約看房就必須注冊登錄。學生端注冊登錄、瀏覽房源、按區(qū)域/價格/戶型篩選、收藏房源、提交預約看房、查看預約狀態(tài)、查看個人收藏夾、對已看過的房源發(fā)表評價。房東端注冊登錄、發(fā)布房源標題、描述、圖片、租金、戶型、地址、管理自己的房源下架/編輯、查看收到的預約請求并確認/拒絕。管理端用戶管理禁用/啟用賬號、房源審核新發(fā)布的房源必須過審才能展示、公告管理、數(shù)據(jù)概覽用戶數(shù)、房源數(shù)、預約次數(shù)等簡單統(tǒng)計。注意一個細節(jié)房源審核這個功能很有價值。它不光是業(yè)務需要還能讓你的系統(tǒng)多出一個“狀態(tài)流轉”的演示點寫論文時能單獨占一節(jié)“審核機制設計”。很多同學做這類項目只在實體字段里加一個“狀態(tài)”數(shù)字卻不設計狀態(tài)流轉規(guī)則答辯時被問“一個房源從發(fā)布到上架經(jīng)歷了什么狀態(tài)”就答不上來。1.3 從需求到原型的取舍思路拿到需求清單之后第一件事不是建表而是做取舍。我見過不少同學把功能表列得很滿今天加一個“在線聊天”明天加一個“租金計算器”最后數(shù)據(jù)庫二十多張表代碼四處漏風。這里要有一個原則核心鏈路優(yōu)先周邊功能從簡。這個項目的核心鏈路就是“發(fā)布房源-搜索房源-預約看房-確認看房-評價”。所有角色和表結構都應該服務于這條鏈路。至于站內(nèi)信、消息通知這類屬于可有可無的加分項時間充裕再加。我做這個項目時會先畫一條最簡單的業(yè)務線然后用“如果我是學生我會在哪個步驟卡住”來反推功能。比如學生看到房源想聯(lián)系房東如果平臺不提供任何聯(lián)系入口那這個平臺就廢了。所以“預約看房”不是附加功能是核心功能。原型階段不需要用Axure畫得多精致一張紙一支筆畫出每個角色的頁面流轉就行。桌面端和移動端怎么取舍考慮到學生和房東大量使用手機界面要優(yōu)先適配移動端但畢業(yè)設計演示通常是在電腦大屏上所以更推薦做得“響應式”——Bootstrap或Vue加個移動端適配兩邊都能看。這個細節(jié)寫進文檔里是“界面設計考慮到了多端訪問”很加分。2. 技術選型與整體架構Spring Boot為主線的務實方案技術選型決定一個項目好不好寫完、好不好答辯。我不建議在畢業(yè)設計里追新技術更不建議“為了用而用”。一個成熟的課題方向是Spring Boot做后端MyBatis-Plus做數(shù)據(jù)訪問MySQL存儲數(shù)據(jù)Redis做緩存和驗證碼JWT做登錄鑒權Vue或Thymeleaf做前端。這套組合最大的優(yōu)點不是“新”而是“穩(wěn)”——網(wǎng)上資料多、社區(qū)問答多、模板多出了問題容易搜到答案。2.1 后端選型基于Spring Boot的版本與組件搭配Spring Boot的版本選擇是很多人的第一個坑?，F(xiàn)階段寫新項目Spring Boot 2.7.x是一個比較穩(wěn)妥的選擇原因有二一是2.7屬于社區(qū)資源最豐富的版本段你搜到的大多數(shù)博客、網(wǎng)課、畢業(yè)設計模板都跑在這個版本上二是Spring Boot 3.x雖然新但底層是Jakarta EE命名空間javax變成jakarta很多舊資料里的import javax.servlet.*直接復制過來會報紅。如果你用了Spring Boot 3.x等于自己主動放棄了大量現(xiàn)成參考資料。組件搭配上我推薦下面這個組合組件用途替代方案與說明MyBatis-Plus數(shù)據(jù)訪問層自帶分頁插件和條件構造器原版MyBatis要寫大量XMLPlus更適合快速開發(fā)MySQL 8.x主數(shù)據(jù)庫5.7也能跑但8.x時區(qū)配置更省心Redis登錄Token存儲、驗證碼緩存沒有Redis可用Session但用了Redis寫文檔更好看JWT Spring Security接口鑒權畢設用Interceptor加JWT工具類就夠不必上Spring SecurityLombok簡化實體類有爭議但能少寫大量get/setHutool工具類集合驗證碼生成、隨機數(shù)、日期處理都能用它為什么不用Spring Security因為這個平臺的權限模型非常簡單三類角色少數(shù)幾個管理員接口需要校驗管理員身份其余接口只要“已登錄”就行。拿Spring Security那套過濾器鏈、UserDetailsService、密碼編碼器去實現(xiàn)代碼量翻倍答辯時還容易把自己繞暈。一個自定義攔截器加JWT工具類兩千行以內(nèi)搞定權限控制效果完全夠用。2.2 前端與部署形態(tài)Vue打包放進Spring Boot的實操前端的選擇會直接影響交付形式?！皊pringboot007大學生租房平臺”的設計通常有兩種一種是傳統(tǒng)的服務端渲染用Thymeleaf模板引擎加Bootstrap寫完一個包直接扔進static目錄就能跑另一種是前后端分離后端提供JSON接口前端用Vue框架開發(fā)時前后端分兩個進程跑交付時把Vue打包產(chǎn)物放到Spring Boot的static目錄下。第二種更像真實企業(yè)項目也更符合現(xiàn)在的招聘技能要求。但要注意如果把Vue打包后的dist目錄直接放到Spring Boot的src/main/resources/static下會有一個經(jīng)典問題頁面路由是history模式時刷新某個子路徑會404。原因是Spring Boot默認只把/映射到index.html并沒有把前端路由的路徑重新指回首頁。解決辦法也簡單寫一個WebMvcConfigurer把非接口路徑全部轉發(fā)到/index.html。另一個常見錯誤是接口前綴不一致。前端Vue開發(fā)時通過/api代理請求后端打包部署后沒有代理了必須保證前端請求的地址和后端接口實際地址一致。我的做法是后端所有接口統(tǒng)一以/api開頭前端請求也直接寫/api/...開發(fā)時用Vite的proxy把/api轉發(fā)到http://localhost:8080部署后同源訪問不需要改代碼。這個細節(jié)能幫你省下大量聯(lián)調(diào)時間。2.3 項目結構設計按功能分包而不是按層分包很多剛接觸Spring Boot的同學會把項目結構寫成controller、service、mapper、entity四個包所有Controller堆在一起。小項目這么寫問題不大但當一個模塊的功能增多后找代碼會變得很痛苦。租房平臺規(guī)模適中我建議按功能模塊分包com.example.house ├── common # 通用工具、統(tǒng)一返回結果、異常處理 ├── config # 配置類如跨域、攔截器、緩存配置 ├── security # JWT工具、登錄攔截、角色校驗 ├── modules │ ├── user # 用戶模塊Controller、Service、Mapper、實體 │ ├── house # 房源模塊 │ ├── order # 預約模塊 │ ├── favorite # 收藏模塊 │ └── admin # 后臺管理模塊 └── HouseApplication.java按功能分包的好處是改“房源審核”時只需要打開modules/house目錄所有相關的Controller、Service、Mapper都在里面不需要在四個大包里來回跳。寫文檔的時候也更好描述“用戶模塊負責……房源模塊負責……”架構圖更清晰。這個包結構本身就是一個加分項說明你有模塊化意識。3. 數(shù)據(jù)庫設計與核心表結構房源、訂單與權限的關鍵建模數(shù)據(jù)庫設計是這個項目里最值得花時間的地方。表結構定得好后面寫代碼順風順水表結構定得爛后面每個查詢都在補洞。我用四張核心表展開講用戶表、房源表、預約表、收藏表再加一張公告表作為管理端功能點。3.1 核心表清單與字段設計要點用戶表t_user要區(qū)分角色用role字段枚舉值STUDENT、LANDLORD、ADMIN。其他字段包括用戶名、密碼BCrypt加密、昵稱、手機號、頭像、學校/職業(yè)等。注意手機號在租房場景里是核心聯(lián)系手段必須做唯一索引。房源表t_house是最重的一張表。核心字段包括標題、描述、封面圖、戶型幾室?guī)讖d、面積、租金元/月、出租方式整租/合租、所在區(qū)域、詳細地址、房東ID、狀態(tài)待審核/已上架/已下架、瀏覽量、創(chuàng)建時間。這里我特別提兩點一是租金用整數(shù)INT表示“元/月”不要用字符串“3000元/月”否則后面做價格區(qū)間查詢時沒法用數(shù)字比較二是詳細地址要單獨一個字段但列表頁只展示區(qū)域和小區(qū)名避免用戶隱私過早泄露這個點寫進文檔能體現(xiàn)安全意識。預約表t_appointment用于記錄看房預約字段包括房源ID、學生ID、預約時間、期望看房時間段、備注、狀態(tài)待確認/已確認/已取消/已完成、創(chuàng)建時間。預約狀態(tài)是這個模塊的核心一定要有狀態(tài)位。評價表t_review記錄學生看完房后的評價關聯(lián)預約ID或房源ID再關聯(lián)用戶ID。3.2 房源狀態(tài)與預約狀態(tài)的狀態(tài)機設計狀態(tài)機是答辯時最能展示你思考深度的部分。房源的完整狀態(tài)流轉是待審核(AUDITING)-已上架(ON_SALE)-已下架(OFF_SALE)其中待審核只能通過管理員審核變成已上架或已駁回(REJECTED)房東可以主動把已上架下架但不能繞過審核直接上架。這里用代碼寫一個校驗不是很難但一定要有。預約的狀態(tài)流轉是待確認(PENDING)-已確認(CONFIRMED)也可以已取消(CANCELED)最后學生看房完畢由學生確認或系統(tǒng)自動置為已完成(FINISHED)。為什么預約要設計“待確認”這一步因為房東不一定有空必須給房東一個操作空間。很多同學這里直接設計成“學生提交預約就算約成功”這不符合真實場景答辯時也容易被追問。一個實用的設計技巧是在狀態(tài)字段旁加一個status_text的展示字段前端直接讀取展示文案不用前端硬編碼狀態(tài)對應的中文?；蛘哂肕yBatis-Plus的枚舉轉換把數(shù)據(jù)庫里的數(shù)字自動轉成Java枚舉前端拿到的就是可讀狀態(tài)。無論如何狀態(tài)文案只允許在后端出別讓前端猜。3.3 數(shù)據(jù)訪問層的選擇MyBatis-Plus分頁與條件構造MyBatis-Plus是這類畢業(yè)設計項目的好搭檔。它內(nèi)置了BaseMapper單表CRUD幾乎不用寫SQL分頁插件開箱即用條件構造器QueryWrapper能解決大部分動態(tài)查詢。比如房源列表的篩選查詢學生可能按區(qū)域篩、按價格區(qū)間篩、按戶型篩、按“合租/整租”篩還可能同時組合。用MyBatis-Plus寫很簡潔public PageHouse searchHouse(HouseQuery query, int page, int size) { PageHouse p new Page(page, size); LambdaQueryWrapperHouse wrapper new LambdaQueryWrapper(); wrapper.eq(StringUtils.hasText(query.getRegion()), House::getRegion, query.getRegion()) .eq(query.getRentType() ! null, House::getRentType, query.getRentType()) .between(query.getMinPrice() ! null query.getMaxPrice() ! null, House::getPrice, query.getMinPrice(), query.getMaxPrice()) .eq(House::getStatus, HouseStatus.ON_SALE) .orderByDesc(House::getCreateTime); return houseMapper.selectPage(p, wrapper); }注意這里我把“只看已上架房源”作為固定條件寫死了防止學生刷出待審核或已下架的房源。這種細節(jié)就是安全邏輯的體現(xiàn)。另外分頁參數(shù)page和size一定要做邊界控制page最小為1size最大別超過100否則有人傳一個size999999一次把整表拉出來接口直接就慢成“演示事故”。4. 核心功能實現(xiàn)與代碼排坑實錄這一節(jié)是重點我把這個項目里最容易掉進去的坑和對應的實現(xiàn)思路集中講一遍。能寫出來的都是我自己跑過、調(diào)試過、出過丑的真實經(jīng)驗。4.1 用戶注冊登錄與JWT鑒權注冊登錄是入口但很多同學的入口代碼寫得亂七八糟。先說密碼絕不能明文存儲用BCryptPasswordEncoder加密。加密之后即使數(shù)據(jù)庫泄露攻擊者也很難反推出原始密碼。Spring Security里自帶這個類如果你沒引入Spring Security單獨引入spring-security-crypto依賴也能用。注冊時還要處理幾個問題用戶名是否重復、手機號格式、密碼強度。我一般會在Service層做統(tǒng)一校驗然后Mapper插入。接口返回統(tǒng)一用ResultT結構比如public ResultString login(String username, String password) { User user userService.findByUsername(username); if (user null || !encoder.matches(password, user.getPassword())) { return Result.error(用戶名或密碼錯誤); } String token jwtUtil.generateToken(user.getId(), user.getRole()); return Result.success(token); }登錄成功后返回JWT字符串前端存在localStorage里之后每個請求在Authorization頭帶上。后端攔截器解析Token取出用戶ID放到ThreadLocal或請求屬性里供后續(xù)寫業(yè)務代碼使用。關于JWT有個坑要提示JWT默認不加密payload是Base64明文千萬不要把手機號、密碼之類的敏感信息塞進去。Token里只需要用戶ID和角色需要更多信息時再查庫。4.2 房源發(fā)布與圖片上傳的坑房源發(fā)布里最鬧心的就是圖片上傳。畢設項目一般不用OSS對象存儲最常見的是把圖片存到本地磁盤。這里有兩個坑必須提前避開。第一個坑是本地路徑問題。如果直接把圖片寫到項目根目錄下的upload文件夾然后以相對路徑訪問打包成jar運行時會發(fā)現(xiàn)圖片存到了jar包外面的臨時目錄或者根本寫不進去。我的做法是在application.yml里配置一個對外統(tǒng)一的存儲路徑比如E:/upload/或者Linux下的/data/upload/再配一個靜態(tài)資源映射Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceHandler(file: uploadPath); }這樣訪問http://localhost:8080/upload/xxx.jpg就能直接看到圖片而且圖片文件和項目代碼分離重打jar包也不會丟數(shù)據(jù)。第二個坑是文件類型和大小校驗。只檢查拓展名是不可靠的一個改名成.jpg的腳本文件能直接繞過。至少做到用MimeType校驗限制文件大小比如單張不超過5MB并把文件重命名為UUID加拓展名保存避免中文名和“同名覆蓋”問題。安全這塊如果寫進文檔的“系統(tǒng)安全設計”里是個很有分量的加分點。4.3 搜索篩選與預約看房的關鍵代碼搜索篩選上一節(jié)展示過了這里重點說預約看房的流程實現(xiàn)。學生選擇“預約看房”時前端提交房源ID、預約日期、時間段、備注。后端要校驗四件事房源存在且已上架當前用戶已登錄且角色是學生該房源沒有被當前用戶重復提交待確認的預約預約時間不能是過去。校驗通過后插入一條PENDING狀態(tài)的預約記錄。public ResultVoid createAppointment(AppointmentRequest req, Long studentId) { House house houseMapper.selectById(req.getHouseId()); if (house null || house.getStatus() ! ON_SALE) { return Result.error(房源不存在或不可預約); } long count appointmentMapper.selectCount(new LambdaQueryWrapperAppointment() .eq(Appointment::getHouseId, req.getHouseId()) .eq(Appointment::getStudentId, studentId) .eq(Appointment::getStatus, PENDING)); if (count 0) { return Result.error(你已預約過該房源請等待房東確認); } if (req.getAppointmentDate().isBefore(LocalDate.now())) { return Result.error(預約時間不能早于今天); } // 插入預約記錄 return Result.success(); }房東端看到預約請求后可以選擇“確認”或“拒絕”。確認時把狀態(tài)改為CONFIRMED同時給學生做一個站內(nèi)通知或發(fā)送一條系統(tǒng)消息這塊用一張簡單的t_message表就行不一定要上WebSocket。這套交互做完項目在業(yè)務上就是一個完整的閉環(huán)了。5. 文檔寫作與答辯準備畢設項目不能只交代碼很多同學把精力全部放在寫代碼上文檔最后三天趕工結果代碼能跑但論文質(zhì)量差答辯照樣被批。我必須強調(diào)這個題目的交付物是“文檔源碼”兩樣缺一不可。文檔不是代碼的說明書它要回答“你為什么做這個系統(tǒng)”“系統(tǒng)怎么設計”“遇到什么問題怎么解決”。5.1 論文/文檔怎么寫才不像湊字數(shù)常見的畢業(yè)設計文檔結構是選題背景與意義、國內(nèi)外研究現(xiàn)狀、需求分析、系統(tǒng)設計、數(shù)據(jù)庫設計、功能實現(xiàn)、系統(tǒng)測試、總結與展望。這套結構本身沒問題但大多數(shù)同學寫出來的內(nèi)容充滿了廢話。比如“選題背景”不要寫“隨著互聯(lián)網(wǎng)的發(fā)展人們的生活水平提高了”一開口就知道是拼湊的應該寫清楚你這個平臺面向的具體人群和具體痛點。哪怕這樣寫都更好“高校周邊租房市場長期存在信息不對稱問題學生找房成本高、房東發(fā)布渠道分散、看房時間難以協(xié)調(diào)。針對以上問題本課題設計并實現(xiàn)一個面向高校學生和房東的租房信息平臺通過線上房源審核與預約看房機制降低租房交易的信息門檻。”需求分析部分不要只貼用例圖還要畫數(shù)據(jù)流圖把“學生-平臺-房東”三方的信息交互流程講清楚。系統(tǒng)設計部分要有總體架構圖和各模塊設計。功能實現(xiàn)部分挑至少3-4個核心功能詳細展開比如JWT鑒權流程、房源審核流程、價格區(qū)間篩選的實現(xiàn)思路配上核心代碼和運行截圖。5.2 答辯時的高頻提問與應答思路答辯老師不一定會把項目跑一遍但他們一定會問“所以你是怎么做的”和“為什么這么做”。常見問題我列一下你們提前準備為什么選Spring Boot而不是SSH/SSM答Spring Boot簡化了配置、內(nèi)置了Tomcat、生態(tài)成熟適合快速構建獨立服務且在求職市場上Spring Boot是主流要求。你的系統(tǒng)是如何保證安全的答密碼BCrypt加密、JWT無狀態(tài)鑒權、管理員審核房源、上傳文件類型與大小校驗、SQL走MyBatis-Plus參數(shù)化避免字符串拼接SQL。如果并發(fā)量上來了系統(tǒng)瓶頸在哪答當前是單體架構瓶頸會在數(shù)據(jù)庫的房源表和預約表的寫入與查詢上可以加索引緩存后續(xù)可引入Redis緩存熱門房源列表預約邏輯可以異步化。為什么預約要設計“待確認”狀態(tài)答因為房東時間不確定必須給予確認環(huán)節(jié)保證雙方信息對稱。答不出來的老老實實說“這個當時沒有深入考慮但我的想法是……”比硬編一個答案強得多。千萬不要背答案老師一眼就能看出來。5.3 項目二次擴展把源碼變成自己的東西很多同學拿到一套“大學生租房平臺”源碼第一反應是改個名字提交。這是最危險的做法因為數(shù)據(jù)庫里可能還留著原作者的測試數(shù)據(jù)、包名、logo甚至Git提交歷史。至少要做四件事全局替換包名和項目名、清空或重置數(shù)據(jù)庫、刪除殘留無用的圖片和測試數(shù)據(jù)、把代碼從頭到尾讀一遍并注釋理解。讀一遍也不是瞎讀。我建議按“請求進入-攔截器校驗-Controller- Service- Mapper- SQL”這條鏈路把一個核心流程完整追一遍比如“學生提交預約看房的完整調(diào)用鏈”。追完之后再改兩三個自己感興趣的功能比如加一個“地圖選房”頁面或者加一個“房東收入統(tǒng)計”的報表。哪怕只是很小的改動答辯時你說“我在原基礎上增加了XXX”底氣都不一樣。6. 常見問題速查表與避坑清單最后貢獻一份實用的避坑清單。這里面的問題我?guī)缀趺總€都在真實項目里見過按照“環(huán)境搭建期、編碼實現(xiàn)期、部署演示期”三個階段整理遇到直接查表。6.1 環(huán)境搭建期的高頻問題問題現(xiàn)象原因與解決啟動報Failed to configure a DataSource沒有配置或沒有識別到數(shù)據(jù)源。檢查application.yml里spring.datasource配置是否正確注意MySQL驅(qū)動坐標有沒有引入Spring Boot版本太高引入老依賴直接報錯Spring Boot 3.x對javax改名為jakarta老依賴可能不兼容。建議用2.7.x或每引入一個依賴先看它是否聲明支持Spring Boot 3端口被占用啟動后訪問不到改server.port或者殺掉占用進程。Windows下查端口netstat -ano前端請求接口CORS報錯開發(fā)時配置跨域。寫一個WebMvcConfigureraddCorsMappings允許本地前端地址訪問或者按前文統(tǒng)一/api前綴部署后同源無跨域這里單獨說一說“Spring Boot版本太高”這個問題。我見過太多同學從官網(wǎng)直接拉最新版3.3、3.4然后開始百度找各種starter結果發(fā)現(xiàn)老教程的配置都不生效。不是說新版本不好而是畢業(yè)設計不應該把時間花在和版本搏斗上。用2.7.x踩坑成本最低。6.2 編碼實現(xiàn)期的經(jīng)典坑問題現(xiàn)象原因與解決時間字段返回數(shù)組或奇怪字符串默認JSON序列化對LocalDateTime支持不友好。統(tǒng)一用Jackson配置全局日期格式或在字段上加JsonFormat圖片上傳后訪問404檢查靜態(tài)資源映射是否配置檢查存儲路徑是否帶了文件名檢查路徑中是否有中文或空格建議全部重命名為UUID分頁數(shù)據(jù)對但總數(shù)不對MyBatis-Plus分頁插件沒有注冊。需要配置MybatisPlusInterceptor并添加PaginationInnerInterceptor刪除用戶時外鍵報錯需要先刪關聯(lián)數(shù)據(jù)或者刪用戶時做“邏輯刪除”用deleted字段標記而不是物理刪除邏輯刪除這件事強烈建議做。用戶表、房源表、預約表都加一個deleted字段查詢時自動過濾。好處有兩個一是數(shù)據(jù)不真丟誤刪還能恢復二是SQL自帶where deleted 0對答辯時“數(shù)據(jù)安全”的提問也有東西可講。6.3 部署與演示期的注意事項最后的演示環(huán)節(jié)翻車最不值得。提前做好三件事第一數(shù)據(jù)庫要準備一批真實感強的測試數(shù)據(jù)房源圖片不要用網(wǎng)上隨機抓的模糊圖至少十幾套清晰圖片房源地址起“大學城地鐵站附近”“圖書館東門500米”這類真實的校園周邊位置第二演示前把項目啟動好瀏覽器直接打開頁面別在臺上等著五六秒的啟動過程第三準備一條“演示腳本”從學生注冊、搜索房源、預約看房到房東登錄、確認預約再到管理員審核房源完整走一遍控制在3分鐘以內(nèi)。圖片資源這塊我多說一句。很多畢設的房源圖片一眼假全是同一張占位圖?；c時間找真實的房屋照片或者自己用手機拍幾張會讓整個項目在答辯時的質(zhì)感完全不一樣?！凹毠?jié)到位”在畢設評價里從來都是加分項。最后再分享一個小經(jīng)驗做完項目之后一定把你寫過的核心代碼按模塊整理成幾篇帶注釋的Markdown筆記配上表和結構圖。這不只是給文檔用也是你面試談項目時的提詞器。把“大學生租房平臺”講清楚、講深一層比簡歷上寫十個“熟練使用”都管用。如果你現(xiàn)在正卡在某個環(huán)境問題或編碼小坑里對照這份避坑清單再試一次多半就能過去。