春招那會兒我接過不少私活其中很大一類就是幫本科生把畢業(yè)設(shè)計從能跑打磨到能答辯。做得最多的就是Spring Boot管理系統(tǒng)什么圖書借閱、宿舍管理、校園考勤換一層業(yè)務(wù)殼子骨架都大同小異。但說實話基于Spring Boot家教管理系統(tǒng)的設(shè)計與實現(xiàn)這類題目是我覺得最有業(yè)務(wù)味道、也最能體現(xiàn)設(shè)計能力的一個選題。它不像圖書管理那樣只對著CRUD猛懟里面既有用戶角色劃分、又有訂單和課時結(jié)算這種完整流程還牽扯到權(quán)限控制和時間沖突校驗。今天我就以這個題目為例子把我做這類項目的完整思路、表結(jié)構(gòu)設(shè)計、后端落地、前端聯(lián)調(diào)、以及那些文檔里絕對不會寫的坑一次性講清楚。這篇文章適合誰適合正在做家教管理系統(tǒng)畢設(shè)的同學適合想系統(tǒng)地走一遍Spring Boot全棧項目的初學者也適合接單幫別人做畢設(shè)的開發(fā)同行。我會按照真實項目的推進順序來寫從選題理由到數(shù)據(jù)庫設(shè)計從JWT鑒權(quán)到定時任務(wù)每一段都是實操后的總結(jié)不是那種只給截圖不給代碼的教程。1. 為什么我推薦用Spring Boot做家教管理系統(tǒng)選題與技術(shù)選型的真實考量1.1 家教業(yè)務(wù)的核心痛點信息不對稱與流程管理先聊一個最基礎(chǔ)的問題家教管理系統(tǒng)到底要解決什么如果你只是把它當成一個增刪改查的練習那答辯的時候很容易被問住。家教行業(yè)本質(zhì)上是一個撮合平臺牽涉到的角色至少有四類家長、學生、家教老師、平臺管理員。傳統(tǒng)模式下大家靠微信群和電話溝通信息極度分散上課時間靠口頭約定課時費算不清楚老師放鴿子了家長也沒處投訴。所以一個合格的家教管理系統(tǒng)至少要管住三件事誰來教、誰來學、怎么結(jié)算。老師和學生的匹配關(guān)系、課程的時間安排、課后的評價與課時確認這三條線是最核心的。你去看很多高分畢設(shè)論文功能列表拉得很長但業(yè)務(wù)主線也就是這三條。想明白這一點你在做需求分析的時候就不會跑偏。這也是為什么我不建議把題目改成家教信息發(fā)布系統(tǒng)或者家教預(yù)約平臺——管理這兩個字意味著你要做的不僅僅是一個信息墻而是一套有狀態(tài)流轉(zhuǎn)、有角色權(quán)限、有業(yè)務(wù)流程的后臺系統(tǒng)這恰恰是Spring Boot最擅長的領(lǐng)域。1.2 技術(shù)選型對比Spring Boot、SSM、SSH該怎么選很多同學在開題的時候會糾結(jié)學校老師讓用SSMSpring SpringMVC MyBatis我看網(wǎng)上全是Spring Boot的教程到底選哪個我的建議很直接優(yōu)先Spring Boot除非導師硬性規(guī)定SSM。理由有三個第一Spring Boot的自動配置機制幫你省掉了大量XML配置尤其是數(shù)據(jù)源、事務(wù)管理器、攔截器這些東西以前在SSM里要手寫一堆配置文件Spring Boot通過starter依賴和application.yml幾行配置全搞定了。這不是偷懶而是把精力騰出來放在業(yè)務(wù)邏輯上。第二招聘市場和開源社區(qū)早就倒向Spring Boot了你寫簡歷的時候精通Spring Boot比熟悉SSM有說服力得多。哪怕你只是做畢設(shè)用Spring Boot也是給自己攢經(jīng)驗。第三Spring Boot 2.x和3.x選誰的問題。我的建議是選2.7.x。為什么因為3.x要求JDK 17起步而且很多第三方starter的兼容性還停留在2.x時代。你如果是為了穩(wěn)定把畢設(shè)做完JDK 8 Spring Boot 2.7.x MyBatis-Plus這套組合最穩(wěn)踩坑最少。當然如果你的導師要求新那Spring Boot 3.2 JDK 17也可以但你要做好某些老教程代碼不能直接抄的心理準備。2. 需求邊界畫清楚后面寫代碼才不擰巴2.1 四類角色的權(quán)限劃分管理系統(tǒng)的核心思想就是不同人看到不同的東西。家教系統(tǒng)里我通常設(shè)置四種角色權(quán)限從上到下是角色核心操作范圍特殊能力管理員全站用戶管理、科目管理、訂單總覽強制下架違規(guī)老師、處理投訴家長發(fā)布需求、搜索老師、發(fā)起預(yù)約對已完成的課時進行確認/評價家教老師發(fā)布可授課程、查看預(yù)約、提交課時上傳資質(zhì)證明、維護可授課時間學生查看課程、提交試聽申請綁定在家長賬號下這里有個細節(jié)很多人不注意學生和家長在業(yè)務(wù)上經(jīng)常是分離的。小學生上課是家長付費、家長選老師但真正上課的是孩子。所以在數(shù)據(jù)模型里學生信息應(yīng)該獨立建表家長賬號通過student_id關(guān)聯(lián)到孩子。如果你偷懶只做一個用戶表角色字段后面做家長查看孩子的上課記錄這個功能時就會非常別扭。2.2 核心業(yè)務(wù)流從預(yù)約到授課到結(jié)算我建議你把業(yè)務(wù)流程先畫出來不是畫給答辯看是畫給自己寫代碼時理清頭緒。家教系統(tǒng)的核心鏈路通常長這樣家長搜索老師 → 按科目、區(qū)域、價格篩選家長發(fā)起預(yù)約 → 提交期望的上課時間老師確認/拒絕 → 確認后生成課程訂單實際上課完成 → 老師提交課時記錄家長確認課時 → 系統(tǒng)自動累計已確認課時結(jié)算階段 → 家長充值/支付老師申請?zhí)岈F(xiàn)這條鏈路最大的特點是存在狀態(tài)機。預(yù)約訂單的狀態(tài)至少要有待確認、已確認、已拒絕、進行中、已完成、已取消。數(shù)據(jù)庫里最好用一個status字段專門存這個狀態(tài)而不是通過刪記錄來表示取消。別小看這個設(shè)計答辯老師最喜歡問的就是訂單取消后數(shù)據(jù)怎么處理你在表里保留狀態(tài)字段直接就能答上來。2.3 容易被忽視的非功能需求很多同學做畢設(shè)只盯著功能清單結(jié)果答辯的時候被一句你這個系統(tǒng)并發(fā)怎么樣問懵。我不主張你為了畢設(shè)去搞微服務(wù)、消息隊列這種重武器但有幾個非功能需求你要心里有數(shù)參數(shù)校驗手機號格式、價格區(qū)間、時間格式后端的Validated注解不能省別把校驗全丟給前端。日志記錄操作日志表要建至少記錄誰在什么時間做了什么操作關(guān)鍵業(yè)務(wù)操作如取消訂單必須留痕。異常處理全局異常處理器要寫不然前端動不動就拿到一個帶堆棧的500頁面體驗太差。這些不是加分項而是基本素養(yǎng)。答辯老師可能不會逐行看代碼但如果你能主動說一句我用攔截器做了JWT登錄校驗用全局異常處理器統(tǒng)一了返回格式印象分直接上一個檔次。3. 數(shù)據(jù)庫設(shè)計家教系統(tǒng)的地基怎么打3.1 核心表結(jié)構(gòu)用戶、課程、訂單、課時記錄數(shù)據(jù)庫設(shè)計這一個章節(jié)在論文里能寫十幾頁但落到具體表結(jié)構(gòu)我建議你抓住五張主表和幾張輔助表user表用戶表CREATE TABLE user ( id bigint(20) NOT NULL AUTO_INCREMENT, username varchar(50) NOT NULL COMMENT 登錄賬號, password varchar(255) NOT NULL COMMENT BCrypt加密后的密碼, nickname varchar(50) DEFAULT NULL, phone varchar(20) DEFAULT NULL, role tinyint(4) NOT NULL COMMENT 1-管理員 2-家長 3-老師 4-學生, status tinyint(4) DEFAULT 1 COMMENT 1-正常 0-禁用, create_time datetime DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;teacher_profile表老師信息擴展表因為老師有科目、教學年限、認證狀態(tài)、課時費等維度單獨拆一張表更清爽用user_id關(guān)聯(lián)。course_order表預(yù)約/課程訂單表CREATE TABLE course_order ( id bigint(20) NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 訂單編號, teacher_id bigint(20) NOT NULL, student_id bigint(20) NOT NULL, parent_id bigint(20) DEFAULT NULL, subject_id bigint(20) NOT NULL COMMENT 科目, start_time datetime NOT NULL COMMENT 上課開始時間, end_time datetime NOT NULL COMMENT 上課結(jié)束時間, duration int(11) DEFAULT 2 COMMENT 課時長(小時), unit_price decimal(10,2) NOT NULL COMMENT 每小時單價, total_amount decimal(10,2) NOT NULL COMMENT 總價, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 0-待確認 1-已確認 2-已拒絕 3-進行中 4-已完成 5-已取消, create_time datetime DEFAULT NULL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;lesson_record表課時記錄表老師上完課之后提交家長確認后這個狀態(tài)才變成已完成這個表是為結(jié)算服務(wù)的。這幾張表之間的外鍵關(guān)系我不建議真的在數(shù)據(jù)庫里加物理外鍵邏輯外鍵就夠了。理由是MyBatis-Plus做聯(lián)表查詢的時候物理外鍵反而容易造成麻煩而且如果老師被刪除、但訂單還要保留歷史記錄物理外鍵會擋住這種邏輯刪除的需求。3.2 字段設(shè)計上的幾個細節(jié)決策這里分享幾個容易踩坑的點第一價格永遠用DECIMAL不要用FLOAT或DOUBLE。浮點數(shù)在計算機里是近似存儲0.1 0.2可能等于0.30000000000000004。金額字段一旦出現(xiàn)精度問題結(jié)算那一步就全亂了。DECIMAL(10,2)足夠應(yīng)付單價和總價。第二時間字段建議直接存datetime不要存字符串。有人圖方便把上課時間存成2025-06-01 14:00這種字符串后面如果要查某個時間段有哪些老師在教或者做時間沖突校驗字符串比較會把你折騰瘋。MySQL的datetime字段配合BETWEEN語句比字符串好用一百倍。第三邏輯刪除比物理刪除安全。用戶誤操作刪除了一條課時記錄如果物理刪了數(shù)據(jù)就沒了。我一般在每張業(yè)務(wù)表加一個deleted字段0/1查詢的時候默認過濾掉deleted1的記錄。MyBatis-Plus里用TableLogic注解就能自動實現(xiàn)所以這個成本極低。第四訂單號要單獨生成不要用自增ID當訂單號。自增ID暴露了業(yè)務(wù)量而且用戶看到訂單號是58這種會有種不正規(guī)感。你可以用時間戳隨機數(shù)生成訂單號比如yyyyMMddHHmmss 兩位隨機數(shù)或者直接用IdWorker.getIdStr()MyBatis-Plus自帶雪花算法實現(xiàn)一行代碼搞定。4. Spring Boot后端落地骨架搭建與關(guān)鍵接口實現(xiàn)4.1 目錄分層controller-service-mapper的職責邊界后端工程的包結(jié)構(gòu)我建議按模塊化來分而不是按層級分。什么概念按層級分是controller包下放所有Controllerservice包下放所有Service按模塊分是order包下同時有OrderController、OrderService、OrderMapper。模塊化的好處是改動一個功能時你只需要在一個包結(jié)構(gòu)內(nèi)跳轉(zhuǎn)代碼閱讀成本低很多。推薦包結(jié)構(gòu)com.example.tutor ├── common // 通用類返回結(jié)果、異常處理、常量 │ ├── Result.java │ ├── GlobalExceptionHandler.java │ └── BusinessException.java ├── config // 配置類攔截器、跨域、密碼加密器 ├── security // JWT相關(guān)TokenUtil、JwtInterceptor ├── user // 用戶模塊 │ ├── UserController.java │ ├── UserService.java │ ├── UserMapper.java │ └── entity/User.java ├── order // 訂單模塊 └── lesson // 課時模塊這里一定要記住Controller只做參數(shù)接收和結(jié)果返回不寫業(yè)務(wù)邏輯。我見過太多人把數(shù)據(jù)庫更新語句直接寫在Controller里當時寫起來爽后面調(diào)試的時候想死。Service層是核心業(yè)務(wù)邏輯全部放Service里Controller保持薄薄一層。4.2 登錄認證JWT方案在單體應(yīng)用中的實現(xiàn)家教系統(tǒng)里沒有任何一個接口可以裸奔放行除了登錄和注冊。我的做法是用JWT做無狀態(tài)認證全套流程是用戶登錄后端校驗用戶名密碼密碼用BCryptPasswordEncoder校驗。校驗通過后生成Token把用戶ID、角色封裝進Token的claims里。前端把Token存到localStorage每次請求在Authorization頭帶上。后端寫一個攔截器攔截非白名單路徑解析Token并放行。核心代碼大致是這樣Configuration public class WebConfig implements WebMvcConfigurer { Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(jwtInterceptor()) .addPathPatterns(/api/**) .excludePathPatterns(/api/auth/login, /api/auth/register, /api/subject/list); } }public class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (token null || !token.startsWith(Bearer )) { throw new BusinessException(未登錄或登錄已過期); } // 解析Token如果簽名不對或過期會拋異常 Claims claims JwtUtil.parseToken(token.replace(Bearer , )); request.setAttribute(userId, claims.get(userId)); request.setAttribute(userRole, claims.get(role)); return true; } }這里有個容易踩的坑攔截器拋異常全局異常處理器接得住嗎需要注意攔截器preHandle里拋出的異常如果你是注冊在WebMvcConfigurer里全局異常處理器是能接到的但如果你用HandlerInterceptor實現(xiàn)類里的邏輯拋了異常而你的異常處理器沒有配置對前端會收到亂碼。解決辦法是確保ControllerAdvice生效并且自定義異常類里別吞掉堆棧信息。Token如果要實現(xiàn)用戶被禁用后立刻失效光靠JWT是做不到的因為JWT是無狀態(tài)的。我提供兩個方案一是把Token有效期設(shè)短一些比如2小時配合前端重新登錄機制二是在user表加一個token_version字段每次登錄1JWT里存這個版本號服務(wù)端校驗時比對版本號。方案二在畢設(shè)里屬于亮點功能答辯可以主動講。4.3 業(yè)務(wù)接口設(shè)計的幾個原則有幾個接口設(shè)計的原則我寫代碼的時候一直在用原則一接口返回結(jié)構(gòu)要統(tǒng)一。所有接口都返回ResultT里面包含code、message、data三個字段。成功時code200失敗時code500或者業(yè)務(wù)碼。前端拿到這個結(jié)構(gòu)統(tǒng)一處理不需要每個接口單獨寫異常邏輯。原則二列表查詢千萬別只做一個findAll。分頁查詢是標配前端傳pageNum和pageSize后端用MyBatis-Plus的Page對象一行代碼就能搞定分頁public PageCourseOrder getOrderPage(Long userId, int pageNum, int pageSize) { LambdaQueryWrapperCourseOrder wrapper new LambdaQueryWrapper(); wrapper.eq(userId ! null, CourseOrder::getParentId, userId) .orderByDesc(CourseOrder::getCreateTime); return orderMapper.selectPage(new Page(pageNum, pageSize), wrapper); }LambdaQueryWrapper這個類強烈推薦使用它用lambda表達式引用列名編譯期就能查出字段名錯誤比寫字符串parent_id安全得多。原則三修改和刪除要加是本人操作校驗。比如老師想取消一個訂單你得先查出訂單里的teacher_id是不是當前登錄用戶不是就拒絕。這個邏輯雖然簡單但很多初學者會忘這是數(shù)據(jù)安全的基本底線。5. 前端聯(lián)調(diào)與打包Vue Spring Boot的協(xié)同細節(jié)5.1 接口約定與聯(lián)調(diào)環(huán)境家教管理系統(tǒng)的前端我一般用Vue 3 Element Plus理由不用多說組件成熟、文檔豐富、招聘要求里也常出現(xiàn)。前后端分離開發(fā)時最大的問題是跨域。Spring Boot后端解決跨域很簡單寫一個配置類Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOrigins(http://localhost:8081) // 前端地址 .allowedMethods(GET, POST, PUT, DELETE) .allowCredentials(true) .maxAge(3600); } }如果你用了Shiro或者Spring Security跨域配置要放行預(yù)檢請求OPTIONS不然瀏覽器先發(fā)個預(yù)檢請求被攔截你后面真正的請求壓根發(fā)不出去。前后端接口字段的命名也要提前約定好。我習慣后端返回駝峰命名比如createTime前端直接用不做轉(zhuǎn)換。MySQL里的create_time通過MyBatis-Plus的駝峰映射自動轉(zhuǎn)成createTime所以Java實體類里也是駝峰三層命名一致省去很多煩惱。5.2 Vue打包放進Spring Boot的坑與處理很多同學做完前后端分離老師卻說我要一個能直接跑的東西這時候就需要把Vue打包后放到Spring Boot里打成單jar運行。步驟很簡單在Vue項目根目錄執(zhí)行npm run build生成dist目錄。把dist里的文件復(fù)制到Spring Boot的src/main/resources/static目錄下。重新打包Spring Bootjava -jar啟動后直接訪問http://localhost:8080/就能看到前端頁面。但這里有幾個坑幾乎必踩坑一Vue路由的history模式會導致刷新404。如果你用history模式路由訪問/order/list刷新頁面時Spring Boot會把請求交給DispatcherServlet找不到對應(yīng)的/order/list接口就會返回404。解決辦法是在后端加一個路由轉(zhuǎn)發(fā)規(guī)則Controller public class RouteController { RequestMapping(value /{path:[^\\.]*}) public String forward() { return forward:/index.html; } }這個正則[^\\.]*的意思是路徑里不含點號就轉(zhuǎn)發(fā)到index.html這樣既能放行靜態(tài)資源js/css帶點號又能解決前端路由404。這個配置在畢設(shè)答辯里是一個很能加分的點因為大部分同學根本不會遇到這個問題?？佣岸苏埱蟮腂aseURL要跟部署環(huán)境適配。開發(fā)時前端代理指向http://localhost:8080打包之后前端頁面和后端同源了如果代碼里還硬編碼了http://localhost:8080部署到服務(wù)器上就廢了。我的做法是在Vue里用環(huán)境變量區(qū)分// .env.development VITE_API_BASE_URL /api // .env.production VITE_API_BASE_URL /api開發(fā)時配置Vite代理轉(zhuǎn)發(fā)生產(chǎn)時因為同源所以不需要代理。這樣代碼里就統(tǒng)一寫axios.post(${baseUrl}/order/create)不會出現(xiàn)環(huán)境切換的麻煩?？尤募蟼髀窂絼e用相對路徑。家教老師上傳資質(zhì)證明教師資格證照片很多同學會把文件保存到static/upload/目錄下這在本地跑好好的部署到服務(wù)器上就出問題。更好的做法是配置一個絕對路徑的上傳目錄通過application.yml里的file.upload-path配置然后用一個虛擬路徑映射到它Configuration public class FileConfig implements WebMvcConfigurer { Value(${file.upload-path}) private String uploadPath; Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceLocations(file: uploadPath /); } }這樣前端訪問/upload/xxx.jpg就能拿到圖片而文件本體存在服務(wù)器某個固定目錄不會因為重新打包jar而丟失。6. 實測中踩過的坑與優(yōu)化建議6.1 Spring Boot版本和依賴兼容性問題這幾個月我?guī)腿舜罱ōh(huán)境時遇到最多的報錯九成出在版本上。Spring Boot 2.7.x對應(yīng)MyBatis-Plus的mybatis-plus-boot-starter要選3.5.x但如果你用Spring Boot 3.x要求MyBatis-Plus 3.5.3以上并且包名會變從com.baomidou變到com.github.pagehelper這種邊邊角角的兼容問題則更隱蔽網(wǎng)上老教程的代碼直接復(fù)制過來多半跑不起來。我的建議是做畢設(shè)就鎖死一套經(jīng)過驗證的組合別追求最新。推薦組合如下組件推薦版本JDK1.8或11Spring Boot2.7.18MyBatis-Plus3.5.3.1MySQL驅(qū)動8.0.33Hutool5.8.xJJWT0.11.5Hutool這個工具庫我強烈推薦里面封裝了日期處理、加密、文件上傳、驗證碼生成等等常用方法能少做很多輪子。JJWT是標準的Java JWT庫0.11.5版本對JDK 8友好別去用io.jsonwebtoken:jjwt的舊坐標那是另一個坑。6.2 定時任務(wù)的實現(xiàn)與注意事項家教系統(tǒng)里天然需要定時任務(wù)比如課時開始前2小時給老師發(fā)提醒訂單超過24小時未確認自動取消月底生成賬單。Spring Boot的定時任務(wù)用Scheduled注解就夠Component public class OrderAutoCloseTask { Scheduled(cron 0 0 * * * ?) // 每小時執(zhí)行一次 public void closeExpiredOrders() { // 查詢狀態(tài)為待確認、創(chuàng)建時間超過24小時的訂單批量改為已取消 } }但凡是定時任務(wù)就避不開幾個細節(jié)一是cron表達式別寫錯。Spring Boot的cron是6段有時7段秒 分 時 日 月 周網(wǎng)上抄的表達式多半是Quartz的7段跑不起來別慌把首位去掉試試。二是定時任務(wù)默認是單線程串行執(zhí)行的。如果你有多個定時任務(wù)默認情況下它們是排隊完成的如果某個任務(wù)執(zhí)行時間過長會卡住后面的任務(wù)。要并發(fā)執(zhí)行就配置一個TaskScheduler并設(shè)置線程池大小。這個點回答系統(tǒng)如何優(yōu)化性能時可以作為一個小亮點。三是線上環(huán)境里定時任務(wù)要關(guān)注冪等性。比如自動取消超時訂單這個任務(wù)如果執(zhí)行到一半服務(wù)器重啟了重啟后任務(wù)會重新執(zhí)行你怎么保證不會重復(fù)取消我的辦法是任務(wù)執(zhí)行前判斷訂單當前狀態(tài)只有在待確認狀態(tài)才執(zhí)行取消已經(jīng)取消的跳過天然冪等。6.3 上線前要做的安全加固畢設(shè)雖然很多只需要在本地演示但如果你想把項目放到服務(wù)器上給老師遠程看以下安全措施一個都別省密碼加密禁止明文存密碼BCryptPasswordEncoder起步這個Spring Security自帶不需要引入全套Security框架單獨引入spring-security-crypto依賴即可。SQL注入防堵MyBatis-Plus的LambdaQueryWrapper參數(shù)綁定天然防注入但如果是手寫XML里的${}傳參就要小心能用#{}就別用${}。越權(quán)訪問防護JWT里存了role但后端不能只看前端傳的role每個角色接口的鑒權(quán)必須依賴攔截器里從Token解析出的角色不能信任前端請求體里的字段。限制敏感接口的請求頻率比如發(fā)送短信驗證碼、登錄接口這種加個簡單的Redis計數(shù)器限制頻率。如果項目還沒引入Redis也可以先用一個ConcurrentHashMap手動計數(shù)兜底差距區(qū)別只在分布式環(huán)境上。7. 寫在最后的項目落地個人體會這個家教管理系統(tǒng)從建表到全部功能跑通我前后花了大概四天。如果只是為自己做三天就夠剩下一天全部消耗在環(huán)境和聯(lián)調(diào)上了。給我的最大感受是寫業(yè)務(wù)系統(tǒng)的核心能力不是把代碼敲出來而是把業(yè)務(wù)關(guān)系理清楚——學生要不要單獨建表訂單狀態(tài)怎么流轉(zhuǎn)課時確認之后錢怎么算這些問題想清楚了Spring Boot只是一個順手的工具代碼寫起來非?？臁５绻阋簧蟻砭蛺烆^建工程寫CRUD后面改表的代價會教你做人。另一個實操建議是從中間表入手寫代碼不要從頭表寫起。我每次都是先做訂單表和課時記錄表因為這兩張表關(guān)聯(lián)了其他所有表把它們跑通了用戶表和科目表怎么接都順理成章。最后留一個可以當答辯加分項/擴展方向的小提示家教系統(tǒng)的推薦邏輯其實特別適合做簡單化處理比如同科目優(yōu)先、同區(qū)域優(yōu)先、價格從低到高排序就可以用一句SQL完成如果你想再深入一步還可以引入用戶評價分作為排序權(quán)重這就是一個輕量級協(xié)同過濾的雛形。這句話你寫在論文結(jié)論部分比空談未來可以接入大數(shù)據(jù)分析要具體得多也更能體現(xiàn)你真的想過系統(tǒng)演進的方向。