簡介這是一套基于Java實現(xiàn)的二手車交易拍賣系統(tǒng)畢業(yè)設(shè)計程序面向計算機相關(guān)專業(yè)需要完成畢設(shè)或課程設(shè)計的學(xué)生也適合希望參考完整管理系統(tǒng)開發(fā)流程的Java學(xué)習(xí)者。資源壓縮包約10.96MB內(nèi)含可運行的程序源代碼一份與配套數(shù)據(jù)庫文件目錄圍繞系統(tǒng)源碼與數(shù)據(jù)腳本組織具體配置環(huán)境在包內(nèi)說明。已有2281人學(xué)習(xí)下載說明其在同類畢設(shè)資料中具有一定參考熱度。內(nèi)容覆蓋需求分析、系統(tǒng)功能與總體結(jié)構(gòu)設(shè)計、數(shù)據(jù)結(jié)構(gòu)及安全設(shè)計并深入數(shù)據(jù)庫訪問實現(xiàn)、主要功能模塊的具體實現(xiàn)與關(guān)鍵代碼最后給出功能測試及結(jié)果分析。讀者可據(jù)此梳理二手車拍賣業(yè)務(wù)的模塊劃分、數(shù)據(jù)庫表關(guān)系、數(shù)據(jù)庫訪問與測試思路獲得一套結(jié)構(gòu)完整、可運行驗證的畢設(shè)實現(xiàn)方案便于對照學(xué)習(xí)與二次調(diào)整。1. 從二手車拍賣的實際流程切入這套 Java 系統(tǒng)能解決什么二手車拍賣跟普通電商最大的區(qū)別不在商品在“時間”和“唯一性”一輛車只有一個成交名額同一秒可能有十幾個人點出價誰的錢先落庫、誰的出價被順延、誰的保證金該退全是硬約束。這套基于 Java 的二手車交易拍賣系統(tǒng)就是把這些約束落成可運行代碼的一套完整程序覆蓋車輛發(fā)布、場次管理、實時出價、延時競拍、保證金凍結(jié)、訂單結(jié)算和管理端審核。它適合三類人拿它做課程設(shè)計或畢設(shè)答辯的演示系統(tǒng)需要一份能跑通全鏈路的骨架想練手 Spring Boot 業(yè)務(wù)分層的中級開發(fā)者以及要快速驗證拍賣類業(yè)務(wù)模型的產(chǎn)品側(cè)同學(xué)。讀完你應(yīng)該能判斷它值不值得下載、自己改哪幾個點就能跑起來。2. 技術(shù)棧與工程分層Spring Boot MyBatis-Plus 的骨架怎么搭選型這部分先說結(jié)論拍賣系統(tǒng)是典型的“讀多寫少但寫極敏感”的業(yè)務(wù)寫操作集中在出價和結(jié)算兩個點上讀寫比例大致 20:1。這意味著框架不需要多花哨但事務(wù)邊界和鎖的粒度必須清楚。純 Servlet JDBC 能跑但你要自己寫連接池管理、參數(shù)綁定、異常統(tǒng)一處理改一個字段要動五個文件維護成本會把調(diào)試時間吃掉。Spring Boot 的價值在這里不是“流行”而是把事務(wù)注解、參數(shù)校驗、全局異常這三件事收斂成聲明式配置讓你把注意力放回競價邏輯本身。2.1 依賴清單與版本口徑下面這份pom.xml片段是我一般會用的最小集合去掉了一切非必要組件。注意 MyBatis-Plus 的版本要和 Spring Boot 主版本對齊3.5.x 配 Boot 2.7.x 是經(jīng)過大量項目驗證的組合跨大版本容易在分頁插件上翻車。dependencies !-- Web 層REST 接口 Thymeleaf 管理端頁面 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-thymeleaf/artifactId /dependency !-- 持久層MyBatis-Plus 省掉 80% 單表 CRUD -- dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId version8.0.33/version /dependency !-- 參數(shù)校驗NotNull / Min 直接作用在 DTO 上 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-validation/artifactId /dependency !-- JWT管理端和用戶端分開鑒權(quán) -- dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt-api/artifactId version0.11.5/version /dependency !-- 工具類金額計算、日期格式化、MD5 -- dependency groupIdcn.hutool/groupId artifactIdhutool-all/artifactId version5.8.20/version /dependency /dependencies這份清單背后的取舍是不引入 Redis 做分布式鎖。畢設(shè)級和個人項目基本都是單機部署MySQL 的行鎖加樂觀鎖足夠撐住幾十并發(fā)的出價場景多引一個中間件只會讓部署環(huán)節(jié)多一個失敗點。等你真到了多實例部署再把出價入口換成 Redis 的SETNX加 Lua 腳本改動面也就一個 Service 方法。2.2 配置文件與啟動順序配置文件里最容易被忽略的是時區(qū)和連接池。時間字段一旦跨時區(qū)拍賣結(jié)束時間會莫名其妙提前 8 小時這種問題排查起來極其耗時。server: port: 8080 servlet: context-path: / spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://127.0.0.1:3306/auction_car?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue username: root password: 123456 hikari: maximum-pool-size: 20 # 出價接口是短事務(wù)20 足夠 minimum-idle: 5 connection-timeout: 30000 servlet: multipart: max-file-size: 10MB # 車輛圖片單張上限 max-request-size: 50MB mybatis-plus: configuration: map-underscore-to-camel-case: true # car_id - carId log-impl: org.apache.ibatis.logging.stdout.StdOutImpl # 調(diào)試期開上線關(guān) global-config: db-config: id-type: auto logic-delete-field: deleted # 全局邏輯刪除字段 logic-delete-value: 1 logic-not-delete-value: 0連接池上限設(shè) 20 而不是默認的 10是因為出價接口在壓測時會出現(xiàn)“等連接”而非“等鎖”的假死現(xiàn)象是接口超時但數(shù)據(jù)庫 CPU 很低血淚經(jīng)驗是先把池子調(diào)大再懷疑 SQL。啟動順序上先跑建表 SQL再mvn spring-boot:run最后訪問/admin/login。如果啟動報Table auction_car.sys_user doesnt exist說明建表腳本沒執(zhí)行或庫名對不上別急著改代碼。2.3 六張核心表與字段口徑拍賣系統(tǒng)的數(shù)據(jù)模型核心是“場次”和“出價”兩張表的關(guān)系。場次存當前最高價和領(lǐng)先者出價表存全量流水兩者是冗余關(guān)系——場次表是為了讀快出價表是為了可追溯和爭議處理。表名作用關(guān)鍵字段說明sys_user用戶/管理員id,username,role,real_name_statusrole取值 0 普通、1 管理員未實名不能出價car_vehicle車輛檔案id,brand,model,reg_date,mileage,seller_id,audit_status里程數(shù)用 int 存公里reg_date用 dateauction_item拍賣場次id,car_id,start_price,current_price,step_price,start_time,end_time,status,versionstatus0 待開始、1 競價中、2 已結(jié)束、3 已流拍bid_record出價流水id,auction_id,user_id,bid_price,bid_time,request_idrequest_id做冪等唯一索引au_deposit保證金id,user_id,auction_id,amount,statusstatus0 凍結(jié)、1 已退、2 已抵扣au_order成交訂單id,auction_id,buyer_id,deal_price,pay_statusauction_id唯一索引防重復(fù)落單金額一律用decimal(12,2)理由在第 5 章展開。auction_item.version是樂觀鎖字段MyBatis-Plus 的Version注解能自動接管它但前提是你用updateById而不是自己寫 XML 的 update 語句這一點后面會展開。3. 拍賣核心鏈路出價校驗、延時競拍與訂單落庫這一章是整個系統(tǒng)最關(guān)鍵的部分。出價接口寫得好不好直接決定系統(tǒng)在并發(fā)下會不會出現(xiàn)“一輛車兩個人成交”或者“價格被覆蓋”的事故。我見過不少類似項目把出價簡化成一條UPDATE auction_item SET current_price ?單機演示沒問題一旦兩個人同時點后寫的直接覆蓋前面的而且不留痕跡。3.1 出價接口的六道校驗與樂觀鎖先看校驗順序。順序不是隨便排的便宜的判斷放前面能避免無謂的數(shù)據(jù)庫往返涉及金額和身份的放后面因為要查表。Service public class BidService { Resource private AuctionItemMapper auctionMapper; Resource private BidRecordMapper bidMapper; Resource private DepositMapper depositMapper; /** * 出價核心方法 * param auctionId 場次 ID * param userId 出價人 * param bidPrice 出價金額前端傳入服務(wù)端必須重校驗 * param requestId 前端生成的 UUID用于冪等 */ Transactional(rollbackFor Exception.class) public BidResult placeBid(Long auctionId, Long userId, BigDecimal bidPrice, String requestId) { // 1. 冪等攔截同一 requestId 只允許落一條流水 Long dup bidMapper.selectCount( new LambdaQueryWrapperBidRecord().eq(BidRecord::getRequestId, requestId)); if (dup 0) { throw new BizException(請勿重復(fù)提交); } // 2. 場次必須存在且處于競價中 AuctionItem item auctionMapper.selectById(auctionId); if (item null || item.getStatus() ! 1) { throw new BizException(該場次不在競價中); } // 3. 時間窗校驗服務(wù)端時間為準不信任前端 LocalDateTime now LocalDateTime.now(); if (now.isBefore(item.getStartTime()) || now.isAfter(item.getEndTime())) { throw new BizException(不在競價時間段內(nèi)); } // 4. 賣家不能拍自己的車 CarVehicle car carMapper.selectById(item.getCarId()); if (car.getSellerId().equals(userId)) { throw new BizException(不能競拍自己發(fā)布的車輛); } // 5. 保證金必須已凍結(jié) Long depositOk depositMapper.selectCount(new LambdaQueryWrapperAuDeposit() .eq(AuDeposit::getUserId, userId) .eq(AuDeposit::getAuctionId, auctionId) .eq(AuDeposit::getStatus, 0)); if (depositOk 0) { throw new BizException(請先繳納保證金); } // 6. 出價必須高于 當前價 最小加價幅度 BigDecimal minAccept item.getCurrentPrice().add(item.getStepPrice()); if (bidPrice.compareTo(minAccept) 0) { throw new BizException(出價不得低于 minAccept); } // 7. 樂觀鎖更新version 不匹配則說明被別人搶先 int rows auctionMapper.update(null, new LambdaUpdateWrapperAuctionItem() .set(AuctionItem::getCurrentPrice, bidPrice) .set(AuctionItem::getCurrentWinnerId, userId) .set(AuctionItem::getVersion, item.getVersion() 1) .set(AuctionItem::getEndTime, extendIfNeeded(item, now)) // 延時邏輯見 3.3 .eq(AuctionItem::getId, auctionId) .eq(AuctionItem::getVersion, item.getVersion()) .eq(AuctionItem::getStatus, 1)); if (rows 0) { throw new BizException(出價已被他人搶先請刷新后重試); } // 8. 落流水 BidRecord record new BidRecord(); record.setAuctionId(auctionId); record.setUserId(userId); record.setBidPrice(bidPrice); record.setBidTime(now); record.setRequestId(requestId); bidMapper.insert(record); return BidResult.ok(bidPrice); } }這段代碼里有三個地方值得單獨說。第一冪等用request_id唯一索引兜底代碼里查一次只是為了讓用戶看到友好提示真正的防線是數(shù)據(jù)庫唯一索引即使并發(fā)穿透了應(yīng)用層的查詢插入也會失敗回滾。第二eq(AuctionItem::getStatus, 1)這個條件是防御性的防止在查和更新之間場次被定時任務(wù)結(jié)算掉屬于“多寫一個條件少一次事故”的典型。第三update語句里同時改了價格、領(lǐng)先者、版本號和結(jié)束時間是一條語句完成的不存在中間態(tài)被別人讀到的情況。參數(shù)方面step_price建議按車價分檔設(shè)10 萬以下的車設(shè) 50010 到 30 萬設(shè) 100030 萬以上設(shè) 2000。這個字段放在場次表而不是全局配置是因為同一批次的車可能加價規(guī)則不同寫到全局配置里后期改起來要動代碼。3.2 拍賣結(jié)束的調(diào)度與冪等結(jié)算結(jié)算最容易出的問題是重復(fù)落單。定時任務(wù)每 10 秒掃一次如果某次執(zhí)行超過 10 秒下一次會并發(fā)跑起來同一場次被結(jié)算兩次生成兩張訂單。解決辦法是把“改狀態(tài)”作為結(jié)算的前置條件用條件更新?lián)屾i。Component public class AuctionSettleTask { Resource private AuctionItemMapper auctionMapper; Resource private OrderService orderService; /** 每 10 秒掃描一次到期場次fixedDelay 保證上一輪跑完才開下一輪 */ Scheduled(fixedDelay 10_000L, initialDelay 15_000L) public void settleExpired() { ListAuctionItem list auctionMapper.selectList(new LambdaQueryWrapperAuctionItem() .eq(AuctionItem::getStatus, 1) .le(AuctionItem::getEndTime, LocalDateTime.now()) .last(limit 100)); // 分批避免一次拉太多 for (AuctionItem item : list) { // 搶占式改狀態(tài)只有把 1 改成 2 成功的那個線程才繼續(xù)結(jié)算 int locked auctionMapper.update(null, new LambdaUpdateWrapperAuctionItem() .set(AuctionItem::getStatus, 2) .eq(AuctionItem::getId, item.getId()) .eq(AuctionItem::getStatus, 1)); if (locked 0) { continue; // 已被其他線程結(jié)算直接跳過 } if (item.getCurrentWinnerId() null) { auctionMapper.update(null, new LambdaUpdateWrapperAuctionItem() .set(AuctionItem::getStatus, 3) .eq(AuctionItem::getId, item.getId())); continue; // 無人出價置為流拍 } orderService.createOrder(item); } } }fixedDelay和fixedRate的區(qū)別這里必須分清fixedRate按固定頻率觸發(fā)任務(wù)執(zhí)行時間超過間隔時會堆積并發(fā)fixedDelay是上一輪結(jié)束后再等 10 秒天然串行。畢設(shè)項目里用fixedDelay就能規(guī)避掉大部分重復(fù)結(jié)算再疊加狀態(tài)條件更新基本萬無一失。limit 100是防止某次積壓了幾千場次導(dǎo)致單輪執(zhí)行過久分批次處理更穩(wěn)。訂單表上還要加一個uk_order_auction唯一索引auction_id單列這是最后一道防線。應(yīng)用層邏輯再嚴密也可能因為將來加了新的結(jié)算入口而出錯唯一索引能在數(shù)據(jù)庫層面直接拒絕重復(fù)插入報錯信息也比臟數(shù)據(jù)好排查。3.3 延時競拍最后三分鐘出價順延的邊界延時競拍是拍賣類系統(tǒng)的標配作用是防止“最后一秒狙擊”。規(guī)則一般寫成結(jié)束前 N 分鐘內(nèi)有新出價結(jié)束時間往后順延 M 分鐘。N 和 M 我一般取 3 和 5也見過取 5 和 5 的看業(yè)務(wù)習(xí)慣。/** * 判斷是否需要順延結(jié)束時間 * param item 當前場次 * param bidTime 本次出價時間 * return 順延后的結(jié)束時間不需要順延時返回原值 */ private LocalDateTime extendIfNeeded(AuctionItem item, LocalDateTime bidTime) { long secondsLeft Duration.between(bidTime, item.getEndTime()).getSeconds(); if (secondsLeft 0 secondsLeft 180) { // 剩余 3 分鐘內(nèi) return item.getEndTime().plusMinutes(5); // 順延 5 分鐘 } return item.getEndTime(); }這里有個容易被忽略的點順延要設(shè)上限。如果一直有人出價理論上可以無限延長實際業(yè)務(wù)里通常會限制最多順延 3 次或總時長不超過 2 小時。實現(xiàn)方式是在場次表加一個extend_count字段每次順延加一超過閾值就不再順延。不加這個限制測試階段會出現(xiàn)“怎么也結(jié)束不了”的詭異現(xiàn)象第一次遇到會以為是定時任務(wù)掛了其實是自己的延時邏輯在無限觸發(fā)。另一個細節(jié)是secondsLeft 0這個判斷。如果不加場次已經(jīng)過期但還沒被結(jié)算的那幾秒內(nèi)有人出價secondsLeft是負數(shù)plusMinutes會算出一個更早的時間等于把結(jié)束時間往前推越推越亂。4. 交易側(cè)功能落地車輛發(fā)布、保證金與后臺審核核心競價跑通之后剩下的功能看著瑣碎但直接影響系統(tǒng)能不能演示完整。這一章按“賣家發(fā)布 → 平臺審核 → 買家繳保證金 → 參與競拍”的實際使用順序展開每一步給出可運行的接口和需要注意的參數(shù)。4.1 車輛發(fā)布與圖片上傳的路徑處理車輛信息包含品牌、型號、上牌日期、里程、排量、變速箱、車況描述和一組圖片。圖片存儲是這類項目最常見的翻車點本地開發(fā)用D:/upload/寫死絕對路徑換臺機器或部署到服務(wù)器就 404。正確的做法是路徑配置化通過資源映射對外暴露。Configuration public class WebMvcConfig implements WebMvcConfigurer { Value(${app.upload.path}) private String uploadPath; // 例如 /data/upload/ 或 D:/upload/ /** 把磁盤目錄映射成可訪問的 URL 前綴 */ Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceLocations(file: uploadPath); } }PostMapping(/car/publish) public ResultLong publish(Valid RequestBody CarPublishDTO dto, HttpServletRequest req) { Long userId (Long) req.getAttribute(userId); CarVehicle car new CarVehicle(); car.setBrand(dto.getBrand()); car.setModel(dto.getModel()); car.setRegDate(dto.getRegDate()); // LocalDate格式 yyyy-MM-dd car.setMileage(dto.getMileage()); // 單位公里int car.setSellerId(userId); car.setAuditStatus(0); // 0 待審核只有 1 才能上架 car.setImages(String.join(,, dto.getImageUrls())); carMapper.insert(car); return Result.ok(car.getId()); }圖片上傳接口本身要注意兩件事一是文件名用 UUID 重命名別用原始文件名中文名和特殊字符在部分容器里會出問題二是限制擴展名白名單jpg、jpeg、png、webp不要只靠前端accept屬性那個隨手就能繞過。上傳成功后返回相對路徑/upload/2024/06/xxx.jpg前端拼接域名展示這樣換域名不用改數(shù)據(jù)庫。audit_status字段控制車輛能否上架值為 0 時管理端能看到用戶端列表查不到。這個字段別省很多同類項目直接發(fā)布即上架答辯時被問“虛假車源怎么處理”就答不上來。4.2 保證金凍結(jié)與退回的狀態(tài)流轉(zhuǎn)保證金是拍賣系統(tǒng)的信用基礎(chǔ)。設(shè)計上分三個狀態(tài)0 凍結(jié)、1 已退、2 已抵扣。繳納時插入一條凍結(jié)記錄競拍失敗退回到 1成交后從凍結(jié)轉(zhuǎn)抵扣或在支付尾款時一并處理。Transactional(rollbackFor Exception.class) public void payDeposit(Long userId, Long auctionId, BigDecimal amount) { // 同一場次同一用戶只能有一筆有效保證金 Long exist depositMapper.selectCount(new LambdaQueryWrapperAuDeposit() .eq(AuDeposit::getUserId, userId) .eq(AuDeposit::getAuctionId, auctionId) .ne(AuDeposit::getStatus, 1)); if (exist 0) { throw new BizException(該場次已繳納保證金); } AuctionItem item auctionMapper.selectById(auctionId); if (item.getStatus() ! 0 item.getStatus() ! 1) { throw new BizException(該場次不接受保證金); } AuDeposit d new AuDeposit(); d.setUserId(userId); d.setAuctionId(auctionId); d.setAmount(amount); d.setStatus(0); d.setCreateTime(LocalDateTime.now()); depositMapper.insert(d); // 凍結(jié)邏輯從用戶賬戶余額扣減這里用賬戶表減余額 凍結(jié)額加值 accountMapper.freeze(userId, amount); }ne(AuDeposit::getStatus, 1)這個條件的意思是把“已退回”的記錄排除在外允許用戶退款后再次繳納。如果寫成eq(status, 0)邏輯上也對但將來加“已過期”狀態(tài)時會漏掉。狀態(tài)判斷盡量用“排除法”而不是“枚舉法”擴展性更好。保證金金額一般設(shè)起拍價的 5% 到 10%最低不低于 500 元。這個值放在場次表里跟著車走不要全局寫死因為高檔車的保證金要求明顯更高。4.3 管理端審核與接口鑒權(quán)管理端負責(zé)三件事車輛審核、場次創(chuàng)建、異常訂單處理。鑒權(quán)用 JWT 加攔截器普通用戶和管理員走同一套 token 機制靠role字段區(qū)分。public class AuthInterceptor implements HandlerInterceptor { Resource private JwtUtil jwtUtil; Override public boolean preHandle(HttpServletRequest req, HttpServletResponse resp, Object handler) throws Exception { String token req.getHeader(Authorization); if (token null || !token.startsWith(Bearer )) { resp.setStatus(401); return false; } try { Claims claims jwtUtil.parse(token.substring(7)); req.setAttribute(userId, Long.valueOf(claims.getSubject())); req.setAttribute(role, claims.get(role, Integer.class)); return true; } catch (Exception e) { resp.setStatus(401); // token 過期或簽名不符統(tǒng)一 401 return false; } } }管理員專屬接口再加一層判斷比如在AdminController的類級別攔截里校驗role 1。不要只靠前端隱藏菜單接口必須獨立鑒權(quán)這是安全底線。審核動作本身很簡單update car_vehicle set audit_status 1 where id ? and audit_status 0加上audit_status 0的條件是為了防止重復(fù)審核覆蓋掉拒絕原因。5. 避坑與排查這套系統(tǒng)最容易出問題的五處這一章全是實際調(diào)試中撞出來的每條按現(xiàn)象、原因、解決三段寫對照排查能省掉很多時間。5.1 出價成功但價格不漲現(xiàn)象接口返回成功bid_record也插入了但刷新頁面價格還是舊的。原因auction_item的更新語句里漏了version的自增或者用了updateById(item)但item是從緩存里取的舊對象Version注解雖然生效但比對的是舊版本號更新影響行數(shù)為 0 卻沒人檢查。解決所有涉及樂觀鎖的更新必須判斷rows為 0 時拋異?；貪L。同時確認 XML 里寫的是version version 1而不是set version #{version}。5.2 金額出現(xiàn) 0.1 0.2 0.30000000000000004現(xiàn)象加價后價格出現(xiàn)一長串小數(shù)或者兩個用戶出價 1000.10 和 1000.20比較時判定后者不高于前者。原因?qū)嶓w類用了double或float數(shù)據(jù)庫字段用了float。浮點數(shù)二進制表示無法精確表達十進制小數(shù)。解決Java 側(cè)一律BigDecimal數(shù)據(jù)庫一律decimal(12,2)比較用compareTo不用equalsequals會比 scale1000.0和1000.00不相等。這個坑我在三個項目里都見過屬于必踩。5.3 定時任務(wù)重復(fù)生成訂單現(xiàn)象同一場次出現(xiàn)兩條au_order記錄或者日志里同一場次結(jié)算了兩次。原因多實例部署或fixedRate導(dǎo)致任務(wù)重疊狀態(tài)更新和訂單插入之間沒有原子性。解決fixedRate換fixedDelay改狀態(tài)用條件更新?lián)屾i訂單表加auction_id唯一索引兜底。5.4 時間字段整體偏移 8 小時現(xiàn)象設(shè)定的結(jié)束時間是 20:00實際 12:00 就結(jié)束了。原因JDBC URL 沒寫serverTimezone或者實體用了java.util.Date配JsonFormat時區(qū)沒指定。解決URL 加serverTimezoneAsia/Shanghai實體統(tǒng)一用LocalDateTimeJackson 全局配置spring.jackson.time-zoneGMT8和date-formatyyyy-MM-dd HH:mm:ss。5.5 分頁查詢返回全表數(shù)據(jù)現(xiàn)象前端傳page1size10返回了 500 條。原因MyBatis-Plus 的分頁插件沒注冊Page對象被當成普通參數(shù)忽略SQL 里沒有l(wèi)imit。解決加一個MybatisPlusInterceptor配置類注冊PaginationInnerInterceptor(DbType.MYSQL)。這個配置不寫編譯不報錯運行時才出問題屬于典型的靜默失敗。6. 并發(fā)驗證用一個腳本把出價鏈路壓到邊界功能跑通不代表正確拍賣系統(tǒng)的正確性只有在并發(fā)下才暴露。我的習(xí)慣是上線前用腳本模擬 20 個用戶同時搶一輛車然后核對三件事最終價格是否等于最高出價、bid_record條數(shù)是否等于成功請求數(shù)、au_order是否只有一條。下面這段 Python 腳本不依賴 JMeter裝個requests就能跑改兩個參數(shù)就能復(fù)用到不同場次。import threading, uuid, requests, time BASE http://127.0.0.1:8080 AUCTION_ID 1001 TOKENS [ftoken_{i} for i in range(20)] # 預(yù)先登錄拿到的 20 個用戶 token results [] lock threading.Lock() def bid(token, price): headers {Authorization: fBearer {token}} body { auctionId: AUCTION_ID, bidPrice: price, requestId: str(uuid.uuid4()) # 每次請求唯一模擬正常用戶 } r requests.post(f{BASE}/api/bid/place, jsonbody, headersheaders, timeout5) with lock: results.append((token, price, r.status_code, r.text[:60])) # 用 Barrier 讓 20 個線程盡可能同時發(fā)出 barrier threading.Barrier(20) def worker(i): barrier.wait() bid(TOKENS[i], 50000 i * 1000) threads [threading.Thread(targetworker, args(i,)) for i in range(20)] [t.start() for t in threads] [t.join() for t in threads] ok [r for r in results if r[2] 200] print(f成功 {len(ok)} / 總 {len(results)}) print(最高成功價:, max([r[1] for r in ok], default0))腳本的關(guān)鍵在threading.Barrier它讓 20 個線程在同一個瞬間釋放比順序發(fā)請求更容易撞出并發(fā)問題。如果只是for循環(huán)發(fā)請求服務(wù)端處理太快根本壓不出競爭。requestId每次都用新 UUID是模擬正常用戶如果想驗證冪等把uuid.uuid4()換成固定字符串重復(fù)發(fā) 20 次正確結(jié)果是只有 1 次成功。跑完腳本后執(zhí)行這三條 SQL 核對-- 1. 最終價格應(yīng)等于最高成功出價 SELECT current_price, current_winner_id, version FROM auction_item WHERE id 1001; -- 2. 流水條數(shù)應(yīng)等于成功請求數(shù) SELECT COUNT(*) FROM bid_record WHERE auction_id 1001; -- 3. 訂單只能有一條 SELECT COUNT(*) FROM au_order WHERE auction_id 1001;我第一次做這類驗證時20 個并發(fā)里有 3 個請求返回成功但價格被覆蓋version字段只漲了 17。原因就是當時更新語句里漏了eq(version)條件直接updateByIdMyBatis-Plus 的樂觀鎖插件只在updateById生效而我當時用的是自定義 XML 的 update注解等于沒生效。后來養(yǎng)成的習(xí)慣是凡是帶樂觀鎖的表更新方法統(tǒng)一走LambdaUpdateWrapper并顯式寫eq(getVersion, oldVersion)不依賴注解的隱式行為也不寫裸的updateById。這行代碼多寫 20 個字符能省掉一整晚的排查。壓測的另一個價值是暴露連接池配置問題。20 并發(fā)下如果出現(xiàn)大量Connection is not available, request timed out先看 Hikari 的maximum-pool-size再看每個事務(wù)里有沒有在事務(wù)內(nèi)調(diào)外部接口比如發(fā)短信、調(diào)圖片處理有的話把外部調(diào)用挪到事務(wù)外事務(wù)只包數(shù)據(jù)庫操作。這個調(diào)整通常能把接口 P99 從 800ms 壓到 100ms 以內(nèi)。最后提醒一句壓測數(shù)據(jù)和真實數(shù)據(jù)要分開腳本跑完記得清掉測試場次和流水不然演示時列表里全是 50000 起的假車源。希望幫到你。本文還有配套的精品資源點擊獲取