SpringBoot做生日商城這個題目在畢業(yè)設(shè)計里算是一個很有代表性的“常規(guī)但扎實”的選擇。不夸張地說Java方向的畢設(shè)十有八九是商城類系統(tǒng)而SpringBoot就是這些項目最主流的底座。之所以專門聊聊“慶祝生日商城”這個題目是因為它比泛泛的“電商商城”有更清晰的業(yè)務(wù)場景用戶買禮物有明確的時間節(jié)點、有場景化的推薦需求、有送祝福的心理訴求。這樣的業(yè)務(wù)邊界對做畢設(shè)來說非常重要——功能范圍明確演示效果直觀答辯也好講。這篇內(nèi)容我按做項目的完整鏈路來寫先說怎么拆需求和選型再講數(shù)據(jù)庫與核心模塊怎么設(shè)計接著是前后端聯(lián)調(diào)的思路然后是部署運(yùn)行環(huán)節(jié)的準(zhǔn)備工作最后單獨給一份答辯避坑清單。如果你正好在準(zhǔn)備這個題目的畢設(shè)或者拿到了一套完整源碼卻不知道怎么講清楚這篇內(nèi)容基本可以照著用。1. 項目核心需求拆解與整體技術(shù)選型1.1 “慶祝生日”這個場景到底在解決什么問題普通的商城系統(tǒng)核心是“用戶逛-下單-支付-收貨”而生日商城多了兩個關(guān)鍵差異一個是時間敏感生日是有明確日期的用戶需要在某個日期之前收到禮物所以訂單流程里最好有“期望送達(dá)日期”這類概念另一個是場景驅(qū)動用戶不是隨便逛逛而是帶著“給誰買、什么場合、預(yù)算多少”的需求進(jìn)來所以商品需要支持按場景、按對象、按價位篩選。這個差異直接決定了功能模塊的邊界。做畢設(shè)最忌諱的就是需求無限發(fā)散把淘寶那套功能全搬過來。生日商城的合理范圍應(yīng)該控制在用戶端注冊登錄、商品瀏覽與檢索、商品詳情、購物車、下單與訂單管理、收貨地址管理、生日日期管理、收藏與評價管理端商品管理、分類管理、訂單處理、用戶管理、輪播圖管理。再往上的優(yōu)惠券、秒殺、支付網(wǎng)關(guān)對接這些不是畢設(shè)重點做出來反而吃力不討好。這里要特別提醒一點不要為了“功能多”而把系統(tǒng)做成大雜燴。答辯時老師問“你這個系統(tǒng)解決了什么問題”“每個表是干什么的”如果你說不出清晰的業(yè)務(wù)主線功能再多也是減分項。生日商城的主線就是“創(chuàng)建一個生日事件系統(tǒng)幫你選禮物你下單禮物按時送到”——所有模塊都應(yīng)該圍繞這條主線。1.2 為什么用SpringBoot而不是其他框架這是答辯幾乎必問的問題也是在選型時就要想清楚的邏輯。SpringBoot能成為當(dāng)前Java后端開發(fā)的事實標(biāo)準(zhǔn)核心在于它把過去Spring MVC項目里大量繁瑣的配置變成了“約定優(yōu)于配置”。以前做一個SSM項目要寫web.xml、spring-mvc.xml、mybatis-config.xml還要處理jar包版本沖突SpringBoot用自動配置把這些全部弱化一個main方法就能把內(nèi)嵌Tomcat拉起來開發(fā)體驗完全不一樣。選SpringBoot而不是Spring MVC、SSH這類老框架最現(xiàn)實的原因是生態(tài)和招聘市場都倒向了SpringBoot。以后找工作簡歷上寫“熟練掌握SpringBoot”是基本門檻而寫“熟悉SSH”已經(jīng)沒人看了。對畢設(shè)來說用新主流技術(shù)做的項目在評閱時也更容易拿到“技術(shù)選型合理”的印象分。選SpringBoot還連帶決定了其他配套選型持久層框架優(yōu)先MyBatis-Plus它對單表CRUD做了封裝省去了大量手寫SQL的重復(fù)勞動同時保留了MyBatis原生的XML能力適合做復(fù)雜查詢。純MyBatis也完全沒問題但代碼量肉眼可見地多一截。前端方案如果趕進(jìn)度、想省心用Thymeleaf模板引擎做服務(wù)端渲染就夠了一個SpringBoot工程直接搞定前后端如果想在簡歷上多寫一個技能點可以用Vue 3 Element Plus做前后端分離后端出JSON接口前端單獨跑一套工程。數(shù)據(jù)庫MySQL穩(wěn)坐標(biāo)配。版本建議用MySQL 8.0以上字符集統(tǒng)一utf8mb4排序規(guī)則utf8mb4_general_ci避免中文亂碼和emoji存儲問題。權(quán)限方案畢設(shè)商城不需要上Spring Security那種重型安全框架用攔截器 Session/Token就能把“未登錄不能下單”這類業(yè)務(wù)規(guī)則實現(xiàn)清楚。如果項目用了JWT把生成令牌、校驗令牌、攔截器放行規(guī)則這三段邏輯講明白就行。項目構(gòu)建工具M(jìn)aven是標(biāo)配配好阿里云鏡像后依賴下載速度會舒服很多。這套選型組合很成熟也是市面上大部分Java畢設(shè)項目的標(biāo)配。它不是最“炫”的但一定是最容易跑通、最容易被理解、最不會在答辯時給自己挖坑的。1.3 功能模塊的拆分粒度模塊怎么拆直接決定工作量、代碼結(jié)構(gòu)和論文結(jié)構(gòu)。我的建議是拆成兩大端、六個子模塊用戶端子系統(tǒng)用戶賬號模塊——注冊、登錄、退出、個人信息修改、密碼修改。商品瀏覽模塊——首頁輪播圖、商品分類導(dǎo)航、商品列表分頁、關(guān)鍵詞搜索、商品詳情展示。生日商城還可以加“按性別/年齡/關(guān)系”的場景化推薦入口比如“送女友”“送媽媽”“送閨蜜”這種Tab。購物車模塊——加入購物車、修改數(shù)量、刪除條目、勾選結(jié)算。訂單模塊——下單填寫收貨地址、期望送達(dá)日期、備注祝福語、訂單列表按狀態(tài)分類、訂單詳情、確認(rèn)收貨、刪除訂單。生日管理模塊——添加好友/家人生日日期到日子時前端做入口提醒后端對接一個提醒邏輯。管理端子系統(tǒng)后臺管理模塊——管理員登錄、商品上架下架與編輯、商品分類維護(hù)、訂單狀態(tài)處理發(fā)貨、完成、用戶管理查看列表、禁用啟用、數(shù)據(jù)概覽簡單的訂單量、銷售額統(tǒng)計。這個粒度對一個畢設(shè)來說是恰到好處的“滿月狀態(tài)”工作量足夠撐起一篇論文的“系統(tǒng)設(shè)計”和“系統(tǒng)實現(xiàn)”章節(jié)又不會因為功能太多而讓代碼質(zhì)量失控。2. 數(shù)據(jù)庫設(shè)計與核心模塊實現(xiàn)細(xì)節(jié)2.1 核心表結(jié)構(gòu)設(shè)計思路數(shù)據(jù)庫設(shè)計是論文和答辯的重頭戲老師普遍喜歡針對表結(jié)構(gòu)提問。生日商城的數(shù)據(jù)表不需要太多但每張表的設(shè)計理由要能說清楚。我給出一個經(jīng)過驗證的、可以直接參考的表設(shè)計清單用戶表userid、username、password加密存儲、phone、email、avatar、role區(qū)分普通用戶和管理員、status是否禁用、create_time。密碼一定要加密答辯時如果老師看到明文密碼第一印象會大打折扣。商品分類表categoryid、name、parent_id支持二級分類、sort排序、icon。生日商城的分類適合按送禮對象分送女友、送男友、送父母、送朋友、送孩子也可以按商品類型分鮮花、蛋糕、飾品、玩偶、定制禮品。商品表productid、category_id、name、subtitle副標(biāo)題、main_image主圖、detail富文本詳情、price價格、stock庫存、sales銷量、status上架/下架、create_time。注意price字段用decimal(10,2)不要用float/double——這是老生常談但每次都有人踩坑浮點數(shù)算金額會出精度問題。購物車表cartid、user_id、product_id、quantity、checked是否勾選、create_time。購物車表其實可以用唯一索引(user_id, product_id)來保證同一個用戶不會對同一商品產(chǎn)生多條記錄更新數(shù)量即可。訂單表orderid、order_no訂單編號要唯一、user_id、total_amount、pay_type、status待付款/待發(fā)貨/待收貨/已完成/已取消、receiver_name、receiver_phone、receiver_address、expect_date期望送達(dá)日期、remark祝福語備注、create_time、pay_time、deliver_time、finish_time。訂單明細(xì)表order_itemid、order_id、product_id、product_name、product_image、price下單時快照價格、quantity。訂單明細(xì)里的商品名稱和價格必須做快照不能去關(guān)聯(lián)實時商品表。道理很簡單商品改名、改價、刪除后歷史訂單仍然需要還原當(dāng)時的信息。收貨地址表addressid、user_id、receiver_name、receiver_phone、province、city、district、detail、is_default。生日表birthdayid、user_id、name、birth_date生日日期、relation關(guān)系如家人、朋友、伴侶、create_time。這是生日商城區(qū)別于普通商城的特色表也是答辯時可以重點講“業(yè)務(wù)特性”的落點。2.2 訂單狀態(tài)機(jī)的設(shè)計訂單狀態(tài)是電商系統(tǒng)里最容易在答辯時被追問的點。不要只設(shè)計一個“狀態(tài)字段”要想清楚狀態(tài)之間如何流轉(zhuǎn)、誰觸發(fā)流轉(zhuǎn)、非法跳轉(zhuǎn)怎么攔截。我建議訂單狀態(tài)設(shè)計為五個狀態(tài)待付款、待發(fā)貨、待收貨、已完成、已取消。流轉(zhuǎn)邏輯是用戶提交訂單 - 待付款用戶支付或模擬支付 - 待發(fā)貨管理員后臺發(fā)貨 - 待收貨用戶確認(rèn)收貨 - 已完成待付款狀態(tài)下用戶主動取消或超時未支付自動取消 - 已取消代碼層面不要在每個狀態(tài)變更的地方散落寫狀態(tài)判斷而是抽一個OrderService.changeOrderStatus()方法統(tǒng)一處理內(nèi)部用switch或狀態(tài)集合校驗“當(dāng)前狀態(tài)是否允許變遷到目標(biāo)狀態(tài)”。這樣代碼清晰答辯講起來也很有條理。這里還有一個實操經(jīng)驗如果沒接真實支付要在“模擬支付”環(huán)節(jié)說明清楚。通常做法是訂單列表頁提供一個“模擬支付”按鈕點擊后調(diào)用一個接口把訂單狀態(tài)從待付款改成待發(fā)貨或先改成已付款再進(jìn)入待發(fā)貨。注意邏輯上不能跳狀態(tài)付款和發(fā)貨是兩回事訂單流程要能看出環(huán)節(jié)。2.3 生日提醒與場景推薦怎么實現(xiàn)生日提醒是這個項目最有“記憶點”的功能。實現(xiàn)方式不復(fù)雜用Spring自帶的定時任務(wù)Scheduled就能搞定。寫一個任務(wù)類每天凌晨掃描birthday表判斷當(dāng)天是否有即將到來的生日比如三天內(nèi)然后給對應(yīng)用戶生成站內(nèi)提醒消息或者只是在前端登錄后的首頁展示“3天后是XX的生日還沒有準(zhǔn)備禮物哦”這樣的提示。這個功能的技術(shù)含量不算高但業(yè)務(wù)亮點很強(qiáng)答辯時講出來很容易讓老師覺得“這個系統(tǒng)有自己的思考”。講的時候要強(qiáng)調(diào)兩點一是用cron表達(dá)式控制任務(wù)執(zhí)行頻率二是把“提醒規(guī)則”做成可配置的比如提前三天、提前一周而不是寫死在代碼里。場景推薦也同理不需要上什么協(xié)同過濾算法那是數(shù)據(jù)量很大的系統(tǒng)才需要考慮的事。畢設(shè)層面用標(biāo)簽關(guān)聯(lián)就行商品表加一個scene字段比如值可以是girlfriend/mother/friend前端“送女友”入口就查scene等于girlfriend的商品列表。簡單、好講、效果直觀。3. 前后端實現(xiàn)與接口聯(lián)調(diào)的關(guān)鍵細(xì)節(jié)3.1 接口風(fēng)格與統(tǒng)一返回結(jié)構(gòu)如果走前后端分離路線接口設(shè)計直接決定聯(lián)調(diào)效率。我強(qiáng)烈建議所有接口返回一個統(tǒng)一的JSON結(jié)構(gòu){ code: 200, message: 操作成功, data: { } }后端對應(yīng)定義一個Result類泛型設(shè)計靜態(tài)方法返回成功和失敗。這樣前端只處理一種結(jié)構(gòu)不用每個接口單獨判斷返回字段。Result.success(data); Result.error(商品庫存不足);配置一個全局異常處理器用RestControllerAdvice捕獲業(yè)務(wù)異常比如庫存不足、未登錄統(tǒng)一轉(zhuǎn)成Result格式返回。這不僅讓代碼干凈還能避免一堆try-catch塞在Controller里。接口路徑規(guī)劃也提前想好受RESTful風(fēng)格約束但不用過度糾結(jié)POST /api/user/register注冊POST /api/user/login登錄GET /api/product/list商品分頁列表帶categoryId、keyword、pageNum、pageSize參數(shù)GET /api/product/detail/{id}商品詳情POST /api/cart/add加入購物車GET /api/cart/list購物車列表POST /api/order/create提交訂單GET /api/order/list訂單分頁列表帶status參數(shù)PUT /api/order/{id}/cancel取消訂單PUT /api/order/{id}/receive確認(rèn)收貨POST /api/admin/product/save新增或更新商品PUT /api/admin/order/{id}/deliver發(fā)貨3.2 分頁與參數(shù)校驗分頁是列表接口的必考點SpringBoot MyBatis-Plus的組合讓分頁變得很簡單。用MyBatis-Plus的Page對象傳入pageNum和pageSize然后用selectPage查數(shù)據(jù)返回結(jié)果帶上total總數(shù)前端就能正常渲染分頁組件。參數(shù)校驗不要全靠前端后端接口一定要做基礎(chǔ)校驗。Spring Boot里可以用ValidatedNotBlank這類注解比如注冊接口必須校驗用戶名、密碼、手機(jī)號非空。這個細(xì)節(jié)很多人忽略但答辯時老師很容易隨手測一下前端攔截掉密碼為空直接調(diào)后端接口會怎樣如果后端沒有校驗、直接把空密碼存進(jìn)去這就是明顯的設(shè)計缺陷。3.3 圖片上傳怎么做商城的商品圖片是剛需。最簡單的方案是“本地存儲”上傳接口把MultipartFile保存到服務(wù)器的某個目錄比如/upload同時把該文件的訪問URL存進(jìn)數(shù)據(jù)庫。需要注意的是SpringBoot需要配置靜態(tài)資源映射否則訪問不到上傳后的文件。spring: web: resources: static-locations: classpath:/static/,file:${upload.path}這里有一個比較細(xì)節(jié)的坑Windows環(huán)境下文件路徑的斜杠和Linux不一樣最好在配置文件里單獨設(shè)置一個upload.path而不是把路徑寫死在代碼里。線上部署到Linux服務(wù)器時只需要改配置文件就完成遷移。上傳文件名也別用原始文件名用UUID.randomUUID()生成新文件名防止重名覆蓋。如果時間充裕也可以考慮用對象存儲比如MinIO來管圖片這在部署時可玩性更高但考慮到畢設(shè)核心是業(yè)務(wù)邏輯本地存儲已經(jīng)夠用。如果項目里確實要加注意對象存儲的桶、訪問權(quán)限、文件上傳大小限制這幾個配置點。3.4 前端頁面的組織方式前端如果是Vue工程頁面建議這樣組織首頁輪播圖 分類導(dǎo)航 推薦商品列表商品列表頁左側(cè)分類篩選 右側(cè)商品網(wǎng)格 分頁商品詳情頁大圖 名稱價格 庫存狀態(tài) 數(shù)量選擇 加入購物車/立即購買購物車頁勾選、改數(shù)量、結(jié)算跳轉(zhuǎn)結(jié)算頁收貨地址選擇 期望送達(dá)日期 備注留言 提交訂單訂單列表頁Tab切換不同狀態(tài) 操作按鈕付款/取消/確認(rèn)收貨個人中心我的資料、我的生日管理、我的地址后臺管理頁商品列表/編輯、訂單列表/發(fā)貨、用戶列表登錄注冊頁頁面數(shù)量不算多但覆蓋了完整的用戶路徑。演示視頻錄的時候就按這條路徑走一遍不用專門背稿注冊→登錄→加購→下單→模擬支付→后臺發(fā)貨→確認(rèn)收貨這樣一套流程走完系統(tǒng)功能已經(jīng)展示得很完整。4. 部署運(yùn)行與項目交付物準(zhǔn)備4.1 本地環(huán)境部署步驟很多拿到源碼的人第一步就卡在“跑不起來”這個鍋不全是代碼的環(huán)境配置占了大半。SpringBoot項目的本地部署順序非常重要安裝JDK版本要和pom.xml里java.version一致。SpringBoot 2.x通常要求JDK 8或11SpringBoot 3.x要求JDK 17以上。很多畢設(shè)項目用JDK 8最省事因為兼容性最廣。安裝Maven配置好settings.xml里的阿里云鏡像否則mvn下載依賴可以拖到懷疑人生。安裝MySQL執(zhí)行項目里提供的init.sql或db.sql建庫建表順便插入測試數(shù)據(jù)。修改application.yml把數(shù)據(jù)庫的URL、用戶名、密碼改成自己本機(jī)的配置。啟動項目看到“Started xxxApplication”日志出現(xiàn)說明SpringBoot啟動成功。訪問接口驗證瀏覽器打開http://localhost:8080如果前端是分離的還要啟動Vue開發(fā)服務(wù)器并且把前端請求的baseURL指向后端。我把這個寫成一份部署說明文檔是交付物里很實用的部分。提醒一句部署說明一定要自己走一遍再寫照著實際能跑通的流程截圖記錄不要寫想當(dāng)然的步驟。很多人的部署文檔和實際環(huán)境根本對不上自己復(fù)現(xiàn)一遍就會發(fā)現(xiàn)一堆小細(xì)節(jié)。4.2 前端項目的構(gòu)建與聯(lián)調(diào)如果用了Vue開發(fā)階段用npm run dev啟動開發(fā)服務(wù)器后端接口在vue.config.js或vite.config.js里配置代理proxy: { /api: { target: http://localhost:8080, changeOrigin: true } }這樣前端的/api開頭的請求會轉(zhuǎn)發(fā)到后端8080端口避免跨域問題。開發(fā)完成后用npm run build構(gòu)建靜態(tài)文件產(chǎn)出dist目錄。有兩種方式聯(lián)調(diào)一是把dist目錄放到SpringBoot的src/main/resources/static下重新打包為一個jar直接通過8080端口訪問二是用Nginx單獨部署前端靜態(tài)文件再配置反向代理把/api轉(zhuǎn)發(fā)到后端。對畢設(shè)來說第一種更省事——一個jar包搞定部署演示都方便。4.3 項目演示的準(zhǔn)備技巧交付物里的“演示視頻”看似只是錄屏其實對最終答辯有很大影響。我的建議是演示視頻錄兩遍第一遍按正常流程走——注冊、登錄、瀏覽商品、加購物車、下單、模擬支付、后臺發(fā)貨、確認(rèn)收貨第二遍錄管理端的操作——商品上下架、訂單發(fā)貨、用戶管理。錄之前把測試數(shù)據(jù)準(zhǔn)備好商品圖片選好看一點的至少保證每個分類下都有商品頁面不要空蕩蕩的。視頻里特別注意操作不要太快鼠標(biāo)指到哪就說明到哪最好邊操作邊說一句“這一步是在做什么”。因為評閱老師很可能是快進(jìn)看的如果畫面一直是他看不懂的界面印象分就沒了。4.4 論文LW的結(jié)構(gòu)組織論文和源碼是配套的論文的結(jié)構(gòu)基本跟項目結(jié)構(gòu)走。規(guī)范的畢設(shè)論文通常包含這些章節(jié)緒論背景與意義、國內(nèi)外研究現(xiàn)狀、相關(guān)技術(shù)介紹SpringBoot、MyBatis-Plus、Vue、MySQL等、系統(tǒng)需求分析可行性分析、功能需求、非功能需求、系統(tǒng)設(shè)計總體架構(gòu)、功能模塊設(shè)計、數(shù)據(jù)庫設(shè)計、系統(tǒng)實現(xiàn)關(guān)鍵模塊實現(xiàn)、核心代碼說明、系統(tǒng)測試功能測試用例、結(jié)果分析、總結(jié)與展望。寫論文最容易犯的毛病是“技術(shù)介紹寫一大堆系統(tǒng)設(shè)計一筆帶過”這是典型的比例失調(diào)。技術(shù)章節(jié)寫兩三頁就夠重點是系統(tǒng)設(shè)計里每個表和每個模塊是怎么設(shè)計出來的。數(shù)據(jù)庫表格截圖、接口調(diào)用截圖、效果截圖這些都要有論文直觀程度直接決定評閱老師的耐心。5. 畢設(shè)答辯與避坑指南5.1 技術(shù)環(huán)節(jié)的經(jīng)典問題與應(yīng)答邏輯答辯時老師不會問太高深的問題但喜歡盯著你的項目問。以下幾個問題基本必問提前把答案組織好就能穩(wěn)住場面?！盀槭裁匆肧pringBoot”——因為SpringBoot實現(xiàn)了自動配置內(nèi)嵌Tomcat服務(wù)器簡化了傳統(tǒng)SSM項目繁瑣的XML配置提高了開發(fā)效率同時SpringBoot有龐大的生態(tài)和社區(qū)支持資料多、后續(xù)擴(kuò)展方便?！坝唵螤顟B(tài)是怎么管理的”——訂單有五個狀態(tài)分別在用戶付款、管理員發(fā)貨、用戶確認(rèn)收貨時發(fā)生流轉(zhuǎn)代碼里通過OrderService統(tǒng)一處理狀態(tài)變更不合法跳轉(zhuǎn)會攔截?！懊艽a是怎么存儲的”——用MD5或BCrypt加密后再入庫不能存明文。這里推薦BCrypt自帶鹽值安全性更好。講這個點很容易給老師留下好印象因為它說明你考慮了真實系統(tǒng)的安全問題?！皫齑嬖趺捶乐钩u”——簡單的做法是在下單時判斷stock是否大于0并扣減庫存復(fù)雜一點可以加樂觀鎖/悲觀鎖。畢設(shè)層面講清楚第一種方案就夠重點是有這個意識?！岸〞r任務(wù)是怎么做的”——用Spring的Scheduled注解在配置里定義cron表達(dá)式固定時間去掃描生日表做提醒。“前端和后端是怎么交互的”——前端通過HTTP調(diào)用后端RESTful接口數(shù)據(jù)格式是JSON后端統(tǒng)一返回Result對象前端根據(jù)code字段判斷請求是否成功。5.2 實操過程中的常見問題速查我整理了一份高頻問題速查表這些都是在實際開發(fā)過程中最容易踩到的坑問題現(xiàn)象根本原因解決辦法啟動時報“Failed to configure a DataSource”數(shù)據(jù)庫連接配置不對或沒配檢查application.yml的url/用戶名/密碼Session/攔截器放行路徑配錯導(dǎo)致登錄后也進(jìn)不去攔截器攔截了登錄接口本身放行/login、/register、靜態(tài)資源路徑前端圖片不顯示靜態(tài)資源映射未配置或路徑不對檢查圖片相對路徑和資源映射配置中文亂碼數(shù)據(jù)庫表字符集不是utf8mb4建庫建表時明確指定utf8mb4依賴下載極慢或失敗Maven未配置阿里云鏡像修改settings.xml配置mirror接口返回401/403但功能正常要求未登錄攔截器/登錄校驗邏輯覆蓋了公開接口調(diào)整放行規(guī)則Vue項目build后白屏資源路徑用了絕對路徑修改vue.config.js里publicPath為相對路徑或部署到根目錄商品列表分頁total總是0沒配置MyBatis-Plus分頁插件在配置類里添加PaginationInnerInterceptor端口占用8080被別占其他進(jìn)程已監(jiān)聽修改server.port或找到占用進(jìn)程并killLinux里lsof -i:80805.3 拿到完整項目后怎么快速“吃透”哪怕是拿到了完整源碼也一定要自己過一遍代碼否則答辯時老師隨便問一個“你這個購物車表里的checked字段是干什么的”你都答不上來。我的建議是按照“表結(jié)構(gòu) → 實體類 → Mapper層 → Service層 → Controller層 → 前端頁面”這條鏈路逐層過一遍重點關(guān)注自己負(fù)責(zé)講的模塊。一個很實用的技巧是在源碼里做精簡批注。把每個Service方法的作用、每次狀態(tài)變更的位置、每張表的用途用注釋標(biāo)出來然后自己復(fù)述一遍。能做到“看著項目結(jié)構(gòu)圖就能講出完整流程”答辯基本穩(wěn)了。我不建議死記硬背代碼因為老師問的往往是“為什么”而不是“是什么”。理解每張表為什么這么設(shè)計、每個狀態(tài)為什么這樣流轉(zhuǎn)比記住某一行代碼重要得多。把關(guān)注點放在邏輯和設(shè)計上就算老師臨時問到一個沒準(zhǔn)備的問題也能根據(jù)對系統(tǒng)的理解現(xiàn)場圓回來。5.4 動手之前的幾條實在建議最后說幾條我自己帶人和輔導(dǎo)項目的實在心得。第一不要等項目“完全做好”再準(zhǔn)備論文和視頻三樣?xùn)|西同步推進(jìn)論文寫系統(tǒng)設(shè)計部分時正好可以邊寫邊檢查自己的代碼邏輯視頻則每完成一個模塊就錄一段最后剪輯拼起來避免臨交前熬夜。第二數(shù)據(jù)要“看起來真實”。商品圖片不要太敷衍哪怕從免費(fèi)圖庫下載也比純色占位圖強(qiáng)商品名稱寫得像真實的商家文案訂單狀態(tài)里造一些歷史訂單數(shù)據(jù)。演示界面好看一點評閱老師的第一感觀直接影響打分。第三部署說明、數(shù)據(jù)庫腳本、項目結(jié)構(gòu)說明這三樣?xùn)|西無論如何都要整理清楚。很多時候我們做完項目去跑別人的源碼跑不起來都不是業(yè)務(wù)問題而是鏈路沒人說明白——數(shù)據(jù)庫初始腳本沒提供、版本對不上、配置文件沒說明白。你給別人交付的時候把這幾個點寫清楚能幫對方省下大量時間。這個項目做完SpringBoot主流程、MyBatis操作、前端頁面聯(lián)調(diào)、部署打包這一整套經(jīng)驗都會過一遍該踩的坑基本都踩過了。即使以后不寫商城這套開發(fā)思維在做任何Java后端項目時都復(fù)用得上。