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