:從設(shè)計到部署全解析)
簡介這是一套面向計算機專業(yè)本科生及畢業(yè)設(shè)計開發(fā)者的Spring Boot二手交易平臺完整實現(xiàn)方案聚焦Web全棧開發(fā)實踐與電商類系統(tǒng)架構(gòu)訓(xùn)練。資源包含前后端分離的可運行源碼、詳細(xì)部署說明文檔及配套SQL腳本覆蓋用戶注冊登錄支持QQ/微信第三方、商品發(fā)布與搜索、訂單全流程管理、支付寶/微信支付集成、站內(nèi)信與郵件通知、JWTSSL安全防護(hù)等核心業(yè)務(wù)模塊。壓縮包共810個文件含130個Java后端邏輯文件、48個Vue前端組件、153個JS交互腳本、44個CSS/HTML頁面資源、79個GIF動效及SVG圖標(biāo)等結(jié)構(gòu)清晰便于按層學(xué)習(xí)與二次開發(fā)整體大小為16.78MB。目前已有690人下載學(xué)習(xí)適合用于課程設(shè)計、畢設(shè)選題或Spring BootVue技術(shù)棧的工程化能力提升開箱即用且具備完整交易閉環(huán)能力。 作為一個常年用 Spring Boot 折騰各種項目的人拿到二手交易平臺這種題目第一反應(yīng)是這不又是一個典型的 CRUD 練手項目嗎但真要把一個帶完整源碼、能直接部署上線、還有像樣交易閉環(huán)的平臺做出來里面的門道其實比想象中多得多。它不只是用戶注冊登錄、發(fā)個商品、下個單那么簡單支付狀態(tài)怎么流轉(zhuǎn)、商品上下架怎么處理、圖片存在哪、會話怎么保持這些問題在寫代碼的時候都會逼著你做選擇。這篇文章我會以一個實際可運行的 Spring Boot 二手交易平臺為核心把項目從需求拆解、數(shù)據(jù)庫設(shè)計、后端接口實現(xiàn)到最后的本地部署、云服務(wù)器部署甚至 Docker 打包一條線完整講透。適合正在做畢業(yè)設(shè)計、想熟悉 Spring Boot 全流程開發(fā)、或者打算接私活做商城類項目的朋友照著這篇內(nèi)容可以少走很多彎路。1. 項目整體設(shè)計與技術(shù)選型思路1.1 先想清楚二手交易平臺的本質(zhì)很多人一上來就急著重寫用戶表、商品表、訂單表但其實先想清楚業(yè)務(wù)閉環(huán)更重要。二手交易平臺和普通電商最大的區(qū)別在于買家賣家都是普通用戶沒有平臺自營、沒有商家后臺核心流程是用戶注冊登錄發(fā)布閑置商品設(shè)置價格和成色其他用戶瀏覽搜索感興趣就下單賣家看到訂單后確認(rèn)發(fā)貨買家收貨后確認(rèn)完成整個過程圍繞一件二手商品的狀態(tài)變更展開。所以設(shè)計時要把商品狀態(tài)和訂單狀態(tài)當(dāng)作兩條獨立的狀態(tài)機來看。商品有在售、下架、已賣出三種狀態(tài)訂單有待付款、待發(fā)貨、待收貨、已完成、已取消五種狀態(tài)。每一個狀態(tài)變更都要有明確的操作入口和權(quán)限校驗比如只有賣家能把商品下架只有買家能確認(rèn)收貨。把這個想明白了后面寫 Service 層的業(yè)務(wù)邏輯就很順暢。1.2 技術(shù)棧選型Spring Boot 為主前后端分離為輔這個項目我選擇的是標(biāo)準(zhǔn)的前后端分離架構(gòu)后端用 Spring Boot前端用 Vue 3 Element Plus。Spring Boot 負(fù)責(zé)提供 RESTful API前端通過 axios 調(diào)用接口渲染頁面。這樣做有好處接口可以被 PC 端、移動端、小程序等多端復(fù)用開發(fā)時前后端可以并行遇到問題排查起來也清晰后端返回 JSON前端渲染頁面誰出錯看誰。后端內(nèi)部的選型也值得一提。持久層我用了 MyBatis-Plus它和 Spring Boot 是絕配內(nèi)置的BaseMapper能把單表 CRUD 的工作量砍掉一大半分頁插件通過一個MybatisPlusInterceptor配置就能搞定實在需要手寫 SQL 的部分用Select注解寫在 Mapper 接口里就行。鑒權(quán)方案沒有用重的 Spring Security 加 OAuth2而是選擇了輕量級的 JWT在攔截器里做 Token 校驗邏輯直觀、代碼量少對中小型項目來說完全夠用。注意Spring Boot 版本建議用 2.7.x不要去追最新的 3.x。很多第三方 starter 對 3.x 的 Jakarta 命名空間適配還有坑網(wǎng)上資料也多以 2.x 為主出了問題好查。JDK 用 1.8 或 11 都行如果是 17 以上記得注意兼容性。1.3 工程結(jié)構(gòu)怎么擺才不混亂項目包結(jié)構(gòu)我按模塊分包而不是技術(shù)分包來組織這樣后期維護(hù)找文件效率高很多com.example.secondhand ├── config # 配置類CORS、攔截器、MyBatis-Plus分頁插件、文件上傳 ├── controller # 控制器層只做參數(shù)接收和結(jié)果返回 ├── service # 業(yè)務(wù)邏輯層核心業(yè)務(wù)都在這 │ └── impl # 實現(xiàn)類 ├── mapper # MyBatis-Plus 的 Mapper 接口 ├── entity # 數(shù)據(jù)庫實體類 ├── dto # 前端交互的對象登錄請求、商品發(fā)布請求等 ├── vo # 視圖返回對象統(tǒng)一響應(yīng)格式 ├── utils # 工具類JWT、MD5、文件上傳工具 └── common # 全局異常處理、返回結(jié)果封裝我見過不少人的項目所有代碼堆在幾個包下面controller 里寫 SQL、entity 里塞業(yè)務(wù)邏輯一開始覺得快后面改需求簡直想哭。模塊分包會讓每個類的職責(zé)單一controller 只負(fù)責(zé)接收參數(shù)和響應(yīng)service 只負(fù)責(zé)業(yè)務(wù)邏輯mapper 只負(fù)責(zé)數(shù)據(jù)庫操作這是 Spring Boot 項目能不能持續(xù)迭代的分水嶺。2. 數(shù)據(jù)庫設(shè)計核心表結(jié)構(gòu)與關(guān)鍵字段解析2.1 五張核心表的職責(zé)劃分?jǐn)?shù)據(jù)庫設(shè)計是整個項目的基石表結(jié)構(gòu)不合理后面寫代碼全是痛苦。二手交易平臺最小的數(shù)據(jù)集合需要五張表用戶表、商品表、訂單表、收藏表、留言表。實際擴展還可以加輪播圖表、分類表但核心五張表必須先設(shè)計好。用戶表user的核心字段包括id、username、password、nickname、avatar、phone、balance。這里balance是用戶余額用于模擬交易支付避免真實對接支付網(wǎng)關(guān)的麻煩。密碼字段只存 MD5 或 BCrypt 加密后的密文絕對不允許明文。商品表product是最重要的一張表字段包括id、user_id、title、description、price、original_price、category、condition_level、images、views、status。注意price和original_price我用的是decimal(10,2)類型用 BigDecimal 對象接收。images字段存的是 JSON 數(shù)組字符串形如[/uploads/1.jpg,/uploads/2.jpg]前端拿到后直接JSON.parse就能用省去一張圖片關(guān)聯(lián)表的開銷。訂單表order字段是id、order_no、product_id、seller_id、buyer_id、price、status、create_time、pay_time、ship_time、confirm_time。order_no是業(yè)務(wù)編號手動生成格式類似20250315123000001不要直接用自增 id 當(dāng)訂單號給用戶看會暴露平臺數(shù)據(jù)量也容易被遍歷。收藏表和留言表相對簡單主要存儲關(guān)聯(lián)關(guān)系。2.2 幾個容易忽略卻關(guān)鍵的設(shè)計細(xì)節(jié)第一所有表都加上create_time、update_time兩個時間字段MyBatis-Plus 有TableField(fill FieldFill.INSERT)配合MetaObjectHandler能自動填充省心而且排查問題時能知道每條數(shù)據(jù)是什么時候產(chǎn)生和修改的。第二商品表要有deleted邏輯刪除字段用戶下架商品不是真刪數(shù)據(jù)只是標(biāo)記刪除這樣已下單的訂單還能追溯到商品快照信息。第三金額字段的設(shè)計是最容易踩坑的地方。電商業(yè)務(wù)中金額一律用BigDecimal禁止用double和float。我在項目里親眼見過0.1 0.2 0.30000000000000004這種問題在交易場景中出現(xiàn)那真的是事故。數(shù)據(jù)庫字段用decimal(10,2)精確到分Java 實體用 BigDecimal中間任何計算都用 BigDecimal 的方法不要用運算。第四商品表中的seller_id和訂單表里的seller_id、buyer_id都屬于用戶表的外鍵但實際開發(fā)中我通常不加物理外鍵約束只加普通索引。原因很簡單物理外鍵在批量導(dǎo)入數(shù)據(jù)、邏輯刪除、分庫分表時會帶來額外開銷和約束功能上用代碼保證數(shù)據(jù)一致性就夠了項目里用邏輯外鍵是常見的做法。2.3 初始化 SQL 腳本和測試數(shù)據(jù)源碼里一定帶一個sql/init.sql里面除了創(chuàng)建數(shù)據(jù)庫和建表語句我還會預(yù)置幾條測試數(shù)據(jù)比如一個管理員賬號admin/admin123、一個普通用戶test/test123以及七八條不同分類的商品記錄圖片用占位圖路徑。這樣拿到源碼的人導(dǎo)入數(shù)據(jù)庫后一啟動項目不用注冊就能直接登錄看到效果體驗好很多。測試數(shù)據(jù)很重要因為前端頁面拿到空數(shù)據(jù)時看不出布局效果分布式部署時也方便驗證接口是否打通。我在商品表預(yù)置數(shù)據(jù)時故意讓兩條商品處于已賣出狀態(tài)這樣首頁展示已售標(biāo)簽、詳情頁展示已下架按鈕馬上能看到狀態(tài)機的作用也算是一種隱性的演示設(shè)計。3. 核心功能實現(xiàn)從登錄鑒權(quán)到訂單流轉(zhuǎn)3.1 JWT 登錄鑒權(quán)與全局?jǐn)r截器配置登錄邏輯不復(fù)雜前端提交用戶名和密碼后端校驗通過后生成一個 JWT 返回給前端前端存在 localStorage 里以后每次請求在 header 里帶上Authorization: Bearer token后端攔截器解析 token 拿到用戶 id 并放入 ThreadLocal。我在config包下寫了一個JwtInterceptor實現(xiàn)HandlerInterceptor核心方法preHandle里做這些事public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行 OPTIONS 預(yù)檢請求 if (OPTIONS.equals(request.getMethod())) { return true; } String token request.getHeader(Authorization); if (StringUtils.hasText(token) token.startsWith(Bearer )) { token token.substring(7); try { Claims claims JwtUtil.parseToken(token); // 將用戶id存入 request 屬性后續(xù) Controller 通過參數(shù)獲取 request.setAttribute(userId, claims.get(userId)); return true; } catch (Exception e) { throw new BusinessException(401, 登錄狀態(tài)已過期請重新登錄); } } throw new BusinessException(401, 未登錄請先登錄); }然后注冊到 WebMvcConfigurer 中同時配置放行路徑登錄接口、注冊接口、首頁商品列表接口、商品詳情接口這些不需要登錄就能訪問的接口。ThreadLocal 的用法我在項目里測過簡單場景好用但要注意請求結(jié)束后清理否則線程池復(fù)用會導(dǎo)致數(shù)據(jù)串號。這里我選擇把 userId 直接放進(jìn)request.setAttribute用的時候從 request 取更安全也更直觀。攔截器的執(zhí)行時機是在 Controller 方法之前所以被攔截的接口里能直接從 request 里拿到當(dāng)前登錄用戶的 id省去每個接口手動解析 token 的重復(fù)代碼。3.2 商品發(fā)布與文件上傳圖片到底存哪里商品發(fā)布功能涉及到一個繞不開的問題圖片存哪里。最省錢省事的方案是本地存儲配置一個上傳目錄用 UUID 重命名文件后保存到/uploads目錄然后在 WebMvcConfigurer 里把/uploads/**映射成靜態(tài)資源路徑。上傳接口的實現(xiàn)要點public String upload(MultipartFile file) { if (file.isEmpty()) { throw new BusinessException(400, 文件不能為空); } // 限制文件大小和類型 if (file.getSize() 5 * 1024 * 1024) { throw new BusinessException(400, 文件大小不能超過5MB); } String originalFilename file.getOriginalFilename(); String suffix originalFilename.substring(originalFilename.lastIndexOf(.)); ListString allowedSuffix Arrays.asList(.jpg, .jpeg, .png, .gif, .webp); if (!allowedSuffix.contains(suffix.toLowerCase())) { throw new BusinessException(400, 不支持的圖片格式); } String newFileName UUID.randomUUID().toString().replace(-, ) suffix; // 按日期分目錄存儲如 /uploads/20250315/xxx.jpg String datePath new SimpleDateFormat(yyyyMMdd).format(new Date()); File dir new File(uploadPath datePath); if (!dir.exists()) { dir.mkdirs(); } file.transferTo(new File(dir, newFileName)); return /uploads/ datePath / newFileName; }注意文件路徑的問題。本地開發(fā)時這個絕對路徑和項目根目錄有關(guān)系部署到 Linux 服務(wù)器時要確保上傳目錄存在且有寫權(quán)限否則會拋FileNotFoundException。我在application.yml里配置了一個自定義屬性upload.path上線時直接改配置指向服務(wù)器的數(shù)據(jù)盤路徑建議放在項目外例如/data/secondhand/uploads這樣以后升級項目也不會把圖片搞丟部署時一定要記得把上傳目錄掛載出來。3.3 訂單狀態(tài)機下單、支付、發(fā)貨、確認(rèn)收貨訂單流程是整個項目業(yè)務(wù)邏輯最密集的地方也是最容易出 bug 的地方。用戶點擊立即購買后后端要做的事包括檢查商品狀態(tài)是否在售、獲取商品價格、創(chuàng)建訂單初始狀態(tài)為待付款、修改商品狀態(tài)為已下架防止重復(fù)購買、扣減用戶余額、生成支付記錄。我選擇在創(chuàng)建訂單時就鎖定商品并標(biāo)記為下架狀態(tài)避免同一件商品被兩個用戶同時下單這是二手商品與普通電商的一個顯著差異。支付環(huán)節(jié)我做了模擬支付邏輯是如果余額夠就扣減并更新訂單狀態(tài)為待發(fā)貨不夠就提示余額不足。真實項目對接微信或支付寶支付流程也一樣只是把扣余額替換成調(diào)支付網(wǎng)關(guān)回調(diào)里再修改訂單狀態(tài)。關(guān)鍵的事務(wù)控制不能省。我寫了這樣一個方法Transactional(rollbackFor Exception.class) public Order createOrder(Long userId, Long productId) { Product product productMapper.selectById(productId); if (product null || !ProductStatus.ON_SALE.equals(product.getStatus())) { throw new BusinessException(商品不存在或已下架); } if (product.getUserId().equals(userId)) { throw new BusinessException(不能購買自己發(fā)布的商品); } // 扣減買家余額 int rows userMapper.deductBalance(userId, product.getPrice()); if (rows 0) { throw new BusinessException(余額不足); } // 給賣家加余額 userMapper.addBalance(product.getUserId(), product.getPrice()); // 標(biāo)記商品已下架 productMapper.updateStatus(productId, ProductStatus.SOLD); // 創(chuàng)建訂單 Order order new Order(); order.setOrderNo(generateOrderNo()); // 省略設(shè)置字段... orderMapper.insert(order); return order; }Transactional保證下面的操作要么都成功要么都失敗比如扣買家余額成功之后賣家加余額失敗事務(wù)回滾不會造成資金不一致。這里有個細(xì)節(jié)扣余額用UPDATE user SET balance balance - #{price} WHERE id #{userId} AND balance #{price}這條 SQL 來保證原子性在高并發(fā)下也不會有超扣問題。事務(wù)方法不能被同類內(nèi)部調(diào)用否則注解失效這個問題我在項目里踩過坑也建議你在寫代碼時留意。3.4 商品搜索、分類篩選與分頁首頁商品列表通常支持三種檢索維度按關(guān)鍵字模糊匹配標(biāo)題、按分類精確過濾、按價格升序降序排序。我用的 MyBatis-Plus 的 LambdaQueryWrapper 寫起來很簡潔public PageProductVO listProducts(int page, int size, String keyword, String category, String sort) { PageProduct p new Page(page, size); LambdaQueryWrapperProduct wrapper new LambdaQueryWrapper(); wrapper.eq(Product::getStatus, ProductStatus.ON_SALE) .eq(StringUtils.hasText(category), Product::getCategory, category) .and(StringUtils.hasText(keyword), w - w.like(Product::getTitle, keyword) .or().like(Product::getDescription, keyword)) .orderByDesc(sort.equals(new) ? Product::getCreateTime : Product::getViews); productMapper.selectPage(p, wrapper); // 轉(zhuǎn) VO附帶賣家昵稱和頭像 return convertToVO(p); }分頁大小我固定為 12前端每頁顯示 12 條比較整齊。關(guān)鍵字搜索的or條件需要用and(...)方法包一層否則會和其他eq條件拼出錯誤的 SQL。另外搜索時商品列表只返回在售商品但詳情頁可以顯示已售和下架商品讓用戶知道這件商品已經(jīng)賣出去了避免重復(fù)咨詢。4. 部署說明從本地跑起來到云服務(wù)器上線4.1 本地環(huán)境準(zhǔn)備JDK、Maven、MySQL、Redis拿到源碼后本地部署需要準(zhǔn)備的環(huán)境如下組件版本建議用途JDK1.8 或 11編譯運行 Java 代碼Maven3.6依賴管理、打包MySQL5.7 或 8.0數(shù)據(jù)存儲Redis5.x 及以上驗證碼、緩存可選Node.js14前端項目構(gòu)建如果包含前端JDK 版本這里要多說一句如果源碼是 Spring Boot 2.7.x 寫的JDK 1.8 是最穩(wěn)的搭配。有些人的機器裝的是 JDK 17啟動時可能出現(xiàn)模塊訪問權(quán)限報錯要么換回 JDK 8/11要么在啟動參數(shù)里加--add-opens明顯麻煩得多。Maven 建議用 IDEA 自帶的 Bundled Maven 或自己下載解壓配置好阿里云鏡像國內(nèi)網(wǎng)絡(luò)環(huán)境直接拉默認(rèn)倉庫慢得讓人崩潰。MySQL 導(dǎo)入初始化腳本時注意先手工CREATE DATABASE secondhand DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;再use secondhand;后source init.sql;。utf8mb4 一定要用否則用戶發(fā)商品描述里帶個表情符號直接報Incorrect string value錯誤這是很多新手最容易碰到的編碼坑。4.2 配置修改真正要改的只有一處半源碼里的application.yml盡量把環(huán)境相關(guān)配置抽出來部署時按實際情況修改。我貼一下核心配置塊來說明server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/secondhand?useUnicodetruecharacterEncodingutf8mb4useSSLfalseserverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver mybatis-plus: mapper-locations: classpath:mapper/*.xml configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0 # 自定義配置 upload: path: /data/secondhand/uploads jwt: secret: your-secret-key-please-change expire-hours: 24密碼改成你自己的upload.path改成你想存圖片的目錄jwt.secret一定要改成一個足夠長的隨機字符串否則 token 可以被偽造。密碼加密建議用 BCrypt 而不是 MD5源碼里如果看到 MD5 工具類可以替換成BCryptPasswordEncoder安全性提升一個檔次。如果 Redis 不可用可以把驗證碼等緩存邏輯降級為本地內(nèi)存緩存這樣最小化部署時可以不裝 Redis但生產(chǎn)環(huán)境還是建議裝上。4.3 Linux 云服務(wù)器部署手動部署完整流程云服務(wù)器手動部署的流程是打包后端 - 上傳 jar 到服務(wù)器 - 裝環(huán)境 - 啟動進(jìn)程 - 配置 Nginx 反向代理。后端打包用mvn clean package -DskipTests打完包在target/目錄找到secondhand-0.0.1-SNAPSHOT.jar通過scp或者寶塔面板上傳到服務(wù)器的/opt/secondhand目錄。啟動命令用nohup java -jar /opt/secondhand/secondhand-0.0.1-SNAPSHOT.jar --spring.profiles.activeprod /opt/secondhand/logs/app.log 21 nohup和保證進(jìn)程在 SSH 斷開后繼續(xù)運行。把日志輸出到文件是為了出問題時能tail -f查看。如果你希望開機自啟可以寫一個 systemd service 文件這樣進(jìn)程被誤殺時也會自動重啟我建議生產(chǎn)環(huán)境盡量用 systemd 管理 Java 進(jìn)程。前端構(gòu)建后把dist目錄里的靜態(tài)文件放到 Nginx 的html目錄Nginx 配置里做兩個關(guān)鍵點location /指向靜態(tài)文件location /api/反向代理到http://127.0.0.1:8080并去掉/api前綴。如果是前后端不分離的單體項目后端直接打包成包含靜態(tài)資源的 jar省去 Nginx 這層但前后端分離模式下這個配置是標(biāo)配。部署到云服務(wù)器后訪問不通的排查路徑通常是防火墻有沒有開端口、安全組有沒有放行、Nginx 有沒有啟動、后端進(jìn)程有沒有掛掉、數(shù)據(jù)庫白名單有沒有限制。按這條鏈路從外到內(nèi)一層層排查90% 的問題都能定位。4.4 Docker 部署把環(huán)境固化成一個鏡像如果服務(wù)器上已經(jīng)裝了 Docker把整個 Spring Boot 應(yīng)用做成鏡像會省很多心。一個標(biāo)準(zhǔn)的Dockerfile長這樣FROM openjdk:8-jre-alpine WORKDIR /app COPY secondhand-0.0.1-SNAPSHOT.jar app.jar EXPOSE 8080 ENTRYPOINT [java, -jar, app.jar, --spring.profiles.activeprod]構(gòu)建并運行docker build -t secondhand:1.0 . docker run -d --name secondhand -p 8080:8080 \ -v /data/secondhand/uploads:/app/uploads \ -v /data/secondhand/logs:/app/logs \ --restartalways \ secondhand:1.0為什么-v掛載這兩個目錄因為容器是臨時的一旦容器被刪掉容器里的數(shù)據(jù)就全沒了。圖片上傳目錄在容器重啟或升級時必須持久化到宿主機這是 Docker 部署 Spring Boot 最值得注意的一環(huán)。數(shù)據(jù)庫直接用宿主機的 MySQLjar 里配置jdbc:mysql://宿主機IP:3306/secondhand。如果數(shù)據(jù)庫也容器化了建議用docker-compose把 MySQL、Redis、后端應(yīng)用編排到一起啟動一條命令搞定適合演示和交付。5. 常見問題與排查技巧實錄5.1 項目啟動失敗的幾類典型問題Spring Boot 項目最常見的啟動失敗原因是端口被占用。報錯信息是Web server failed to start. Port 8080 was already in use.排查方法很簡單Linux 上用netstat -tlnp | grep 8080找出占用進(jìn)程要么 kill 掉要么改項目的端口。Windows 上是netstat -ano | findstr 8080然后去任務(wù)管理器結(jié)束進(jìn)程。第二個高頻問題是數(shù)據(jù)庫連接失敗報Access denied for user rootlocalhost或者Communications link failure。前者是賬號密碼或權(quán)限問題后者是數(shù)據(jù)庫沒啟動或者 url 寫錯。判斷思路先在本機用命令行連一下 MySQL確認(rèn)賬號密碼沒問題再查application.yml里的配置是否一致。另外 MySQL 8 的驅(qū)動類名是com.mysql.cj.jdbc.Driver老項目里如果還是com.mysql.jdbc.Driver會報警告建議升級。第三個問題是依賴下載不了Maven 報一堆紅。這種基本是網(wǎng)絡(luò)問題或者倉庫沒配好把settings.xml里的鏡像改成阿里云公共倉庫clean 一下重新 import。我的經(jīng)驗是本地沒網(wǎng)時別碰 Maven 項目裝依賴能把人裝崩潰。5.2 前后端聯(lián)調(diào)時典型的跨域與請求問題前端頁面能打開但接口請求全部失敗打開瀏覽器控制臺能看到Access-Control-Allow-Origin相關(guān)報錯這就是跨域問題。解決方式有兩種后端加CrossOrigin或全局 CORS 配置或者通過 Nginx 反向代理同源。開發(fā)環(huán)境推薦后端加全局 CORSConfiguration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }還有一個很容易忽略的問題攔截器攔截了所有路徑但OPTIONS預(yù)檢請求沒放行導(dǎo)致前端發(fā) POST 請求一直報跨域。實際上請求是先發(fā) OPTIONS 預(yù)檢再發(fā)實際請求后端如果攔截器直接攔截 OPTIONS 返回 401那跨域解決得再好也沒用。我在 JwtInterceptor 的preHandle里第一行就放了if (OPTIONS.equals(request.getMethod())) return true;這個雷我已經(jīng)替各位踩過了。5.3 圖片上傳后訪問 404 的排查方法本地測試圖片上傳成功接口返回了/uploads/20250315/xxx.jpg但瀏覽器訪問這個路徑 404。原因基本是靜態(tài)資源映射沒配置。需要在 WebMvcConfigurer 中顯式地注冊O(shè)verride public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/uploads/**) .addResourceLocations(file: uploadPath /); }這里file:前綴不能丟它告訴 Spring 這是一個文件系統(tǒng)路徑而不是 classpath 路徑。部署到 Linux 后還要確認(rèn)目錄權(quán)限chmod 755確保 nginx 或 Java 進(jìn)程有權(quán)限讀取。如果是用 Nginx 部署前端和后端分離的結(jié)構(gòu)更穩(wěn)妥的做法是在 Nginx 層把/uploads/直接映射到服務(wù)器磁盤目錄不經(jīng)過 Java 層性能更好。5.4 部署到服務(wù)器后接口訪問慢或超時本地一切正常部署到云服務(wù)器后某些接口偶爾超時先從這幾個方面查數(shù)據(jù)庫連接池配置是否偏小、慢 SQL 是否有索引支撐、服務(wù)器帶寬是不是太小。拿商品列表接口舉例如果 product 表只建了主鍵索引搜索直接全表掃描數(shù)據(jù)量上來之后接口會越來越慢。解決方式是給status、category、user_id都加上普通索引這種索引占空間可以忽略但對查詢性能是質(zhì)的提升。另外分享一個我自己的習(xí)慣上線前一定要先用 JMeter 或 Postman 做一次簡單的并發(fā)測試不用多復(fù)雜100 個并發(fā)請求商品列表接口看看平均響應(yīng)時間和錯誤率。如果 100 并發(fā)就撐不住趕緊回去查慢 SQL 和連接池。我見過太多單人用沒問題、一上服務(wù)器就崩的情況都是流量沒測過就上線。6. 源碼之外的幾個加分設(shè)計很多二手交易平臺項目做到基礎(chǔ) CRUD 就停了但真正讓人眼前一亮的往往是那些細(xì)節(jié)設(shè)計。這里分享幾個我在源碼里額外加入、被用戶評價最多的功能點。商品瀏覽量的處理很值得說。如果用數(shù)據(jù)庫字段views累加每次訪問都 UPDATE 一次其實沒必要。我在 Redis 里用incr累加再定期批量回寫數(shù)據(jù)庫減輕數(shù)據(jù)庫壓力。如果沒有 Redis也可以用內(nèi)存 Map 加定時任務(wù)批量更新但注意要加鎖防止并發(fā)問題。詳情頁瀏覽量做到刷新一次只加一次是前端控制的用 sessionStorage 標(biāo)記是否已經(jīng)瀏覽過。我的發(fā)布和我的足跡這兩個功能雖然簡單但對用戶體驗提升明顯。發(fā)布列表就是查詢當(dāng)前用戶的所有商品包括在售、下架、已售的配合狀態(tài)標(biāo)簽和對應(yīng)操作按鈕賣家能清晰地看到每件商品的生命周期。瀏覽足跡本質(zhì)是一個瀏覽記錄表插入時做唯一約束、重復(fù)瀏覽時更新時間列表倒序展示這種小功能寫起來快但對用戶粘性幫助很大。管理員后臺也是加分項。雖然二手平臺的核心是用戶之間交易但平臺運營需要管理入口。一個簡單的 admin 后臺包含用戶管理禁用/啟用賬號、商品管理強制下架違規(guī)物品、訂單查看、數(shù)據(jù)統(tǒng)計每日注冊量、交易量就能撐起一個項目的完整度。我在源碼里單獨寫了 admin 接口模塊Controller 路徑以/admin開頭攔截器判斷當(dāng)前用戶的 role 字段是否為admin用角色區(qū)分權(quán)限沒有引入復(fù)雜的權(quán)限框架。7. 這個項目還能怎么擴展如果你拿到這份源碼之后不滿足于現(xiàn)狀想往深了做我提供幾個方向供參考。第一個方向是增加消息通知功能。買家下單后給賣家發(fā)站內(nèi)信賣家發(fā)貨后給買家發(fā)通知用 WebSocket 做實時提醒。這個可以結(jié)合 Spring Boot 封裝好了的 WebSocket 支持來寫屬于中等難度但很見功力的擴展。第二個方向是引入緩存。把首頁商品列表、商品分類、熱門搜索詞放進(jìn) Redis熱點商品詳情做緩存預(yù)熱接口響應(yīng)能從幾百毫秒降到幾十毫秒。這個方向會讓你從CRUD 程序員向真正做性能優(yōu)化的人邁進(jìn)。第三個方向是接入真實的支付網(wǎng)關(guān)?,F(xiàn)在源碼里是模擬余額支付把支付部分抽象出來對接支付寶當(dāng)面付或者微信 Native 支付回調(diào)處理是這套邏輯里最有含金量的部分。不過做的時候注意要用沙箱環(huán)境測試合規(guī)方面多看看官方文檔。第四個方向是給項目補充單元測試和 CI/CD。寫幾個核心 Service 層的單元測試用例用 GitHub Actions 或 Jenkins 在提交代碼后自動跑測試、自動打包部署流程固化。這個方向雖然不增加業(yè)務(wù)功能但對工程素養(yǎng)的要求很高面試時也是很好的談資。最后聊點實際的做了這么多年 Spring Boot 項目我最大的體會是源碼能跑起來只是第一步真正值錢的是你對業(yè)務(wù)邏輯理解的深度和排查問題的能力。多花時間想想這個狀態(tài)為什么這樣流轉(zhuǎn)這個字段為什么這樣設(shè)計比急著復(fù)制粘貼代碼有用得多。如果你在本地把這個二手交易平臺跑通、部署上線、并且自己動手改了一兩個功能那么你對 Spring Boot 的理解絕對會上一個臺階。后面再做其他項目你會發(fā)現(xiàn)很多思路都是相通的這就是應(yīng)有的迭代節(jié)奏。本文還有配套的精品資源點擊獲取