每年畢業(yè)季被Spring Boot畢業(yè)設(shè)計(jì)折騰的同學(xué)不在少數(shù)。最近常有人問(wèn)到一類題目——基于Spring Boot的助農(nóng)類App設(shè)計(jì)與實(shí)現(xiàn)比如這個(gè)帆林助農(nóng)App名字聽(tīng)起來(lái)平平無(wú)奇但真正動(dòng)手做起來(lái)里面要拆解的東西還挺多。這篇文章就把這個(gè)題目從頭到尾完整過(guò)一遍從需求拆解、技術(shù)選型、數(shù)據(jù)庫(kù)設(shè)計(jì)到核心功能實(shí)現(xiàn)和踩坑記錄聊聊我整理這套項(xiàng)目時(shí)的思路和實(shí)操過(guò)程。如果你正準(zhǔn)備做類似方向的畢設(shè)或者想用Spring Boot快速落地一個(gè)帶完整業(yè)務(wù)閉環(huán)的小型應(yīng)用這篇內(nèi)容應(yīng)該能省你不少摸索的時(shí)間。這個(gè)項(xiàng)目表面上是做一個(gè)App實(shí)際上考察的是三件事你對(duì)業(yè)務(wù)需求的理解能力、數(shù)據(jù)庫(kù)建模的功底以及Spring Boot后端接口的完整開發(fā)能力。它不是一個(gè)純粹的CRUD玩具也不是復(fù)雜的分布式系統(tǒng)而是剛好卡在有真實(shí)業(yè)務(wù)邏輯、有完整閉環(huán)、又不至于失控的位置上。下面按我的實(shí)操順序一層層拆開講。1. 項(xiàng)目背景與需求拆解1.1 助農(nóng)App要解決的現(xiàn)實(shí)問(wèn)題助農(nóng)類應(yīng)用的核心矛盾是農(nóng)產(chǎn)品上行難。產(chǎn)地農(nóng)戶手里有好貨但銷售渠道有限往往要依賴中間商層層壓價(jià)消費(fèi)者想買產(chǎn)地直供的農(nóng)產(chǎn)品又找不到可靠的信息入口和購(gòu)買渠道。帆林助農(nóng)App這個(gè)題目本質(zhì)就是做一個(gè)連接農(nóng)戶、消費(fèi)者和平臺(tái)管理方的交易撮合平臺(tái)順便把農(nóng)業(yè)資訊、產(chǎn)品展示這類內(nèi)容也承載起來(lái)。理解了業(yè)務(wù)背景你就知道這個(gè)題目不能只做電商系統(tǒng)的換皮而是要體現(xiàn)助農(nóng)這個(gè)特殊場(chǎng)景。比如農(nóng)戶入駐認(rèn)證、農(nóng)產(chǎn)品審核上架、產(chǎn)地信息展示這些都是普通電商系統(tǒng)里不太會(huì)強(qiáng)調(diào)、但在助農(nóng)場(chǎng)景里必須有的環(huán)節(jié)。答辯時(shí)老師最常問(wèn)的就是你的系統(tǒng)解決了什么真實(shí)問(wèn)題這幾點(diǎn)能答上來(lái)項(xiàng)目立意就立住了。1.2 用戶角色與業(yè)務(wù)流程這個(gè)系統(tǒng)涉及三類角色消費(fèi)者C端買家瀏覽商品、加購(gòu)物車、下單、支付模擬、確認(rèn)收貨、評(píng)價(jià)。農(nóng)戶B端賣家提交入駐認(rèn)證、發(fā)布農(nóng)產(chǎn)品、管理商品上下架、處理訂單發(fā)貨。平臺(tái)管理員管理端審核農(nóng)戶入駐、審核商品信息、管理商品分類和資訊內(nèi)容、查看平臺(tái)數(shù)據(jù)統(tǒng)計(jì)。典型業(yè)務(wù)流程是農(nóng)戶注冊(cè)后提交入駐資料 → 管理員審核通過(guò) → 農(nóng)戶發(fā)布農(nóng)產(chǎn)品填寫價(jià)格、庫(kù)存、圖片等 → 管理員審核商品 → 商品在消費(fèi)者端上架展示 → 消費(fèi)者瀏覽下單 → 模擬支付 → 農(nóng)戶發(fā)貨 → 消費(fèi)者確認(rèn)收貨并評(píng)價(jià)。這個(gè)流程跑通系統(tǒng)的主線閉環(huán)就完成了。剩下的是資訊、收藏、輪播圖、公告這類外圍功能屬于錦上添花但必要的模塊。1.3 功能需求清單整理在動(dòng)手寫代碼之前我建議先把功能清單用表格列出來(lái)后期開發(fā)時(shí)對(duì)照著勾選進(jìn)度能避免漏功能。模塊角色核心功能點(diǎn)賬號(hào)與權(quán)限全部手機(jī)號(hào)注冊(cè)/登錄、JWT鑒權(quán)、角色區(qū)分、用戶禁用首頁(yè)消費(fèi)者輪播圖、推薦商品、助農(nóng)資訊、公告商品消費(fèi)者分類篩選、關(guān)鍵字搜索、商品詳情、多圖展示購(gòu)物車消費(fèi)者添加、刪除、改數(shù)量、選擇結(jié)算訂單消費(fèi)者/農(nóng)戶生成訂單、模擬支付、取消、發(fā)貨、確認(rèn)收貨、評(píng)價(jià)農(nóng)戶入駐與商品管理農(nóng)戶入駐申請(qǐng)、發(fā)布商品、上下架、編輯、查看訂單管理后臺(tái)管理員用戶管理、入駐審核、商品審核、分類管理、資訊管理、數(shù)據(jù)統(tǒng)計(jì)資訊模塊消費(fèi)者/管理員文章列表、詳情、點(diǎn)贊、后臺(tái)發(fā)布功能清單確定后再談技術(shù)方案就有的放矢了。項(xiàng)目規(guī)模控制在能做完整閉環(huán)、代碼量適中、答辯講得清楚的程度不需要盲目堆功能。2. 技術(shù)選型與整體架構(gòu)2.1 為什么選Spring Boot而不是別的框架標(biāo)題里已經(jīng)指定了Spring Boot但你可以想清楚為什么非它不可。最直接的原因是Spring Boot簡(jiǎn)化了Spring和SpringMVC那一大堆XML配置內(nèi)嵌Tomcat打一個(gè)jar包就能跑開發(fā)效率高。對(duì)畢設(shè)來(lái)說(shuō)你不需要理解底層容器的復(fù)雜機(jī)制只要按照約定把依賴引入、配置寫好接口就能快速搭起來(lái)。有人會(huì)問(wèn)為什么不用SSMSpring SpringMVC MyBatisSSM不是不行但配置繁瑣是公認(rèn)的。Spring Boot在SSM的基礎(chǔ)上做了自動(dòng)裝配讓你把精力集中在業(yè)務(wù)代碼上。還有一個(gè)回答思路如果題目沒(méi)有明確限制用Spring Boot說(shuō)明你關(guān)注主流技術(shù)棧貼合現(xiàn)在企業(yè)級(jí)項(xiàng)目的實(shí)際開發(fā)方式這個(gè)理由在答辯時(shí)是加分項(xiàng)。至于微服務(wù)架構(gòu)比如Spring Cloud Alibaba我不建議在畢設(shè)里硬上。咱們這個(gè)App的單體應(yīng)用規(guī)模拆微服務(wù)純屬給自己挖坑服務(wù)注冊(cè)、配置中心、網(wǎng)關(guān)、分布式事務(wù)每一樣都要額外配置和排查演示時(shí)一旦某個(gè)服務(wù)沒(méi)起來(lái)整個(gè)項(xiàng)目就癱了。單體應(yīng)用把模塊劃分清楚一樣能體現(xiàn)設(shè)計(jì)能力。2.2 前端方案怎么選帆林助農(nóng)App的App字眼容易讓人誤解以為必須做原生Android或iOS應(yīng)用。實(shí)際上國(guó)內(nèi)畢設(shè)里絕大多數(shù)App項(xiàng)目走的是這三條路Uniapp跨端開發(fā)一套代碼編譯成安卓App、iOS App和小程序演示時(shí)拿手機(jī)掃碼或者H5瀏覽器里直接跑方便。微信小程序原生開發(fā)面向微信生態(tài)審核和演示都簡(jiǎn)單但只能作為小程序存在嚴(yán)格說(shuō)不算App。Vue移動(dòng)端H5通過(guò)瀏覽器訪問(wèn)配合打包工具可以套殼成App。從答辯演示的角度我更推薦Uniapp或者H5。管理后臺(tái)則用Vue做PC端頁(yè)面配上Element Plus組件庫(kù)。這里有個(gè)經(jīng)驗(yàn)用戶端和管理后臺(tái)的前端項(xiàng)目是兩套代碼很多人第一次寫會(huì)被前端折騰瘋。如果前端基礎(chǔ)一般用戶端用原生微信小程序其實(shí)很穩(wěn)——它依賴少、調(diào)試直接、教程多。管理后臺(tái)用Vue加Element Plus有幾個(gè)現(xiàn)成的后臺(tái)模板可以參照但不要直接套用企業(yè)級(jí)腳手架因?yàn)榇疝q時(shí)老師追問(wèn)里面的業(yè)務(wù)邏輯答不上來(lái)會(huì)很尷尬。2.3 后端工程結(jié)構(gòu)與目錄規(guī)劃后端代碼的包結(jié)構(gòu)我建議這樣劃分com.fanlin.app ├── common # 統(tǒng)一返回結(jié)果、異常處理、常量定義 ├── config # CORS配置、WebMvc配置、Swagger配置 ├── controller # 接口層只做參數(shù)接收和結(jié)果封裝 ├── service # 業(yè)務(wù)層核心邏輯都在這里 │ └── impl ├── mapper # MyBatis Plus的Mapper接口 ├── entity # 數(shù)據(jù)庫(kù)實(shí)體類 ├── dto # 前端傳入的請(qǐng)求參數(shù)對(duì)象 ├── vo # 返回給前端的展示對(duì)象 ├── util # JWT工具類、文件上傳工具類等 └── interceptor # 登錄攔截器這個(gè)分層的好處是職責(zé)清晰Controller不寫業(yè)務(wù)邏輯Service不直接操作數(shù)據(jù)庫(kù)Mapper只負(fù)責(zé)數(shù)據(jù)訪問(wèn)。答辯時(shí)老師如果問(wèn)為什么Controller這么薄你可以直接說(shuō)業(yè)務(wù)邏輯集中在Service層方便復(fù)用和事務(wù)管理這也是團(tuán)隊(duì)開發(fā)中常見(jiàn)的分層約定。依賴方面核心就這幾樣Spring Boot Web、MyBatis Plus、MySQL驅(qū)動(dòng)、Redis存token緩存、Swagger接口文檔、Lombok簡(jiǎn)化實(shí)體類。Redis如果不熟也可以先去掉把token存在內(nèi)存或數(shù)據(jù)庫(kù)里但加上Redis并在答辯時(shí)說(shuō)清楚用Redis管理token過(guò)期時(shí)間是明顯加分項(xiàng)。3. 數(shù)據(jù)庫(kù)設(shè)計(jì)3.1 核心表結(jié)構(gòu)與設(shè)計(jì)思路數(shù)據(jù)庫(kù)設(shè)計(jì)是我在這個(gè)項(xiàng)目里花心思最多的地方。表結(jié)構(gòu)設(shè)計(jì)得好后面寫代碼會(huì)非常順暢設(shè)計(jì)得差代碼里到處是補(bǔ)丁式的查詢邏輯。下面把核心表逐一過(guò)一遍。用戶表user核心字段id、phone、password、nickname、avatar、role、status、create_time。角色用role區(qū)分0代表消費(fèi)者1代表農(nóng)戶2代表管理員。這里有一個(gè)值得注意的點(diǎn)是否要單獨(dú)建角色表我的建議是畢設(shè)階段不需要。獨(dú)立的角色權(quán)限表雖然更規(guī)范但對(duì)這個(gè)項(xiàng)目來(lái)說(shuō)很多余反而增加聯(lián)表查詢。用int字段存角色配合常量類定義完全夠用且直觀。農(nóng)戶入駐表farmer核心字段id、user_id、real_name、farm_name、region、description、id_card、audit_status、audit_remark、create_time。農(nóng)戶入駐審核是這個(gè)項(xiàng)目區(qū)別于普通電商的地方。想成為農(nóng)戶賣貨必須先提交入駐資料管理員審核通過(guò)后才有權(quán)限發(fā)布商品。audit_status字段設(shè)計(jì)為0待審核、1通過(guò)、2駁回。審核駁回時(shí)把原因?qū)戇M(jìn)audit_remark農(nóng)戶端就能看到為什么沒(méi)通過(guò)這是一個(gè)很務(wù)實(shí)的交互設(shè)計(jì)。商品表product核心字段id、product_name、category_id、main_image、images、price、original_price、stock、sales、unit、origin_place、description、farmer_id、status、is_recommend、create_time、update_time。這里有兩個(gè)細(xì)節(jié)值得說(shuō)。第一main_image和images為什么分開存儲(chǔ)列表頁(yè)只需要顯示一張主圖而詳情頁(yè)需要多張輪播圖。如果列表也去讀取完整的圖片數(shù)組會(huì)增加無(wú)用數(shù)據(jù)傳輸分成兩個(gè)字段后列表查詢和詳情查詢可以各取所需。第二status字段表示商品的審核與展示狀態(tài)統(tǒng)一為0待審核、1已上架、2已下架、3已駁回。注意審核和上架是兩件事這個(gè)狀態(tài)機(jī)我們放到后面小節(jié)細(xì)說(shuō)。購(gòu)物車表cart核心字段id、user_id、product_id、quantity、checked。check字段用來(lái)記錄當(dāng)前條目是否被勾選結(jié)算這是電商常見(jiàn)做法。下單時(shí)只處理勾選狀態(tài)的條目這樣用戶可以把暫不想買的商品留在購(gòu)物車?yán)?。訂單表order核心字段id、order_no、user_id、farmer_id、total_amount、freight_amount、pay_amount、status、receiver_name、receiver_phone、receiver_address、remark、create_time、pay_time、ship_time、finish_time。訂單表是整個(gè)系統(tǒng)最核心的表。order_no使用時(shí)間戳加隨機(jī)數(shù)的策略生成唯一訂單號(hào)指望MySQL自增主鍵暴露給前端不安全也不美觀自研訂單號(hào)生成規(guī)則在答辯時(shí)也是一個(gè)可講的亮點(diǎn)。farmer_id字段表示該筆訂單歸屬哪個(gè)農(nóng)戶商家端查訂單直接按這個(gè)字段過(guò)濾不用做復(fù)雜的多級(jí)關(guān)聯(lián)。訂單明細(xì)表order_item核心字段id、order_id、product_id、product_name、product_image、price、quantity、total_price。訂單明細(xì)為什么要冗余商品名稱、圖片和價(jià)格因?yàn)樯唐沸畔⑽磥?lái)可能修改或者下架但歷史訂單不能跟著變。下單那一刻的商品快照信息要存下來(lái)這在數(shù)據(jù)設(shè)計(jì)中叫冗余存儲(chǔ)換取歷史可追溯老師很認(rèn)這個(gè)點(diǎn)。其他外圍表分類表categoryid、category_name、parent_id支持二級(jí)分類。地址表addressid、user_id、receiver_name、receiver_phone、province、city、district、detail、is_default。資訊表articleid、title、cover、content、author、view_count、like_count、status、create_time。評(píng)價(jià)表reviewid、order_id、product_id、user_id、content、rating、images、create_time。輪播圖表bannerid、image、link_url、sort、status。公告表noticeid、title、content、status、create_time。表數(shù)量控制在10張左右不要貪多。每張表都要有存在的理由如果某個(gè)功能模塊用不上寧可砍掉也不要硬建表否則維護(hù)成本和冗余字段會(huì)讓你后期頭疼。3.2 商品與訂單的狀態(tài)機(jī)設(shè)計(jì)狀態(tài)字段用int而不是字符串這是我在項(xiàng)目里堅(jiān)持的一個(gè)約定。字符串可讀性雖然好但容易拼寫出錯(cuò)且難以擴(kuò)展int配合常量類代碼里寫ProductStatus.ON_SALE這種語(yǔ)義化引用既安全又清晰。商品狀態(tài)流轉(zhuǎn)路徑是待審核 → 已上架 / 已駁回 → 已上架 → 已下架。審核駁回后農(nóng)戶可以修改信息重新提交審核此時(shí)狀態(tài)回到待審核。訂單狀態(tài)流轉(zhuǎn)路徑是待付款 → 待發(fā)貨 → 待收貨 → 已完成。此外還有兩個(gè)分支待付款時(shí)可以取消取消后訂單進(jìn)入已取消狀態(tài)農(nóng)戶在待發(fā)貨狀態(tài)也可以取消訂單。設(shè)計(jì)狀態(tài)機(jī)時(shí)我給自己的忠告是不要為了顯示高級(jí)而把狀態(tài)切得過(guò)于細(xì)碎比如已發(fā)貨和已到達(dá)分開對(duì)于這個(gè)項(xiàng)目沒(méi)有意義徒增代碼分支。狀態(tài)細(xì)粒度以滿足業(yè)務(wù)表達(dá)為準(zhǔn)四個(gè)訂單狀態(tài)加一個(gè)取消狀態(tài)已經(jīng)能覆蓋整個(gè)交易閉環(huán)。3.3 索引與性能設(shè)計(jì)數(shù)據(jù)量小的時(shí)候索引的作用看不出來(lái)但你得養(yǎng)成建索引的意識(shí)。我在這些字段上建立了索引order表order_no建唯一索引user_id建普通索引farmer_id建普通索引。product表category_id建普通索引farmer_id建普通索引status建普通索引。cart表user_id建普通索引。這樣做的原因是在訂單查詢、商品列表篩選、購(gòu)物車列表等高頻場(chǎng)景里走索引比全表掃描快很多。答辯時(shí)如果能主動(dòng)說(shuō)出我在訂單表的user_id和farmer_id上建了索引因?yàn)橛唵蔚牟樵內(nèi)肟诨径紡倪@兩個(gè)字段進(jìn)來(lái)這一句話就足以體現(xiàn)你懂性能優(yōu)化而不是只會(huì)寫CRUD。另外把商品列表接口做成只返回必要的字段不要每次查詢都把description這種長(zhǎng)文本帶出來(lái)詳情接口再單獨(dú)返回完整信息。這個(gè)接口設(shè)計(jì)上的瘦身思路效果非常直接。4. 核心功能實(shí)現(xiàn)與實(shí)操過(guò)程4.1 用戶登錄與JWT鑒權(quán)實(shí)現(xiàn)登錄鑒權(quán)我選擇JWT配合攔截器的方式。為什么不用Spring Security因?yàn)镾pring Security對(duì)畢設(shè)項(xiàng)目來(lái)說(shuō)太重了配置繁瑣概念又多答辯時(shí)如果被問(wèn)到底層過(guò)濾器鏈很容易卡殼。JWT自己寫一個(gè)工具類加一個(gè)攔截器總共不到一百行代碼邏輯一目了然而且前端拿到token之后在請(qǐng)求頭里攜帶非常貼合現(xiàn)在主流的前后端分離模式。用戶登錄的流程是前端傳手機(jī)號(hào)和密碼 → 后端校驗(yàn)賬號(hào)密碼 → 校驗(yàn)通過(guò)后用用戶信息生成token返回給前端 → 前端把token存起來(lái) → 后續(xù)請(qǐng)求在請(qǐng)求頭加Authorization → 后端攔截器解析token并校驗(yàn) → 校驗(yàn)通過(guò)放行并把userId放到請(qǐng)求上下文里。JWT工具類的核心代碼大致是這個(gè)樣子public class JwtUtil { private static final String SECRET fanlin-app-secret-key; private static final long EXPIRE 1000 * 60 * 60 * 24 * 7; // 7天 public static String generateToken(Long userId, String role) { return Jwts.builder() .claim(userId, userId) .claim(role, role) .setExpiration(new Date(System.currentTimeMillis() EXPIRE)) .signWith(SignatureAlgorithm.HS256, SECRET) .compact(); } public static Claims parseToken(String token) { return Jwts.parser() .setSigningKey(SECRET) .parseClaimsJws(token) .getBody(); } }攔截器里做的事情是從請(qǐng)求頭取出token嘗試解析如果失敗就返回401如果成功就把userId和role寫入request的attribute里供Controller取用。注意項(xiàng)目里有三個(gè)角色攔截器做成可配置的比如農(nóng)戶相關(guān)的接口需要農(nóng)戶角色才能訪問(wèn)這個(gè)可以在注解或者攔截路徑上做文章簡(jiǎn)單可控。這里有一個(gè)非常關(guān)鍵的細(xì)節(jié)登錄接口、商品列表、商品詳情、輪播圖這些不需要登錄就能訪問(wèn)的接口必須在攔截器配置里明確放行否則前端一打開首頁(yè)就報(bào)未登錄排查起來(lái)要花半天時(shí)間。4.2 農(nóng)產(chǎn)品發(fā)布與圖片上傳實(shí)現(xiàn)農(nóng)戶發(fā)布商品時(shí)圖片上傳是第一個(gè)要處理的功能。上傳方案我選擇了最穩(wěn)妥的本地存儲(chǔ)MultipartFile接收文件保存到服務(wù)器指定目錄再把訪問(wèn)URL存入數(shù)據(jù)庫(kù)。為什么不直接上對(duì)象存儲(chǔ)對(duì)畢設(shè)來(lái)說(shuō)本地存儲(chǔ)加Nginx靜態(tài)資源映射已經(jīng)能完美解決展示需求不依賴第三方服務(wù)演示時(shí)也不會(huì)因?yàn)橥饩W(wǎng)環(huán)境問(wèn)題導(dǎo)致圖片加載失敗。如果項(xiàng)目方或者導(dǎo)師要求用云存儲(chǔ)那是另一個(gè)故事但先跑通本地方案永遠(yuǎn)是第一步。上傳接口的核心邏輯PostMapping(/upload) public R upload(RequestParam(file) MultipartFile file) { if (file.isEmpty()) { return R.error(文件不能為空); } String originalFilename file.getOriginalFilename(); String ext originalFilename.substring(originalFilename.lastIndexOf(.)); String fileName UUID.randomUUID().toString().replace(-, ) ext; String datePath new SimpleDateFormat(yyyyMMdd).format(new Date()); String dirPath uploadPath / datePath /; File dir new File(dirPath); if (!dir.exists()) { dir.mkdirs(); } file.transferTo(new File(dirPath fileName)); return R.ok().put(url, /files/ datePath / fileName); }這里我做了兩件事一是用UUID重命名文件防止用戶傳的文件名重復(fù)覆蓋二是按日期分目錄存儲(chǔ)避免單個(gè)目錄文件堆積過(guò)多。URL里的/files前綴通過(guò)WebMvcConfigurer配置映射到實(shí)際磁盤路徑這樣前端訪問(wèn)圖片時(shí)就是一個(gè)標(biāo)準(zhǔn)的HTTP地址不用暴露服務(wù)器絕對(duì)路徑。圖片上傳還有幾個(gè)細(xì)節(jié)要處理限制文件大小Spring Boot默認(rèn)單文件最大1MB商品圖通常要調(diào)大到5MB或10MB記得在配置文件里設(shè)置限制文件類型只允許jpg、png、webp這些常見(jiàn)格式防止有人上傳可執(zhí)行文件文件后綴校驗(yàn)不能只看文件名最好再驗(yàn)證文件頭不過(guò)畢設(shè)做到后綴校驗(yàn)加后綴白名單已經(jīng)足夠交代。4.3 購(gòu)物車與下單流程實(shí)現(xiàn)購(gòu)物車的增刪改查本身不復(fù)雜真正體現(xiàn)業(yè)務(wù)功底的是下單邏輯。這里最核心的問(wèn)題是如何防止超賣也就是兩個(gè)人同時(shí)下單時(shí)庫(kù)存不會(huì)出現(xiàn)負(fù)數(shù)。我采用的方案是樂(lè)觀的原子更新SQL。下單時(shí)不是先查庫(kù)存再更新而是直接執(zhí)行一條條件更新語(yǔ)句UPDATE product SET stock stock - 1 WHERE id #{productId} AND stock 0這條語(yǔ)句里AND stock 0就是關(guān)鍵的防線只有在庫(kù)存還有剩余時(shí)才允許扣減同時(shí)UPDATE本身是行級(jí)鎖操作多用戶并發(fā)也不會(huì)互相覆蓋。如果受影響行數(shù)為0說(shuō)明庫(kù)存不足直接拋出業(yè)務(wù)異常提示商品庫(kù)存不足。下單的整體業(yè)務(wù)邏輯放在一個(gè)被Transactional注解包裹的Service方法里流程為根據(jù)購(gòu)物車勾選的條目和商品ID查詢商品信息。校驗(yàn)商品狀態(tài)是否為已上架。計(jì)算訂單總金額。執(zhí)行扣減庫(kù)存的原子更新。生成訂單主表和訂單明細(xì)分表數(shù)據(jù)。清空對(duì)應(yīng)的購(gòu)物車條目。這六步必須在一個(gè)事務(wù)里任何一步失敗都要整體回滾否則會(huì)出現(xiàn)庫(kù)存扣了但訂單沒(méi)生成或者訂單生成了但購(gòu)物車沒(méi)清這種數(shù)據(jù)不一致的問(wèn)題。下單接口的Service核心邏輯可以這樣表達(dá)Transactional(rollbackFor Exception.class) public Order createOrder(Long userId, ListLong cartIds, Long addressId) { // 1. 查詢購(gòu)物車條目 ListCart carts cartMapper.selectBatchIds(cartIds); if (CollectionUtils.isEmpty(carts)) { throw new BizException(購(gòu)物車沒(méi)有選中商品); } // 2. 遍歷生成訂單明細(xì)計(jì)算總額 // 3. 扣減庫(kù)存原子更新防止超賣 // 4. 保存訂單主表 // 5. 保存訂單明細(xì) // 6. 刪除購(gòu)物車條目 }事務(wù)之所以要用rollbackFor Exception.class是因?yàn)镾pring默認(rèn)只對(duì)RuntimeException回滾普通的異常拋出來(lái)不會(huì)觸發(fā)回滾。我最初寫的時(shí)候沒(méi)加這個(gè)參數(shù)測(cè)試時(shí)故意觸發(fā)了一個(gè)業(yè)務(wù)異常結(jié)果發(fā)現(xiàn)訂單和庫(kù)存對(duì)不上排查了一會(huì)才意識(shí)到是這個(gè)細(xì)節(jié)。支付環(huán)節(jié)我采用的是模擬支付方案用戶下單后點(diǎn)擊立即支付后端直接把訂單狀態(tài)從待付款改成待發(fā)貨同時(shí)記錄支付時(shí)間。不要試圖對(duì)接真實(shí)支付涉及商戶號(hào)、證書、回調(diào)完全超出畢設(shè)范圍而且演示時(shí)大概率會(huì)被卡在環(huán)境配置上。4.4 管理后臺(tái)審核與數(shù)據(jù)統(tǒng)計(jì)管理后臺(tái)是很多同學(xué)容易忽視的部分覺(jué)得能登錄、能查列表就行。但事實(shí)上管理后臺(tái)承擔(dān)了平臺(tái)運(yùn)營(yíng)的所有操作它是業(yè)務(wù)閉環(huán)里不可或缺的一環(huán)。在帆林助農(nóng)App里管理后臺(tái)的核心場(chǎng)景有兩個(gè)審核和統(tǒng)計(jì)。審核功能包括農(nóng)戶入駐審核和商品審核。審核列表和詳情展示已經(jīng)通過(guò)MyBatis Plus分頁(yè)查出來(lái)了審核本身只是一次狀態(tài)更新。唯一要注意的是審核駁回時(shí)要填寫原因這個(gè)原因要展示在農(nóng)戶客戶端里。為此我在商品表和農(nóng)戶表都預(yù)留了audit_remark字段駁回時(shí)寫入原因農(nóng)戶端在我的商品或入駐狀態(tài)里能看到為什么被拒這是一個(gè)很真實(shí)的用戶體驗(yàn)設(shè)計(jì)。數(shù)據(jù)統(tǒng)計(jì)方面我在首頁(yè)數(shù)據(jù)看板做的是幾個(gè)聚合查詢// 今日新增用戶 long todayUsers userMapper.selectCount( new QueryWrapperUser() .ge(create_time, LocalDate.now()) ); // 待審核商品數(shù) long pendingProducts productMapper.selectCount( new QueryWrapperProduct().eq(status, 0) );銷售趨勢(shì)用簡(jiǎn)單的SQL按日期分組統(tǒng)計(jì)即可SELECT DATE(create_time) AS day, COUNT(*) AS order_count, SUM(pay_amount) AS total_amount FROM order WHERE status IN (1, 2, 3) AND create_time #{startDate} GROUP BY DATE(create_time) ORDER BY day我見(jiàn)過(guò)不少同學(xué)在統(tǒng)計(jì)模塊引入ECharts畫各種炫酷圖表這本身沒(méi)問(wèn)題但管理后臺(tái)如果沒(méi)有ECharts展示頁(yè)面接口數(shù)據(jù)造得再漂亮也看不到。建議先保證接口數(shù)據(jù)對(duì)再?zèng)Q定要不要加圖表。演示時(shí)一個(gè)清晰的數(shù)據(jù)概覽大屏確實(shí)加分前提是頁(yè)面加載速度不被海量數(shù)據(jù)拖垮。5. 常見(jiàn)問(wèn)題與踩坑實(shí)錄5.1 跨域與攔截器的組合坑前后端分離后跨域問(wèn)題基本必現(xiàn)。最典型的現(xiàn)象是瀏覽器控制臺(tái)報(bào)No Access-Control-Allow-Origin header is present。解決辦法是在后端配一個(gè)CORS配置類設(shè)置允許的來(lái)源、方法、請(qǐng)求頭。但更隱蔽的問(wèn)題是加了攔截器之后前端發(fā)送OPTIONS預(yù)檢請(qǐng)求時(shí)也會(huì)被攔截器攔下來(lái)。因?yàn)镃ORS預(yù)檢請(qǐng)求不帶業(yè)務(wù)token攔截器一看到?jīng)]有Authorization頭就直接拒絕返回401前端就永遠(yuǎn)等不到真正的響應(yīng)。解決方法是攔截器里對(duì)OPTIONS請(qǐng)求直接放行if (OPTIONS.equalsIgnoreCase(request.getMethod())) { return true; }這個(gè)坑排查起來(lái)很耗時(shí)間因?yàn)槟憧春蠖巳罩救钦５那岸藚s一直報(bào)跨域錯(cuò)誤。我是在接口調(diào)試了兩輪之后才反應(yīng)過(guò)來(lái)攔截器優(yōu)先級(jí)高于CORS過(guò)濾器。如果你也遇到類似情況記得先檢查攔截器是否放行了OPTIONS。5.2 日期時(shí)間格式問(wèn)題Spring Boot返回JSON時(shí)LocalDateTime默認(rèn)序列化成數(shù)組或者帶T的格式比如2025-06-01T10:30:00前端展示很不友好。統(tǒng)一在配置文件里加上spring.jackson.date-formatyyyy-MM-dd HH:mm:ss spring.jackson.time-zoneGMT8這里時(shí)區(qū)一定要設(shè)置為GMT8否則你會(huì)發(fā)現(xiàn)數(shù)據(jù)庫(kù)里存的時(shí)間明明是中午12點(diǎn)返回給前端卻變成了凌晨4點(diǎn)。這個(gè)時(shí)區(qū)問(wèn)題是由服務(wù)器默認(rèn)時(shí)區(qū)和Jackson序列化策略共同導(dǎo)致的屬于后端這邊必須處理掉的問(wèn)題。如果項(xiàng)目里用了Date類型和LocalDateTime混合建議保持一致性盡量都使用LocalDateTime配合MyBatis Plus的字段自動(dòng)填充功能把create_time和update_time交給數(shù)據(jù)庫(kù)自動(dòng)維護(hù)可以少寫很多重復(fù)的setTime代碼。5.3 圖片上傳后訪問(wèn)404上傳接口正常返回了URL但瀏覽器訪問(wèn)時(shí)404這個(gè)問(wèn)題的根源往往在于文件確實(shí)保存到了磁盤但Spring Boot不認(rèn)識(shí)那個(gè)路徑。我的做法是在WebMvcConfigurer里加一個(gè)資源映射Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/files/**) .addResourceLocations(file: uploadPath /); }注意結(jié)尾的斜杠不能省略u(píng)ploadPath是絕對(duì)路徑。另一個(gè)隱蔽問(wèn)題是Linux部署后如果uploadPath配置成相對(duì)路徑程序的工作目錄不同會(huì)導(dǎo)致文件保存到意料之外的文件夾。建議在配置文件里用一個(gè)絕對(duì)路徑或者在啟動(dòng)時(shí)動(dòng)態(tài)獲取項(xiàng)目根目錄拼接避免環(huán)境差異帶來(lái)的困擾。5.4 事務(wù)不生效前面提過(guò)事務(wù)和庫(kù)存扣減這里單獨(dú)再說(shuō)一個(gè)經(jīng)典場(chǎng)景同類的內(nèi)部方法調(diào)用事務(wù)注解會(huì)失效。例如在OrderService里一個(gè)方法調(diào)用同類里的另一個(gè)被Transactional標(biāo)注的方法這個(gè)標(biāo)注不會(huì)生效因?yàn)镾pring的事務(wù)是通過(guò)代理對(duì)象實(shí)現(xiàn)的內(nèi)部調(diào)用走的是this對(duì)象而不是代理對(duì)象。排查這個(gè)問(wèn)題的思路是把事務(wù)方法放到獨(dú)立的Service類里通過(guò)注入的方式調(diào)用或者確保事務(wù)方法的調(diào)用入口就是外部Controller調(diào)用的那個(gè)public方法。我在寫項(xiàng)目時(shí)把下單的整個(gè)事務(wù)邏輯集中在一個(gè)方法里避免嵌套調(diào)用既省心又清晰。5.5 分頁(yè)插件的配置遺漏MyBatis Plus的分頁(yè)查詢依賴分頁(yè)插件很多剛上手的人只加了依賴卻忘了配置PaginationInnerInterceptor結(jié)果發(fā)現(xiàn)Page對(duì)象返回的total永遠(yuǎn)是0記錄永遠(yuǎn)是全部數(shù)據(jù)。這個(gè)問(wèn)題我翻了半天文檔才確認(rèn)。正確做法是在配置類里注冊(cè)Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }分頁(yè)插件注冊(cè)后用Page對(duì)象查列表total和records才會(huì)準(zhǔn)確。否則你沒(méi)法在管理后臺(tái)做真正的分頁(yè)展示商品一多頁(yè)面會(huì)卡。6. 給做類似題目的同學(xué)的實(shí)操建議把一套完整的項(xiàng)目從零搭完我的體會(huì)是順序很重要。建議的推進(jìn)順序是先數(shù)據(jù)庫(kù)建模再后端接口再管理后臺(tái)最后做用戶端頁(yè)面。數(shù)據(jù)庫(kù)建模是地基地基不穩(wěn)后面全是返工。我見(jiàn)過(guò)一上來(lái)就寫Controller的同學(xué)寫到一半發(fā)現(xiàn)表結(jié)構(gòu)缺字段連帶前端頁(yè)面、后端接口、測(cè)試數(shù)據(jù)全部推翻重來(lái)那種挫敗感很傷人。演示順序也很講究。正式答辯時(shí)我的演示路徑一定是管理后臺(tái)登錄 → 審核一個(gè)待審核商品 → 用戶端刷新看到商品上架 → 農(nóng)戶端上架另一個(gè)商品 → 用戶端下單支付 → 農(nóng)戶端看到新訂單并發(fā)貨 → 用戶端確認(rèn)收貨并評(píng)價(jià) → 管理后臺(tái)看到銷量數(shù)據(jù)變化。這個(gè)演示是一條完整的故事線每個(gè)環(huán)節(jié)都有數(shù)據(jù)聯(lián)動(dòng)比東點(diǎn)一下西點(diǎn)一下的效果好很多。關(guān)于代碼量控制如果你的目標(biāo)是功能完整、邏輯清楚、能跑通那么后端核心代碼在三千行左右是合理的。不要為了湊行數(shù)去復(fù)制大段冗余代碼老師看的是邏輯和思路不是代碼數(shù)量。把注釋寫清楚尤其是下單、審核這類核心業(yè)務(wù)方法里的注釋比多寫三百行樣板代碼管用得多。最后說(shuō)一個(gè)心態(tài)問(wèn)題。做畢設(shè)最怕的不是不會(huì)寫代碼而是拖延和返工。你把這個(gè)題目拆成四個(gè)階段需求設(shè)計(jì)、數(shù)據(jù)庫(kù)、后端接口、前端頁(yè)面每完成一個(gè)階段就是實(shí)打?qū)嵉倪M(jìn)度。帆林助農(nóng)App這個(gè)題目之所以值得做是因?yàn)樗鼧I(yè)務(wù)真實(shí)、閉環(huán)完整、難度適中技術(shù)棧又貼近行業(yè)主流。只要踏踏實(shí)實(shí)走完一遍你收獲的不僅是一個(gè)能通過(guò)答辯的系統(tǒng)更是對(duì)Spring Boot項(xiàng)目從零到一全過(guò)程的理解這種理解在后續(xù)無(wú)論是工作還是深入學(xué)習(xí)中都能復(fù)用上。