簡介本資源是一套基于Spring Boot開發(fā)的校園閑置物品交易系統(tǒng)完整源碼面向Java后端初學者、高校課程設計學生及Web全棧學習者旨在解決校園內(nèi)書籍、電子設備等閑置物品流通效率低、信息不對稱的問題。壓縮包共1565個文件33.16MB涵蓋106個核心Java業(yè)務邏輯與控制器類、84個Vue前端組件如IndexHeader.vue、BreadCrumbs.vue等、306個JS交互腳本、88個CSS/SCSS樣式文件、98個JPG/PNG圖片及SVG圖標資源以及MyBatis映射XML、Spring Boot配置YML、SQL建表語句等關鍵工程文件結(jié)構(gòu)清晰、模塊解耦便于理解MVC分層與前后端分離實踐。已有90人下載學習可直接導入IDE運行完整包含用戶認證、商品發(fā)布瀏覽、在線聊天協(xié)商、交易評價及后臺管理等閉環(huán)功能附帶Lombok簡化、RESTful接口設計、密碼哈希存儲等工程化實踐細節(jié)是掌握Spring Boot企業(yè)級開發(fā)流程的優(yōu)質(zhì)參考項目。1. 項目概述與核心價值最近在整理硬盤翻出來一個幾年前在學校時做的項目源碼包名字就叫“基于Spring Boot的校園閑置物品交易系統(tǒng)代碼.zip”。當時為了畢業(yè)設計和積累實戰(zhàn)經(jīng)驗吭哧吭哧搞了小半年從需求分析、技術(shù)選型到編碼部署踩了不少坑也攢下不少心得。這個系統(tǒng)本質(zhì)上是一個服務于校園內(nèi)師生的C2C二手交易平臺核心目標就是解決“宿舍里東西越堆越多畢業(yè)時一堆帶不走又舍不得扔”的痛點。你想一本九成新的專業(yè)教材、一個只用過幾次的健身器材、一張閑置的校園卡對原主人可能是負擔但對學弟學妹可能就是寶貝。這個系統(tǒng)就是為這種高頻、小額、基于信任的校內(nèi)交易場景而生的。為什么用Spring Boot現(xiàn)在回頭看這個選擇依然非常正確。對于當時還是學生、開發(fā)資源和時間都有限的我們來說Spring Boot那種“開箱即用”的特性簡直是救命稻草。它把Spring生態(tài)里那些繁瑣的XML配置、依賴管理、服務器部署都簡化了讓我們能把精力集中在業(yè)務邏輯本身而不是在環(huán)境搭建上折騰一周。這個項目麻雀雖小五臟俱全涵蓋了用戶管理、商品發(fā)布、搜索瀏覽、在線聊天、訂單交易、后臺管理等完整模塊是一個非常好的全棧實踐樣本。無論你是想學習Spring Boot如何在實際項目中落地還是想了解一個交易系統(tǒng)的核心架構(gòu)設計甚至是打算自己動手做一個類似的校園應用這份代碼和背后的思考過程或許都能給你一些直接的參考。2. 系統(tǒng)整體架構(gòu)與核心設計思路2.1 為什么選擇單體分層架構(gòu)打開項目代碼你會發(fā)現(xiàn)它采用的是經(jīng)典的MVC分層架構(gòu)并且是單體應用。這在當時是經(jīng)過權(quán)衡的。很多同學可能會問現(xiàn)在不是都流行微服務嗎為什么不用這里就涉及到技術(shù)選型的一個核心原則合適優(yōu)于時髦。對于一個校園內(nèi)的閑置物品交易系統(tǒng)它的典型特征包括用戶規(guī)模有限通常在一所學校內(nèi)幾千到幾萬用戶、業(yè)務邏輯相對直接、并發(fā)峰值可預測例如開學季、畢業(yè)季、開發(fā)和運維團隊極小甚至就1-2個人。在這種情況下引入微服務帶來的服務拆分、獨立部署、分布式事務、鏈路監(jiān)控等復雜度是得不償失的。它會讓開發(fā)、測試和部署的成本呈指數(shù)級上升。因此我們采用了單體分層架構(gòu)清晰劃分了職責控制層Controller接收前端HTTP請求進行參數(shù)校驗和基本格式化然后調(diào)用服務層最后返回JSON數(shù)據(jù)。這一層要盡量薄不做業(yè)務邏輯。服務層Service這是業(yè)務邏輯的核心所在地。所有與交易、用戶、商品相關的規(guī)則比如發(fā)布商品的條件、下單時的庫存檢查、聊天權(quán)限驗證等都在這里實現(xiàn)。數(shù)據(jù)訪問層Repository/Mapper負責與數(shù)據(jù)庫對話使用MyBatis或Spring Data JPA來執(zhí)行CRUD操作。這一層要保證高效和純凈只關心數(shù)據(jù)的存取。實體層Entity/Domain定義與數(shù)據(jù)庫表映射的Java對象是數(shù)據(jù)流動的載體。這種架構(gòu)的好處是結(jié)構(gòu)清晰、開發(fā)簡單、易于調(diào)試并且對于這個量級的應用性能完全足夠。所有的代碼都在一個工程里用Maven或Gradle就能構(gòu)建扔到一臺服務器上就能跑起來非常適合快速迭代和初期驗證。2.2 技術(shù)棧選型背后的邏輯技術(shù)選型不是堆砌最火的技術(shù)而是為業(yè)務目標選擇最合適的工具。這個項目的技術(shù)棧是這么考慮的核心框架Spring Boot 2.1.x選擇2.1.x這個當時穩(wěn)定的版本而非最新的快照版是為了避免踩坑。Spring Boot的自動配置、內(nèi)嵌Tomcat、Starter依賴管理是基礎。我們特別用到了它的spring-boot-starter-webWeb開發(fā)、spring-boot-starter-data-jpa數(shù)據(jù)訪問、spring-boot-starter-security安全初期簡單用后期可擴展和spring-boot-starter-websocket實現(xiàn)實時聊天。持久層Spring Data JPA Hibernate為什么用JPA而不是更靈活的MyBatis對于這個業(yè)務模型相對穩(wěn)定、以對象操作為主的項目JPA的ORM對象關系映射能力可以極大減少編寫重復的SQL代碼。通過定義實體類如User,Product,Order和Repository接口就能完成大部分數(shù)據(jù)操作。OneToMany、ManyToOne這些注解能清晰地表達用戶和商品、訂單之間的關系。當然對于復雜的統(tǒng)計查詢我們也會在Repository中使用Query注解寫原生SQL兼顧靈活與便捷。數(shù)據(jù)庫MySQL 5.7關系型數(shù)據(jù)庫是交易類系統(tǒng)的基石ACID特性對于保證交易數(shù)據(jù)的一致性至關重要。MySQL成熟、穩(wěn)定、社區(qū)資源豐富是毫無懸念的選擇。我們設計了大概十幾張表核心包括用戶表、商品表、商品分類表、訂單表、聊天消息表、收藏表等。前端技術(shù)Thymeleaf模板引擎 Bootstrap jQuery考慮到項目初期需要快速出原型并且團隊成員后端背景更強我們沒有采用前后端分離的Vue/React而是用了Spring Boot天然集成的Thymeleaf模板引擎來渲染頁面。這樣做的好處是開發(fā)速度快前后端耦合在同一個項目里調(diào)試方便。頁面樣式用Bootstrap框架能快速搭建出美觀、響應式的界面。交互邏輯用jQuery補充。這雖然看起來“不現(xiàn)代”但對于一個MVP最小可行產(chǎn)品來說是最高效的方式。如果項目發(fā)展壯大完全可以重構(gòu)為前后端分離。緩存與搜索初期未引入但預留了設計在最初的版本中考慮到校園用戶量和商品量我們沒有引入Redis或Elasticsearch。但我們在設計時做了預留。例如商品服務查詢熱門分類的方法上我們加了Cacheable注解的注釋說明未來可以接入Spring Cache抽象層用Redis做后端緩存。對于商品搜索我們使用了數(shù)據(jù)庫的LIKE查詢這顯然效率不高在代碼注釋中明確指出了這是性能瓶頸優(yōu)化方案是接入Elasticsearch進行全文檢索。注意技術(shù)選型文檔化非常重要。我們在項目的README.md和一個專門的DESIGN.md文件里記錄了為什么做這些選擇以及未來可能的演進方向。這不僅是給隊友看的更是給幾個月后的自己看的。3. 核心業(yè)務模塊拆解與實現(xiàn)細節(jié)3.1 用戶系統(tǒng)不僅僅是注冊登錄用戶模塊是起點但絕不僅僅是/register和/login兩個接口。實體設計Entity public class User { Id GeneratedValue(strategy GenerationType.IDENTITY) private Long id; private String username; // 學號/工號唯一標識 private String password; // 加密存儲 private String nickname; private String avatarUrl; // 頭像存儲OSS鏈接或相對路徑 private String phone; private String email; private String dormitory; // 宿舍樓信息便于線下交易 Enumerated(EnumType.STRING) private UserRole role; // 枚舉USER, ADMIN private Integer creditScore; // 信用分初始為100 private Boolean isActive; private LocalDateTime createTime; // 省略 getter/setter }這里有幾個關鍵點1. 用學號/工號作為用戶名保證了校內(nèi)身份的真實性基礎。2.password字段必須加密存儲我們用的是Spring Security的BCryptPasswordEncoder。3. 引入了creditScore信用分這是構(gòu)建信任體系的關鍵。信用分會根據(jù)交易完成情況、評價好壞而增減。注冊流程的坑 注冊時前端會發(fā)送驗證碼到用戶郵箱校內(nèi)郵箱驗證是提升真實性的好方法。我們遇到過的一個典型問題是并發(fā)注冊導致用戶名重復。即使數(shù)據(jù)庫對username字段設置了唯一索引在高并發(fā)下兩個請求可能同時通過“用戶名是否存在”的檢查然后都去插入導致其中一個失敗。我們的解決方案是在Service層方法上加Transactional注解并在檢查用戶名后立即執(zhí)行插入利用數(shù)據(jù)庫的事務隔離級別來防止這種情況。更嚴謹?shù)淖龇ㄊ鞘褂梅植际芥i但在這個場景下數(shù)據(jù)庫唯一索引結(jié)合事務已足夠。會話管理 我們沒有采用傳統(tǒng)的Session而是使用了JWTJSON Web Token。用戶登錄成功后服務端生成一個包含用戶ID和角色的JWT令牌返回給前端。前端后續(xù)請求都在HTTP Header的Authorization中攜帶這個Token。這樣做的好處是無狀態(tài)便于擴展也適合未來可能的前后端分離部署。我們使用jjwt這個庫來生成和解析Token。3.2 商品發(fā)布與管理系統(tǒng)這是系統(tǒng)的核心商品信息是否清晰、檢索是否方便直接影響用戶體驗。商品實體與狀態(tài)機Entity public class Product { Id GeneratedValue(strategy GenerationType.IDENTITY) private Long id; private String title; Lob // 大文本字段 private String description; private BigDecimal price; private String mainImageUrl; // 主圖 ElementCollection // 存儲多張圖片URL的集合 private ListString imageUrls; Enumerated(EnumType.STRING) private ProductStatus status; // 狀態(tài)AUDITING審核中、ON_SALE出售中、SOLD已售出、OFF_SHELF已下架 Enumerated(EnumType.STRING) private ProductCondition condition; // 成色NEW, LIKE_NEW, GOOD, USED ManyToOne JoinColumn(name category_id) private Category category; // 關聯(lián)分類 ManyToOne JoinColumn(name seller_id) private User seller; // 關聯(lián)賣家 private Integer viewCount 0; private LocalDateTime createTime; private LocalDateTime updateTime; }狀態(tài)設計是精髓ProductStatus這個枚舉定義了商品的生命周期。一個新商品發(fā)布后狀態(tài)是AUDITING審核中這是為了防止不良信息。管理員審核通過后變?yōu)镺N_SALE。被下單后并非立即改變狀態(tài)交易完成時變?yōu)镾OLD。賣家也可以手動OFF_SHELF。這個狀態(tài)流轉(zhuǎn)必須嚴謹比如已售出的商品不能再被下單。圖片上傳的處理 這是文件操作的典型場景。我們沒有把圖片以二進制形式存到數(shù)據(jù)庫而是使用了“對象存儲數(shù)據(jù)庫存路徑”的方式。前端通過input typefile上傳圖片。后端FileUploadController接收到MultipartFile對象。我們對文件進行校驗大小如5MB、類型僅限jpg, png、以及簡單的病毒掃描調(diào)用簡單的工具類。生成一個唯一的文件名如UUID 時間戳 后綴防止覆蓋。將文件上傳到阿里云OSS或騰訊云COS、七牛云等。在校園內(nèi)網(wǎng)環(huán)境下如果追求極致速度和零成本也可以自建一個簡單的文件服務器用Nginx做靜態(tài)資源服務但OSS省心、可靠、有CDN加速。將上傳成功后返回的公開訪問URL如https://your-bucket.oss-cn-hangzhou.aliyuncs.com/images/uuid.jpg存入數(shù)據(jù)庫的imageUrls字段。實操心得圖片上傳一定要做異步處理或至少提供進度提示。我們最初是同步上傳大圖片導致接口超時。后來改用了前端分片上傳后端異步接收的方式用戶體驗好了很多。同時一定要在OSS上設置生命周期規(guī)則定期清理那些上傳了但最終沒有關聯(lián)到任何商品的“僵尸圖片”。3.3 實時聊天功能的實現(xiàn)二手交易溝通是關鍵。站內(nèi)信太慢我們實現(xiàn)了基于WebSocket的實時一對一聊天。技術(shù)方案Spring WebSocket STOMP我們選擇了STOMP作為WebSocket的子協(xié)議因為它提供了像消息目的地Destination、訂閱Subscribe這樣的高級抽象比裸的WebSocket更易用。后端配置Configuration EnableWebSocketMessageBroker public class WebSocketConfig implements WebSocketMessageBrokerConfigurer { Override public void registerStompEndpoints(StompEndpointRegistry registry) { // 前端通過 ws://your-domain/ws 建立連接 registry.addEndpoint(/ws).setAllowedOriginPatterns(*).withSockJS(); } Override public void configureMessageBroker(MessageBrokerRegistry registry) { // 客戶端訂閱消息的前綴例如 /topic, /user registry.enableSimpleBroker(/topic, /queue); // 客戶端發(fā)送消息到服務端的前綴 registry.setApplicationDestinationPrefixes(/app); // 點對點消息前綴默認是 /user registry.setUserDestinationPrefix(/user); } }核心業(yè)務邏輯連接與認證前端建立WebSocket連接時需要攜帶JWT Token。我們通過實現(xiàn)HandshakeInterceptor接口在握手階段驗證Token并將用戶信息存入Session。消息路由我們設計了兩個主要的消息目的地。/app/chat.sendPrivateMessage用于接收前端發(fā)送的私聊消息。消息體包含recipientId接收者ID和content。/user/{userId}/queue/messages這是STOMP提供的用戶專屬隊列。服務端可以通過SimpMessagingTemplate.convertAndSendToUser()方法將消息精準推送給指定用戶。這樣就實現(xiàn)了一對一聊天。消息持久化所有聊天消息都需要存入數(shù)據(jù)庫的chat_message表包含發(fā)送者、接收者、內(nèi)容、時間、是否已讀等字段。這樣用戶離線再上線也能拉取歷史記錄。未讀消息計數(shù)這是一個提升體驗的關鍵點。當消息被接收并存儲后如果接收者不在線即沒有對應的WebSocket Session我們會在Redis或數(shù)據(jù)庫里增加他的未讀計數(shù)。當用戶上線建立連接后主動查詢未讀計數(shù)并推送。當用戶打開聊天窗口就將與對應賣家的未讀消息標記為已讀。踩過的坑連接斷開與重連網(wǎng)絡不穩(wěn)定會導致連接斷開。我們前端使用了SockJS客戶端它支持多種傳輸方式降級并自帶重連機制。后端需要處理好在SessionDisconnectEvent事件中清理用戶會話信息。集群部署問題如果未來應用部署在多臺服務器上簡單的SimpMessagingTemplate無法跨服務器推送消息。解決方案是引入消息中間件如RabbitMQ、Redis Pub/Sub作為外部的消息代理Broker讓所有服務器實例連接到同一個Broker。這就是為什么配置中用的是enableSimpleBroker內(nèi)存代理未來可以換成enableStompBrokerRelay。3.4 交易與訂單流程設計這是最需要保證數(shù)據(jù)一致性和安全性的部分。下單流程簡化版前置校驗用戶點擊“立即購買”或“加入購物車”我們系統(tǒng)是直接購買未做購物車。請求到達OrderController.createOrder。生成訂單在Service層方法上添加Transactional注解開啟事務。檢查商品是否存在且狀態(tài)為ON_SALE。檢查賣家不是自己不能買自己的東西。可選檢查庫存對于閑置品我們通常設置庫存為1。創(chuàng)建訂單對象Order狀態(tài)設為UNPAID待支付。訂單號使用“時間戳隨機數(shù)”生成確保唯一。將商品狀態(tài)更新為RESERVED已預訂或保持ON_SALE但關聯(lián)訂單ID。我們選擇了后者避免引入過多狀態(tài)。保存訂單到數(shù)據(jù)庫。支付由于是校園內(nèi)部系統(tǒng)我們實現(xiàn)了一個簡化的“模擬支付”。實際上只是調(diào)用一個支付接口改變訂單狀態(tài)為PAID已支付并記錄支付時間。真實的支付需要接入支付寶或微信的當面付、小程序支付等。發(fā)貨與確認賣家標記發(fā)貨填寫線下交易地點或快遞單號訂單狀態(tài)變?yōu)镾HIPPED已發(fā)貨。買家確認收貨后狀態(tài)變?yōu)镃OMPLETED已完成。此時觸發(fā)一系列后續(xù)操作商品狀態(tài)正式變?yōu)镾OLD。買賣雙方互相評價。根據(jù)評價結(jié)果更新雙方的creditScore信用分。事務與并發(fā)控制 在“創(chuàng)建訂單”這一步存在“超賣”風險。即同一件商品被兩個用戶同時下單。我們通過數(shù)據(jù)庫的樂觀鎖機制來解決。在商品實體中增加一個版本號字段version用Version注解。Entity public class Product { // ... 其他字段 Version private Integer version; }在更新商品狀態(tài)或庫存時SQL語句會帶上where id? and version?。如果兩個請求同時讀到同一個version第一個更新成功后version會1第二個請求再去更新時匹配不到記錄就會拋出ObjectOptimisticLockingFailureException。我們在Service層捕獲這個異常然后返回給前端“商品信息已變化請刷新重試”的友好提示。重要提醒對于交易核心鏈路所有關鍵操作下單、支付、收貨都必須有完整的日志記錄。我們?yōu)镺rder表設計了詳細的日志子表order_log記錄狀態(tài)變更的時間、操作人、原因。這在出現(xiàn)糾紛時是至關重要的證據(jù)。4. 后臺管理系統(tǒng)的關鍵實現(xiàn)后臺管理是平臺有序運行的保障主要給管理員使用。我們單獨做了一個管理后臺通過/admin/**的URL路徑進行攔截并通過用戶角色UserRole.ADMIN進行權(quán)限控制。使用Spring Security進行權(quán)限控制Configuration EnableWebSecurity public class SecurityConfig extends WebSecurityConfigurerAdapter { Override protected void configure(HttpSecurity http) throws Exception { http .authorizeRequests() .antMatchers(/admin/**).hasRole(ADMIN) // 管理員路徑需要ADMIN角色 .antMatchers(/user/**).hasAnyRole(USER, ADMIN) .antMatchers(/, /public/**).permitAll() .and() .formLogin() .loginPage(/login) // 自定義登錄頁 .permitAll() .and() .logout() .permitAll(); // 禁用CSRF以方便API測試生產(chǎn)環(huán)境應開啟并妥善處理 http.csrf().disable(); } }核心管理功能商品審核管理員查看狀態(tài)為AUDITING的商品列表可以查看詳情然后進行“通過”或“拒絕”操作。拒絕時需要填寫理由系統(tǒng)會通過站內(nèi)信或WebSocket通知賣家。用戶管理查看用戶列表可以對違規(guī)用戶進行“禁言”禁止發(fā)布商品或“封禁”禁止登錄操作。操作同樣需要記錄理由。數(shù)據(jù)統(tǒng)計簡單的數(shù)據(jù)看板展示每日新增用戶數(shù)、商品發(fā)布數(shù)、成交訂單數(shù)、熱門商品分類等。這些數(shù)據(jù)通過編寫復雜的SQL查詢語句或使用JPA的Query注解從數(shù)據(jù)庫聚合得到。如果數(shù)據(jù)量大這些統(tǒng)計查詢應移到定時任務中計算好后存入統(tǒng)計表管理員查詢時直接讀統(tǒng)計表避免拖慢運營數(shù)據(jù)庫。操作日志記錄所有管理員的關鍵操作如審核商品、管理用戶等做到有跡可循。后臺的前端我們同樣使用Thymeleaf渲染但套用了一個開源的AdminLTE后臺模板快速搭建出了帶有側(cè)邊欄、圖表、表格的友好界面。5. 系統(tǒng)部署、監(jiān)控與性能考量5.1 從開發(fā)到上線的部署流程項目開發(fā)完成后如何讓同學們訪問我們經(jīng)歷了從本地跑到服務器部署的過程。打包使用Spring Boot Maven插件打成可執(zhí)行的JAR包。mvn clean package -DskipTests生成的target/*.jar文件包含了所有依賴和嵌入的Tomcat服務器。服務器環(huán)境我們申請了一臺學校機房的Linux服務器CentOS 7?；A環(huán)境包括JDK 8或11與本地開發(fā)環(huán)境一致。MySQL數(shù)據(jù)庫并創(chuàng)建了對應的數(shù)據(jù)庫和用戶導入初始數(shù)據(jù)如商品分類?？蛇xRedis如果未來要加緩存或做Session共享。部署腳本我們寫了一個簡單的Shell腳本deploy.sh來做自動化部署。#!/bin/bash APP_NAMEsecondhand-trade JAR_PATH/path/to/your/project/target/*.jar BACKUP_PATH/path/to/backup/ LOG_PATH/path/to/logs/ # 1. 停止舊進程 echo Stopping old application... pkill -f $APP_NAME || true sleep 5 # 2. 備份舊JAR包可選 cp $JAR_PATH $BACKUP_PATH/$APP_NAME-$(date %Y%m%d%H%M%S).jar # 3. 啟動新應用 echo Starting new application... nohup java -jar $JAR_PATH --spring.profiles.activeprod $LOG_PATH/app.log 21 echo Application started. PID: $!這個腳本做了進程停止、備份和啟動。更成熟的做法是使用Docker容器化部署用Docker Compose管理應用、MySQL、Redis等服務實現(xiàn)環(huán)境隔離和一鍵啟動。配置分離我們使用Spring Boot的application-{profile}.properties功能。開發(fā)時用application-dev.properties連接本地數(shù)據(jù)庫生產(chǎn)環(huán)境用application-prod.properties連接服務器數(shù)據(jù)庫配置更嚴格的日志級別等。通過--spring.profiles.activeprod啟動參數(shù)來激活生產(chǎn)配置。5.2 基礎監(jiān)控與日志排查系統(tǒng)跑起來后怎么知道它是否健康健康檢查Spring Boot Actuator是神器。我們引入了spring-boot-starter-actuator依賴并做了一些安全配置只暴露必要的端點。這樣我們就可以通過訪問/actuator/health來查看應用健康狀態(tài)數(shù)據(jù)庫連接等通過/actuator/metrics查看一些基礎指標。日志管理我們使用Logback作為日志框架在logback-spring.xml中配置了日志格式、輸出級別生產(chǎn)環(huán)境用INFO問題排查時臨時改為DEBUG以及按天和大小滾動歸檔的策略避免日志文件撐滿磁盤。appender nameFILE classch.qos.logback.core.rolling.RollingFileAppender file${LOG_PATH}/app.log/file rollingPolicy classch.qos.logback.core.rolling.TimeBasedRollingPolicy fileNamePattern${LOG_PATH}/app.%d{yyyy-MM-dd}.%i.log/fileNamePattern maxHistory30/maxHistory timeBasedFileNamingAndTriggeringPolicy classch.qos.logback.core.rolling.SizeAndTimeBasedFNATP maxFileSize100MB/maxFileSize /timeBasedFileNamingAndTriggeringPolicy /rollingPolicy encoder pattern%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n/pattern /encoder /appender關鍵日志點我們在所有Controller的入口、Service層的重要方法尤其是交易相關、異常捕獲處都打印了日志包含用戶ID、操作類型、關鍵參數(shù)等信息。這樣當用戶反饋“下單失敗了”我們可以根據(jù)他的用戶ID和時間點快速定位到相關日志進行排查。5.3 性能優(yōu)化點分析雖然初期數(shù)據(jù)量不大但我們在設計時考慮了一些常見的性能瓶頸和優(yōu)化方向數(shù)據(jù)庫層面索引在Product表的category_id,status,create_time用于按時間排序等查詢頻繁的字段上建立了索引。在Order表的buyer_id,seller_id,status上也建立了索引。慢查詢監(jiān)控開啟MySQL的慢查詢?nèi)罩径ㄆ诜治鰧?zhí)行時間過長的SQL進行優(yōu)化比如重構(gòu)查詢、增加索引。連接池使用HikariCP作為數(shù)據(jù)庫連接池這是Spring Boot 2.x的默認選擇性能非常好。我們在application-prod.properties中調(diào)整了連接池參數(shù)如最大連接數(shù)、最小空閑連接、連接超時時間等以適應生產(chǎn)環(huán)境的并發(fā)需求。應用層面DTO與懶加載在查詢商品列表時我們不會返回完整的Product實體它關聯(lián)了賣家User對象User又有其他關聯(lián)...而是定義了一個ProductSummaryDTO只包含列表頁需要的字段標題、價格、主圖等。這避免了Hibernate的N1查詢問題。對于必須加載的關聯(lián)對象在Repository查詢方法上使用EntityGraph或?qū)慗OIN FETCH的JPQL來一次性加載避免多次查詢。緩存如前所述熱門分類、用戶基本信息等變化不頻繁的數(shù)據(jù)是引入Redis緩存的首要目標。使用Spring Cache抽象可以輕松地通過注解如Cacheable,CacheEvict來管理緩存。前端層面圖片懶加載與壓縮商品列表圖片很多我們讓前端實現(xiàn)圖片懶加載當圖片進入視口時才加載。同時要求用戶上傳的圖片在后端或OSS處理時進行適當壓縮減少傳輸體積。靜態(tài)資源CDN將CSS、JS、圖片等靜態(tài)資源放到CDN上加速訪問。6. 常見問題排查與實戰(zhàn)技巧在實際開發(fā)和運行中我們遇到了各種各樣的問題這里總結(jié)幾個典型的6.1 數(shù)據(jù)庫連接超時或中斷現(xiàn)象應用運行一段時間后控制臺偶爾會報出Communications link failure或Connection is not available的錯誤。排查與解決檢查連接池配置可能是連接池的最大空閑時間idleTimeout設置小于數(shù)據(jù)庫的wait_timeout。當連接空閑時間超過數(shù)據(jù)庫的wait_timeout數(shù)據(jù)庫會主動斷開連接而連接池并不知道再次使用這個失效連接就會報錯。確保HikariCP的idleTimeout略小于MySQL的wait_timeout。檢查網(wǎng)絡與防火墻服務器和數(shù)據(jù)庫服務器之間的網(wǎng)絡是否穩(wěn)定防火墻是否會在長時間無通信后斷開連接啟用連接保活在HikariCP配置中可以設置connectionTestQuery如SELECT 1和keepaliveTime讓連接池定期測試連接的有效性。6.2 事務失效問題現(xiàn)象在Service方法里拋出了異常但數(shù)據(jù)還是被部分保存了事務沒有回滾。原因與解決異常類型不對Spring事務默認只對RuntimeException和Error進行回滾。如果你在方法里拋出了一個Exception事務是不會回滾的。需要在Transactional注解里明確指定rollbackFor Exception.class。方法訪問權(quán)限Transactional是基于AOP代理實現(xiàn)的如果方法不是public代理可能無法生效。自調(diào)用問題在同一個類中一個沒有Transactional注解的方法A調(diào)用了同一個類中有Transactional注解的方法B事務是不會生效的。因為代理對象調(diào)用方法B時走的是類內(nèi)部調(diào)用而不是通過代理。解決方法是把方法B放到另一個Service中或者使用AopContext.currentProxy()來獲取當前類的代理對象再調(diào)用。6.3 圖片上傳失敗或訪問慢現(xiàn)象用戶上傳圖片時前端長時間等待然后報錯或者圖片上傳成功了但頁面加載非常慢。排查文件大小限制檢查Spring Boot的multipart.maxFileSize和maxRequestSize配置確保它們大于用戶上傳的圖片大小。OSS配置與網(wǎng)絡檢查OSS的Bucket權(quán)限是否為公共讀如果是存儲公開圖片。檢查服務器到OSS外網(wǎng)域名的網(wǎng)絡是否通暢?？梢試L試在服務器上用curl或wget測試上傳和下載速度。前端超時設置增加前端上傳組件的超時時間。CDN加速如果圖片訪問慢可以為OSS Bucket開啟CDN加速這樣圖片會被緩存到離用戶更近的節(jié)點。6.4 實時聊天消息丟失或重復現(xiàn)象用戶反映有時收不到消息或者同一條消息收到了兩次。排查消息持久化與發(fā)送的原子性確?！跋⒋嫒霐?shù)據(jù)庫”和“通過WebSocket發(fā)送”這兩個操作在一個事務里。如果先發(fā)送后存儲發(fā)送成功后系統(tǒng)崩潰消息就丟了。如果先存儲后發(fā)送存儲成功后發(fā)送前崩潰消息狀態(tài)會不一致。我們采用的方式是先存儲狀態(tài)為“發(fā)送中”然后嘗試發(fā)送發(fā)送成功后更新消息狀態(tài)為“已發(fā)送”如果發(fā)送失敗捕獲異常則記錄日志并可能加入重試隊列?？蛻舳讼⑷ブ貫槊織l消息生成一個唯一的ID如UUID前端在收到消息后檢查本地是否已存在該ID如果存在則丟棄。這可以解決網(wǎng)絡延遲導致的消息重復接收問題。離線消息處理用戶離線時消息應持久化到數(shù)據(jù)庫。當用戶上線后需要主動拉取所有未讀消息。這個“拉取”的時機很重要應該在WebSocket連接成功建立、并且用戶身份認證完成后立即進行。這個校園閑置物品交易系統(tǒng)的項目雖然從技術(shù)上看用的都是主流、成熟的框架組合但真正把它從零到一跑通并且能穩(wěn)定支撐幾百上千人的日常使用其中涉及的細節(jié)和思考遠比單純學習框架API要復雜。它考驗的是你將技術(shù)組合起來解決實際問題的能力包括需求分析、架構(gòu)設計、數(shù)據(jù)庫建模、業(yè)務邏輯編碼、異常處理、性能調(diào)優(yōu)乃至簡單的運維部署?；剡^頭看這段經(jīng)歷最大的收獲不是學會了某個注解怎么用而是建立了一套完整的、從問題到代碼的工程化思維。如果你正在學習Spring Boot強烈建議不要只停留在跑通Demo試著用它去構(gòu)思并實現(xiàn)一個能解決你身邊實際問題的完整應用這個過程會讓你對技術(shù)的理解深入一個層次。代碼就在那里關鍵是你如何去理解和改造它讓它為你所用。本文還有配套的精品資源點擊獲取