1. 這個系統(tǒng)為什么年年有人做年年有人喊難每到了課程設(shè)計和畢業(yè)設(shè)計的季節(jié)技術(shù)社區(qū)里就會出現(xiàn)大量求學(xué)生宿舍管理系統(tǒng)源碼的帖子。說實話這道題看起來簡單和做起來麻煩的落差比想象中要大得多。表面上看就是幾個增刪改查頁面學(xué)生信息、宿舍信息、報修記錄。但真正動手做的時候權(quán)限怎么劃分、床位狀態(tài)怎么流轉(zhuǎn)、同一個床位會不會被兩個人同時選中、統(tǒng)計報表里的數(shù)字怎么算才說得清這些細節(jié)會把一個簡單系統(tǒng)硬生生拖成日夜趕工項目。我去年幫一個朋友完整做了一套基于SpringBoot和Vue的學(xué)生宿舍管理系統(tǒng)從數(shù)據(jù)庫設(shè)計到前端頁面再到部署上線前后搭進去一個周末加幾個晚上。這篇文章就把整個開發(fā)過程中的決策邏輯、踩坑點和最終方案完整復(fù)盤一遍。不涉及具體商業(yè)代碼但每一個設(shè)計思路和實現(xiàn)方案你都可以直接復(fù)制到自己的項目里。適合正在做課設(shè)或畢設(shè)、想從能跑進化到能講的同學(xué)也適合剛接觸前后端分離架構(gòu)、想找一個完整案例練手的開發(fā)者。1.1 一份需求清單先搞清楚宿舍管理系統(tǒng)到底管什么在動手寫代碼之前我習(xí)慣先把需求掰開揉碎。學(xué)生宿舍管理系統(tǒng)通常涉及三類角色系統(tǒng)管理員、宿管員、學(xué)生。以最常見的課設(shè)要求為例核心功能基本跑不出這幾個模塊基礎(chǔ)信息管理樓棟管理、宿舍管理、床位管理、學(xué)生信息錄入與維護。宿舍分配業(yè)務(wù)學(xué)生入住分配床位、退宿釋放床位、調(diào)宿申請與審批。日常事務(wù)管理衛(wèi)生檢查打分、報修登記與處理進度、晚歸或請假登記。查詢與統(tǒng)計按樓棟、學(xué)院、班級查學(xué)生統(tǒng)計入住率、報修處理率等。系統(tǒng)管理賬號管理、角色權(quán)限控制、密碼修改、登錄日志。這里有一個非常重要的認(rèn)知這些功能里真正有技術(shù)含量的不是增刪改查而是床位的狀態(tài)流轉(zhuǎn)和權(quán)限控制。床位不是簡單的一個字段它有空閑、已入住、維修中三種狀態(tài)而且同一個學(xué)生不能同時占兩個床位兩個管理員也不能同時把同一個床位分給不同的人。如果不提前設(shè)計好數(shù)據(jù)模型和更新邏輯后面做分配功能時會不停地返工。1.2 這篇博文的定位不是源碼搬運而是設(shè)計思路的完整復(fù)盤我清楚很多人搜學(xué)生宿舍管理系統(tǒng)源碼就是想要一份能直接交差的東西。但我更建議你把這篇內(nèi)容當(dāng)成設(shè)計文檔級別的實戰(zhàn)筆記來看。我會詳細說明為什么選SpringBoot而不選SSM數(shù)據(jù)庫表為什么要那樣建用戶登錄的token到底是怎么流轉(zhuǎn)的前端打包之后怎么丟進SpringBoot的靜態(tài)目錄里以及哪幾個位置最容易在答辯現(xiàn)場被老師一句話問住。就算你最后不用我這里的方案沿著這套思路去拆解任何一份開源源碼你也能在很短時間內(nèi)看懂它、改進它并寫好配套文檔。下面進入正題。2. 翻開一份能跑的源碼SpringBootVue的骨架到底長啥樣我見過太多課設(shè)項目前端是一個HTML頁面套著一堆jQuery后端是Servlet加JDBC代碼全堆在Controller里。能跑但答辯老師只要問一句如果并發(fā)50個人同時選床位怎么辦基本就卡殼了。用SpringBoot加Vue做前后端分離不是為了趕潮流而是這兩個框架恰好都滿足課設(shè)場景里最重要的三個要求學(xué)習(xí)成本可控、資料足夠多、架構(gòu)經(jīng)得起追問。2.1 前后端分離的本質(zhì)兩個項目還是一個項目先把這個問題講透。前后端分離在物理上通常是兩個獨立的工程一個是SpringBoot的Maven工程一個是用Vue CLI或Vite創(chuàng)建的Node前端工程。后端只提供HTTP接口、返回JSON前端只管渲染頁面和交互二者通過Axios之類的HTTP客戶端通信。一個標(biāo)準(zhǔn)的目錄結(jié)構(gòu)長這樣dormitory-system/ ├── backend/ # SpringBoot后端工程 │ ├── src/main/java/com/dorm/ │ │ ├── controller/ # 接收請求返回JSON │ │ ├── service/ # 業(yè)務(wù)邏輯 │ │ ├── mapper/ # 數(shù)據(jù)訪問層 │ │ ├── entity/ # 實體類 │ │ ├── config/ # 配置類跨域、攔截器等 │ │ └── common/ # 統(tǒng)一返回結(jié)果、異常處理 │ └── pom.xml ├── frontend/ # Vue前端工程 │ ├── src/ │ │ ├── views/ # 頁面級組件如DormitoryManage.vue │ │ ├── components/ # 復(fù)用組件 │ │ ├── router/ # 路由配置 │ │ ├── api/ # 封裝請求 │ │ └── store/ # 全局狀態(tài)管理 │ └── package.json └── sql/ # 數(shù)據(jù)庫腳本.sql分這么清楚有個實打?qū)嵉暮锰幠憧梢栽谝粋€端口只開后端用Postman調(diào)接口也可以只開前端用Mock數(shù)據(jù)調(diào)試樣式。調(diào)試效率比單體應(yīng)用高很多出問題時也能快速定位是接口的問題還是頁面的問題。2.2 技術(shù)選型背后的真實理由很多人選型時看哪個流行選哪個我建議看哪個對當(dāng)前項目收益最高。給課設(shè)做選型時我考慮過三個問題第一為什么后端用SpringBoot而不是SSMSSM五年前是主流但配置一堆XML光Spring和MyBatis整合就夠新手喝一壺。SpringBoot把自動配置內(nèi)化你只要引入依賴、寫幾個注解就能跑起來。而且市面上絕大多數(shù)課設(shè)代碼、博客、視頻教程都基于SpringBoot遇到問題搜得到答案這一點在趕工期時能救命。第二為什么ORM層選MyBatis-Plus這里說句實在話學(xué)生宿舍管理系統(tǒng)的數(shù)據(jù)查詢復(fù)雜度不高大部分是單表操作加簡單條件查詢。MyBatis-Plus提供了一整套單表CRUD方法連SQL都不用寫內(nèi)置分頁插件也很方便。相比原生MyBatis要手動維護XML效率高出不止一點。但它不是萬能藥后面講多表聯(lián)查時你會看到什么時候該放棄它、直接手寫SQL。第三為什么前端選Vue而不是React對做課設(shè)的同學(xué)來說Vue的中文資料和Element UI/Element Plus這類現(xiàn)成組件庫是核心優(yōu)勢。你不需要自己手寫一個好看的后臺管理界面直接拿組件庫拼頁面一天的活兒能縮到兩小時。這不是投機取巧而是工程上正常的復(fù)用思維。2.3 版本選擇SpringBoot、JDK、Vue三者搭配是最大的坑我見過太多人死在這上面所以單獨拉一節(jié)說。搜索熱詞里springboot版本太高能上熱搜真不是沒道理?，F(xiàn)在常見的搭配有兩套項目保守方案推薦課設(shè)用較新方案JDK1.817SpringBoot2.7.x3.xMyBatis-Plus3.5.x3.5.x注意兼容Vue2.6 Vue CLI3.x ViteUI庫Element UIElement Plus兩套方案都能做出完整項目但如果你用新教程配合老代碼或者反過來多半會撞上javax和jakarta的報錯。SpringBoot 3.x把javax.servlet改成了jakarta.servlet很多老代碼的import javax.*直接失效。所以我的建議是項目開始之前先定死版本清單寫進文檔里。這一步能幫你省掉后面至少兩天的排錯時間。3. 數(shù)據(jù)庫是整套系統(tǒng)的地基表結(jié)構(gòu)與初始化數(shù)據(jù)怎么設(shè)計說句可能得罪人的話我看了不少課設(shè)源碼很多能跑的系統(tǒng)數(shù)據(jù)庫表設(shè)計是站不住腳的。要么把所有信息塞進一張大寬表要么外鍵關(guān)系混亂要么字符集不是utf8mb4導(dǎo)致中文亂碼。數(shù)據(jù)庫設(shè)計得不好后面每個功能寫起來都別扭。3.1 核心表的關(guān)系網(wǎng)用戶、學(xué)生、宿舍、樓棟先理清核心實體。以我常用的方案為例最終表控制在10張以內(nèi)但關(guān)系清晰sys_user賬號表存登錄名、密碼BCrypt加密、角色admin/manager/student和學(xué)生表是一對一或一對零。t_student學(xué)生表存學(xué)號、姓名、性別、學(xué)院、班級、手機號、當(dāng)前宿舍ID其中學(xué)號是天然的業(yè)務(wù)主鍵。t_building樓棟表存樓棟名稱、可容納人數(shù)等。t_dormitory宿舍表存樓棟ID、房間號、樓層、床位數(shù)、當(dāng)前已住人數(shù)。t_bed床位表把床位單獨拆一張表。宿舍和床位是一對多每個床位有獨立的狀態(tài)字段。這樣做的好處是分配時可以精確到床位而不是只能整個宿舍一起分配也為后續(xù)調(diào)宿、退宿留出了清晰的狀態(tài)流轉(zhuǎn)空間。至于業(yè)務(wù)表常見的有t_repair報修、t_hygiene衛(wèi)生檢查、t_leave請假或晚歸登記、t_transfer調(diào)宿申請。它們都有共同點一個業(yè)務(wù)主鍵、一個關(guān)聯(lián)的外鍵字段、一個狀態(tài)字段、一條時間線。這里我特別想強調(diào)一點外鍵到底加不加。課設(shè)里我建議不加數(shù)據(jù)庫外鍵約束而是把關(guān)聯(lián)關(guān)系放在代碼層維護。原因有二第一MyBatis-Plus這種框架對數(shù)據(jù)庫外鍵沒有特殊支持真正維護關(guān)系的是業(yè)務(wù)代碼第二有外鍵約束后做刪除和批量初始化數(shù)據(jù)時會遇到一堆順序依賴的麻煩。但不加外鍵不代表不設(shè)計關(guān)系關(guān)系在表和字段層面就已經(jīng)定了外鍵約束只是物理層的保護。3.2 一份能從頭執(zhí)行到底的SQL建庫、建表、灌數(shù)據(jù)源碼數(shù)據(jù)庫文檔三件套里數(shù)據(jù)庫往往是最容易被忽略、最后又最影響驗收的一環(huán)。我給你一個建議交付的SQL腳本必須是從頭到尾能完整執(zhí)行的包含建庫、建表、插入初始化數(shù)據(jù)三個部分。很多同學(xué)導(dǎo)出數(shù)據(jù)庫時只導(dǎo)出了表結(jié)構(gòu)和業(yè)務(wù)數(shù)據(jù)評審老師拿到手根本起不來。我的SQL腳本按這個順序組織先建庫CREATE DATABASE dormitory DEFAULT CHARACTER SET utf8mb4;。注意字符集指定utf8mb4光寫utf8在MySQL 5.7之后依然可能出問題。按依賴順序建表sys_user→t_building→t_dormitory→t_bed→t_student→ 各業(yè)務(wù)表。插入初始化數(shù)據(jù)至少包含一個admin賬號、一個宿管賬號、兩三個學(xué)生賬號以及幾條樓棟和床位數(shù)據(jù)。這里有個經(jīng)驗初始化數(shù)據(jù)的密碼記得統(tǒng)一比如都是123456并且用同一種加密算法生成方便演示時登錄。不要在文檔里寫密碼請自行查看這種話那等于給驗收環(huán)節(jié)添堵。3.3 讓統(tǒng)計報表不那么難寫的兩個小技巧宿舍系統(tǒng)很難避開統(tǒng)計功能入住率、各樓棟人數(shù)、報修完成率。如果每次統(tǒng)計都要在代碼里寫一大段循環(huán)去查數(shù)據(jù)庫既慢又丑。我常用的做法是兩個層面配合一是增加冗余字段。在t_dormitory表里放一個已住人數(shù)字段每次分配或退宿時在同一個事務(wù)里同步更新床位狀態(tài)和宿舍已住人數(shù)。查詢匯總時直接對已住人數(shù)求和不需要實時count床位表。你可能會問冗余字段不怕數(shù)據(jù)不一致嗎怕所以在同一個事務(wù)內(nèi)更新t_bed和t_dormitory一致性就有保證。二是復(fù)雜統(tǒng)計直接用SQL的GROUP BY加聚合函數(shù)不要在Java代碼里算。比如按樓棟統(tǒng)計人數(shù)一行SQL就能解決SELECT b.id, b.name, COUNT(s.id) AS stu_count FROM t_building b LEFT JOIN t_student s ON b.id s.building_id LEFT JOIN sys_user u ON s.student_no u.username WHERE u.role student AND s.status 1 GROUP BY b.id, b.name;這種SQL寫完放進Mapper的Select注解里比在Service層寫循環(huán)高效得多答辯時也更講得清楚。4. 從學(xué)生端到管理端權(quán)限與核心業(yè)務(wù)模塊的實現(xiàn)邏輯骨架和數(shù)據(jù)庫搭好之后該解決系統(tǒng)怎么運轉(zhuǎn)的問題了。這一章講三個核心實現(xiàn)邏輯分別對應(yīng)三個最容易答辯翻車的點登錄鑒權(quán)、宿舍分配、狀態(tài)類業(yè)務(wù)流轉(zhuǎn)。4.1 登錄鑒權(quán)前后端分離下我是誰的問題傳統(tǒng)單體應(yīng)用可以用Session前后端分離后我更推薦用JWT做無狀態(tài)鑒權(quán)。流程很簡單用戶輸入賬號密碼后端校驗通過后生成一個JWT字符串里面帶上用戶ID和角色通過接口返回給前端。前端把token存起來之后每次請求都在Header里帶上Authorization: Bearer token。后端寫一個攔截器統(tǒng)一攔截除登錄接口之外的請求解析并校驗token通過后放行不通過返回401。注意幾個細節(jié)。密碼不要明文存儲用BCrypt或MD5加鹽。課設(shè)用BCrypt更顯專業(yè)Spring Security里自帶BCryptPasswordEncoder但不想引入完整Security框架的話也可以單獨引入Spring Security Crypto的依賴只拿它的加密工具類。token有效期建議設(shè)24小時引入Redis做黑名單會更專業(yè)但對課設(shè)場景來說屬于超綱也容易把自己繞暈可以不引入。攔截器的實現(xiàn)參考這樣Component public class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); // 校驗token合法則把用戶信息放入request上下文 // 不合法則返回401并終止請求 return true; } }記得在配置類里注冊攔截器并且放行/api/login和靜態(tài)資源路徑。這個配置遺忘率非常高很多人部署后頁面打不開就是因為靜態(tài)資源被攔截器攔了。4.2 宿舍分配床位狀態(tài)機和并發(fā)問題宿舍分配是整個系統(tǒng)里業(yè)務(wù)邏輯最像樣的部分也是答辯老師最喜歡深挖的地方。一個學(xué)生申請入住時怎么保證他拿到的床位真的是空的如果兩個管理員同時操作會不會把同一個床位分給兩個人我的方案是給床位加狀態(tài)字段并在分配事務(wù)里做條件更新。床位的狀態(tài)機是0-空閑可以被分配1-已入住不可分配2-維修中不可分配分配的核心邏輯是先根據(jù)宿舍ID查可用的空閑床位然后用帶狀態(tài)條件的SQL去更新boolean success bedMapper.updateByCondition( // 設(shè)置新狀態(tài) new Bed().setStatus(1).setStudentId(studentId), // 條件為床位ID匹配且當(dāng)前狀態(tài)為0 new LambdaQueryWrapperBed() .eq(Bed::getId, bedId) .eq(Bed::getStatus, 0) ) 0;關(guān)鍵在于WHERE id? AND status0。如果返回更新行數(shù)為0說明床位已經(jīng)被別人搶走了本次分配失敗重新選擇床位即可。這其實就是樂觀鎖的思路不需要引入分布式鎖用數(shù)據(jù)庫自帶的行鎖就能解決。調(diào)宿和退宿都是在這個狀態(tài)機上做流轉(zhuǎn)。退宿把床位狀態(tài)還原為空閑同時清空學(xué)生ID關(guān)聯(lián)。把關(guān)鍵約束放在數(shù)據(jù)庫字段和更新條件里比在Java代碼里寫一堆if-else要穩(wěn)得多。4.3 報修、衛(wèi)生檢查這類狀態(tài)流轉(zhuǎn)業(yè)務(wù)怎么做學(xué)生報修→宿管查看→維修處理→學(xué)生確認(rèn)這類流程本質(zhì)上就是一張表加上一個狀態(tài)字段的流轉(zhuǎn)區(qū)別只在于哪個角色能改狀態(tài)。實現(xiàn)時我建議統(tǒng)一返回格式{ code: 200, message: 操作成功, data: {} }前端用Axios統(tǒng)一攔截解析code并做提示后端用RestControllerAdvice做全局異常處理。這樣一來報修模塊、衛(wèi)生模塊、請假模塊都可以復(fù)用同一套結(jié)構(gòu)和邏輯代碼量能壓縮不少。表單提交前前端做一次必填校驗和手機號格式校驗后端接口再做一次非空和長度校驗雙保險。千萬別只做前端校驗因為接口是可以被直接調(diào)用的。這是一個非?；A(chǔ)但常見的扣分點。5. 把前端打包塞進SpringBoot從本地聯(lián)調(diào)到服務(wù)器部署代碼寫完了最折騰人的其實是怎么讓前后端真正跑在一起。我見過太多項目在本地跑得好好的一到部署就崩。這一章把聯(lián)調(diào)、跨域、部署三個環(huán)節(jié)說透。5.1 跨域問題前端端口和后端端口八字不合的根源開發(fā)環(huán)境下前端跑在localhost:8080后端跑在localhost:9090端口不同瀏覽器的同源策略就會攔下請求這就是跨域。解決辦法有兩種第一種后端直接加CORS配置類允許前端地址訪問。寫一個WebMvcConfigurer配置類重寫addCorsMappings方法允許所有來源和所有請求方法即可。這種方式簡單直觀適合課設(shè)。第二種前端用Vite或Vue CLI的代理功能把/api開頭的請求代理到后端地址。開發(fā)期用代理更接近生產(chǎn)環(huán)境改接口地址時不用動前端代碼。這兩種方式我都試過開發(fā)期推薦代理生產(chǎn)期推薦直接打包進后端同源部署整個系統(tǒng)只有一個地址沒有跨域問題。5.2 兩種打包部署方式先看懂再選擇第一種是Vue打包放進SpringBoot。在frontend目錄執(zhí)行npm run build得到dist目錄把里面的靜態(tài)文件復(fù)制到后端src/main/resources/static下然后重新打包后端的jar。這樣整個系統(tǒng)只有一個jar包里面既包含后端接口也包含前端頁面。部署時用java -jar dormitory.jar就能跑非常省事。對應(yīng)的前端請求接口的地址不要寫死成http://localhost:9090/api應(yīng)該用相對路徑/api這樣在同一個Tomcat下才不出問題。第二種是前后端分離部署。后端jar包跑在9090端口前端dist目錄交給Nginx托管Nginx配置反向代理把/api請求轉(zhuǎn)發(fā)給9090的SpringBoot進程。這種部署方式更貼近真實企業(yè)環(huán)境適合在文檔里寫未來可擴展性也方便把靜態(tài)資源獨立管理。但如果你在校期間沒有云服務(wù)器用第一種方式就足夠了。這里直接給出一份Nginx靜態(tài)托管加反向代理的關(guān)鍵配置server { listen 80; server_name your_domain_or_ip; root /usr/share/nginx/html/dist; index index.html; location /api/ { proxy_pass http://127.0.0.1:9090; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }5.3 部署時的常見問題端口、數(shù)據(jù)庫連接、配置文件部署踩坑主要集中在三件事端口被占用Linux服務(wù)器上用netstat -tlnp查端口找到占用8080或9090的進程處理掉。Windows下對應(yīng)的是netstat -ano加任務(wù)管理器但服務(wù)器大概率是Linux。數(shù)據(jù)庫連接不上大概率是數(shù)據(jù)庫地址寫成了localhost而客戶端和數(shù)據(jù)庫不在同一臺機器。把application.yml里的url改成服務(wù)器的IP或內(nèi)網(wǎng)地址并確認(rèn)3306端口在防火墻或安全組里放行。配置文件分環(huán)境我的習(xí)慣是application-dev.yml和application-prod.yml兩套配置啟動時用--spring.profiles.activeprod指定。課設(shè)雖然不強制但這個習(xí)慣寫在文檔里評委印象分會高不少。6. 配套文檔怎么寫答辯才不至于一問三不知標(biāo)題里的三件套源碼和數(shù)據(jù)庫都聊完了最后說文檔。我見過不少學(xué)生代碼寫得不錯文檔卻很糟糕答辯時只能干巴巴地說我用了SpringBoot和Vue。文檔其實是給評委的第一印象在答辯中占的比重有時候比代碼本身還高。6.1 課設(shè)文檔的黃金結(jié)構(gòu)從需求到驗證一脈相承不要從網(wǎng)上下一個萬能模板套上去而是圍繞邏輯主線自證合理性。我的建議順序是需求分析把系統(tǒng)用戶和用例列清楚。學(xué)生能干什么、宿管能干什么、管理員能干什么。這是整份文檔的根基。系統(tǒng)設(shè)計畫整體架構(gòu)圖前后端分離、標(biāo)注技術(shù)棧再加數(shù)據(jù)庫ER圖和表結(jié)構(gòu)說明。表結(jié)構(gòu)說明要包含字段名、類型、是否主鍵、含義。評委不一定逐行看代碼但會掃一眼表設(shè)計是否合理字段命名是否規(guī)范。核心模塊設(shè)計選兩三個最能體現(xiàn)技術(shù)能力的模塊深入寫比如宿舍分配的并發(fā)控制、JWT鑒權(quán)流程。這里是你得分的地方一定要把為什么這么設(shè)計寫出來。系統(tǒng)實現(xiàn)與測試貼關(guān)鍵界面截圖和接口測試結(jié)果順帶寫一個簡單的測試用例表比如測試正常分配、測試重復(fù)分配、測試權(quán)限攔截。總結(jié)與展望一兩句話帶過即可重點是實現(xiàn)了什么、還能優(yōu)化什么。不要寫我相信該系統(tǒng)具有良好的應(yīng)用前景這種空話改成后續(xù)可引入消息隊列處理報修通知這種具體方向。6.2 答辯演示的節(jié)奏核心鏈路優(yōu)先別從登錄頁開始講20分鐘答辯演示是很多同學(xué)忽略的環(huán)節(jié)。我的經(jīng)驗是按核心鏈路演示不要按菜單順序演示。菜單順序演示的問題在于講者容易陷入一個個頁面的截圖流評委聽不出業(yè)務(wù)閉環(huán)。核心鏈路演示則不一樣第一步用管理員賬號登錄展示學(xué)生信息和樓棟宿舍列表說明數(shù)據(jù)如何錄入。 第二步走一遍學(xué)生入住分配床位的完整流程順便展示床位狀態(tài)的實時變化。這里是體現(xiàn)數(shù)據(jù)庫設(shè)計和業(yè)務(wù)邏輯的最好時機。 第三步用學(xué)生賬號登錄演示提交一條報修再切回宿管賬號處理這條報修只講狀態(tài)流轉(zhuǎn)。 第四步打開統(tǒng)計頁面展示入住率和報修處理率解釋這兩組數(shù)據(jù)是怎么算出來的。整個演示控制在5到8分鐘評委對系統(tǒng)業(yè)務(wù)閉環(huán)的感知會非常清晰。接著你再講設(shè)計亮點JWT、樂觀鎖、統(tǒng)一異常處理基本就是順著你的節(jié)奏走了。6.3 三件套交付前最后花半小時自查一遍交付前的自查清單我整理一份直接可用的SQL腳本能不能從空數(shù)據(jù)庫直接完整執(zhí)行不報錯初始賬號是否能正常登錄角色是否正確前端打包后的靜態(tài)文件是否已經(jīng)放進了SpringBoot的static目錄能不能在只裝JDK和MySQL的環(huán)境下用一條java -jar命令把系統(tǒng)跑起來文檔里的截圖是不是最新界面的截圖有沒有殘留舊版頁面外鍵、時區(qū)、字符集、跨域這些配置是否在文檔中有說明這半小時的檢查能幫你避免很多老師當(dāng)場打開卻發(fā)現(xiàn)跑不起來的尷尬場景。我做課設(shè)和幫朋友驗收項目時每次都跑一遍這個流程。最后再說一個小習(xí)慣在SQL腳本和接口路徑的命名上盡量保持規(guī)整和語義化接口統(tǒng)一用/api前綴表名統(tǒng)一用t_開頭。你說不上這是哪個大功能但評委翻代碼時視覺上的規(guī)整會潛移默化地影響他對你代碼質(zhì)量的判斷。這些細節(jié)積累起來就是同一套功能有人被夸工程化意識強有人被批這是玩具項目的根本區(qū)別。