簡(jiǎn)介這是一套基于Java實(shí)現(xiàn)的二手車交易拍賣系統(tǒng)畢業(yè)設(shè)計(jì)程序面向計(jì)算機(jī)相關(guān)專業(yè)需要完成畢設(shè)或課程設(shè)計(jì)的學(xué)生也適合希望參考完整管理系統(tǒng)開發(fā)流程的Java學(xué)習(xí)者。資源壓縮包約10.96MB內(nèi)含可運(yùn)行的程序源代碼一份與配套數(shù)據(jù)庫(kù)文件目錄圍繞系統(tǒng)源碼與數(shù)據(jù)腳本組織具體配置環(huán)境在包內(nèi)說明。已有2281人學(xué)習(xí)下載說明其在同類畢設(shè)資料中具有一定參考熱度。內(nèi)容覆蓋需求分析、系統(tǒng)功能與總體結(jié)構(gòu)設(shè)計(jì)、數(shù)據(jù)結(jié)構(gòu)及安全設(shè)計(jì)并深入數(shù)據(jù)庫(kù)訪問實(shí)現(xiàn)、主要功能模塊的具體實(shí)現(xiàn)與關(guān)鍵代碼最后給出功能測(cè)試及結(jié)果分析。讀者可據(jù)此梳理二手車拍賣業(yè)務(wù)的模塊劃分、數(shù)據(jù)庫(kù)表關(guān)系、數(shù)據(jù)庫(kù)訪問與測(cè)試思路獲得一套結(jié)構(gòu)完整、可運(yùn)行驗(yàn)證的畢設(shè)實(shí)現(xiàn)方案便于對(duì)照學(xué)習(xí)與二次調(diào)整。1. 從二手車拍賣的實(shí)際流程切入這套 Java 系統(tǒng)能解決什么二手車拍賣跟普通電商最大的區(qū)別不在商品在“時(shí)間”和“唯一性”一輛車只有一個(gè)成交名額同一秒可能有十幾個(gè)人點(diǎn)出價(jià)誰的錢先落庫(kù)、誰的出價(jià)被順延、誰的保證金該退全是硬約束。這套基于 Java 的二手車交易拍賣系統(tǒng)就是把這些約束落成可運(yùn)行代碼的一套完整程序覆蓋車輛發(fā)布、場(chǎng)次管理、實(shí)時(shí)出價(jià)、延時(shí)競(jìng)拍、保證金凍結(jié)、訂單結(jié)算和管理端審核。它適合三類人拿它做課程設(shè)計(jì)或畢設(shè)答辯的演示系統(tǒng)需要一份能跑通全鏈路的骨架想練手 Spring Boot 業(yè)務(wù)分層的中級(jí)開發(fā)者以及要快速驗(yàn)證拍賣類業(yè)務(wù)模型的產(chǎn)品側(cè)同學(xué)。讀完你應(yīng)該能判斷它值不值得下載、自己改哪幾個(gè)點(diǎn)就能跑起來。2. 技術(shù)棧與工程分層Spring Boot MyBatis-Plus 的骨架怎么搭選型這部分先說結(jié)論拍賣系統(tǒng)是典型的“讀多寫少但寫極敏感”的業(yè)務(wù)寫操作集中在出價(jià)和結(jié)算兩個(gè)點(diǎn)上讀寫比例大致 20:1。這意味著框架不需要多花哨但事務(wù)邊界和鎖的粒度必須清楚。純 Servlet JDBC 能跑但你要自己寫連接池管理、參數(shù)綁定、異常統(tǒng)一處理改一個(gè)字段要?jiǎng)游鍌€(gè)文件維護(hù)成本會(huì)把調(diào)試時(shí)間吃掉。Spring Boot 的價(jià)值在這里不是“流行”而是把事務(wù)注解、參數(shù)校驗(yàn)、全局異常這三件事收斂成聲明式配置讓你把注意力放回競(jìng)價(jià)邏輯本身。2.1 依賴清單與版本口徑下面這份pom.xml片段是我一般會(huì)用的最小集合去掉了一切非必要組件。注意 MyBatis-Plus 的版本要和 Spring Boot 主版本對(duì)齊3.5.x 配 Boot 2.7.x 是經(jīng)過大量項(xiàng)目驗(yàn)證的組合跨大版本容易在分頁插件上翻車。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ù)校驗(yàn)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 !-- 工具類金額計(jì)算、日期格式化、MD5 -- dependency groupIdcn.hutool/groupId artifactIdhutool-all/artifactId version5.8.20/version /dependency /dependencies這份清單背后的取舍是不引入 Redis 做分布式鎖。畢設(shè)級(jí)和個(gè)人項(xiàng)目基本都是單機(jī)部署MySQL 的行鎖加樂觀鎖足夠撐住幾十并發(fā)的出價(jià)場(chǎng)景多引一個(gè)中間件只會(huì)讓部署環(huán)節(jié)多一個(gè)失敗點(diǎn)。等你真到了多實(shí)例部署再把出價(jià)入口換成 Redis 的SETNX加 Lua 腳本改動(dòng)面也就一個(gè) Service 方法。2.2 配置文件與啟動(dòng)順序配置文件里最容易被忽略的是時(shí)區(qū)和連接池。時(shí)間字段一旦跨時(shí)區(qū)拍賣結(jié)束時(shí)間會(huì)莫名其妙提前 8 小時(shí)這種問題排查起來極其耗時(shí)。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 # 出價(jià)接口是短事務(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 而不是默認(rèn)的 10是因?yàn)槌鰞r(jià)接口在壓測(cè)時(shí)會(huì)出現(xiàn)“等連接”而非“等鎖”的假死現(xiàn)象是接口超時(shí)但數(shù)據(jù)庫(kù) CPU 很低血淚經(jīng)驗(yàn)是先把池子調(diào)大再懷疑 SQL。啟動(dòng)順序上先跑建表 SQL再mvn spring-boot:run最后訪問/admin/login。如果啟動(dòng)報(bào)Table auction_car.sys_user doesnt exist說明建表腳本沒執(zhí)行或庫(kù)名對(duì)不上別急著改代碼。2.3 六張核心表與字段口徑拍賣系統(tǒng)的數(shù)據(jù)模型核心是“場(chǎng)次”和“出價(jià)”兩張表的關(guān)系。場(chǎng)次存當(dāng)前最高價(jià)和領(lǐng)先者出價(jià)表存全量流水兩者是冗余關(guān)系——場(chǎng)次表是為了讀快出價(jià)表是為了可追溯和爭(zhēng)議處理。表名作用關(guān)鍵字段說明sys_user用戶/管理員id,username,role,real_name_statusrole取值 0 普通、1 管理員未實(shí)名不能出價(jià)car_vehicle車輛檔案id,brand,model,reg_date,mileage,seller_id,audit_status里程數(shù)用 int 存公里reg_date用 dateauction_item拍賣場(chǎng)次id,car_id,start_price,current_price,step_price,start_time,end_time,status,versionstatus0 待開始、1 競(jìng)價(jià)中、2 已結(jié)束、3 已流拍bid_record出價(jià)流水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注解能自動(dòng)接管它但前提是你用updateById而不是自己寫 XML 的 update 語句這一點(diǎn)后面會(huì)展開。3. 拍賣核心鏈路出價(jià)校驗(yàn)、延時(shí)競(jìng)拍與訂單落庫(kù)這一章是整個(gè)系統(tǒng)最關(guān)鍵的部分。出價(jià)接口寫得好不好直接決定系統(tǒng)在并發(fā)下會(huì)不會(huì)出現(xiàn)“一輛車兩個(gè)人成交”或者“價(jià)格被覆蓋”的事故。我見過不少類似項(xiàng)目把出價(jià)簡(jiǎn)化成一條UPDATE auction_item SET current_price ?單機(jī)演示沒問題一旦兩個(gè)人同時(shí)點(diǎn)后寫的直接覆蓋前面的而且不留痕跡。3.1 出價(jià)接口的六道校驗(yàn)與樂觀鎖先看校驗(yàn)順序。順序不是隨便排的便宜的判斷放前面能避免無謂的數(shù)據(jù)庫(kù)往返涉及金額和身份的放后面因?yàn)橐楸?。Service public class BidService { Resource private AuctionItemMapper auctionMapper; Resource private BidRecordMapper bidMapper; Resource private DepositMapper depositMapper; /** * 出價(jià)核心方法 * param auctionId 場(chǎng)次 ID * param userId 出價(jià)人 * param bidPrice 出價(jià)金額前端傳入服務(wù)端必須重校驗(yàn) * 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(請(qǐng)勿重復(fù)提交); } // 2. 場(chǎng)次必須存在且處于競(jìng)價(jià)中 AuctionItem item auctionMapper.selectById(auctionId); if (item null || item.getStatus() ! 1) { throw new BizException(該場(chǎng)次不在競(jìng)價(jià)中); } // 3. 時(shí)間窗校驗(yàn)服務(wù)端時(shí)間為準(zhǔn)不信任前端 LocalDateTime now LocalDateTime.now(); if (now.isBefore(item.getStartTime()) || now.isAfter(item.getEndTime())) { throw new BizException(不在競(jìng)價(jià)時(shí)間段內(nèi)); } // 4. 賣家不能拍自己的車 CarVehicle car carMapper.selectById(item.getCarId()); if (car.getSellerId().equals(userId)) { throw new BizException(不能競(jìng)拍自己發(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(請(qǐng)先繳納保證金); } // 6. 出價(jià)必須高于 當(dāng)前價(jià) 最小加價(jià)幅度 BigDecimal minAccept item.getCurrentPrice().add(item.getStepPrice()); if (bidPrice.compareTo(minAccept) 0) { throw new BizException(出價(jià)不得低于 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)) // 延時(shí)邏輯見 3.3 .eq(AuctionItem::getId, auctionId) .eq(AuctionItem::getVersion, item.getVersion()) .eq(AuctionItem::getStatus, 1)); if (rows 0) { throw new BizException(出價(jià)已被他人搶先請(qǐng)刷新后重試); } // 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); } }這段代碼里有三個(gè)地方值得單獨(dú)說。第一冪等用request_id唯一索引兜底代碼里查一次只是為了讓用戶看到友好提示真正的防線是數(shù)據(jù)庫(kù)唯一索引即使并發(fā)穿透了應(yīng)用層的查詢插入也會(huì)失敗回滾。第二eq(AuctionItem::getStatus, 1)這個(gè)條件是防御性的防止在查和更新之間場(chǎng)次被定時(shí)任務(wù)結(jié)算掉屬于“多寫一個(gè)條件少一次事故”的典型。第三update語句里同時(shí)改了價(jià)格、領(lǐng)先者、版本號(hào)和結(jié)束時(shí)間是一條語句完成的不存在中間態(tài)被別人讀到的情況。參數(shù)方面step_price建議按車價(jià)分檔設(shè)10 萬以下的車設(shè) 50010 到 30 萬設(shè) 100030 萬以上設(shè) 2000。這個(gè)字段放在場(chǎng)次表而不是全局配置是因?yàn)橥慌蔚能嚳赡芗觾r(jià)規(guī)則不同寫到全局配置里后期改起來要?jiǎng)哟a。3.2 拍賣結(jié)束的調(diào)度與冪等結(jié)算結(jié)算最容易出的問題是重復(fù)落單。定時(shí)任務(wù)每 10 秒掃一次如果某次執(zhí)行超過 10 秒下一次會(huì)并發(fā)跑起來同一場(chǎng)次被結(jié)算兩次生成兩張訂單。解決辦法是把“改狀態(tài)”作為結(jié)算的前置條件用條件更新?lián)屾i。Component public class AuctionSettleTask { Resource private AuctionItemMapper auctionMapper; Resource private OrderService orderService; /** 每 10 秒掃描一次到期場(chǎng)次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 成功的那個(gè)線程才繼續(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; // 無人出價(jià)置為流拍 } orderService.createOrder(item); } } }fixedDelay和fixedRate的區(qū)別這里必須分清fixedRate按固定頻率觸發(fā)任務(wù)執(zhí)行時(shí)間超過間隔時(shí)會(huì)堆積并發(fā)fixedDelay是上一輪結(jié)束后再等 10 秒天然串行。畢設(shè)項(xiàng)目里用fixedDelay就能規(guī)避掉大部分重復(fù)結(jié)算再疊加狀態(tài)條件更新基本萬無一失。limit 100是防止某次積壓了幾千場(chǎng)次導(dǎo)致單輪執(zhí)行過久分批次處理更穩(wěn)。訂單表上還要加一個(gè)uk_order_auction唯一索引auction_id單列這是最后一道防線。應(yīng)用層邏輯再嚴(yán)密也可能因?yàn)閷砑恿诵碌慕Y(jié)算入口而出錯(cuò)唯一索引能在數(shù)據(jù)庫(kù)層面直接拒絕重復(fù)插入報(bào)錯(cuò)信息也比臟數(shù)據(jù)好排查。3.3 延時(shí)競(jìng)拍最后三分鐘出價(jià)順延的邊界延時(shí)競(jìng)拍是拍賣類系統(tǒng)的標(biāo)配作用是防止“最后一秒狙擊”。規(guī)則一般寫成結(jié)束前 N 分鐘內(nèi)有新出價(jià)結(jié)束時(shí)間往后順延 M 分鐘。N 和 M 我一般取 3 和 5也見過取 5 和 5 的看業(yè)務(wù)習(xí)慣。/** * 判斷是否需要順延結(jié)束時(shí)間 * param item 當(dāng)前場(chǎng)次 * param bidTime 本次出價(jià)時(shí)間 * return 順延后的結(jié)束時(shí)間不需要順延時(shí)返回原值 */ 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(); }這里有個(gè)容易被忽略的點(diǎn)順延要設(shè)上限。如果一直有人出價(jià)理論上可以無限延長(zhǎng)實(shí)際業(yè)務(wù)里通常會(huì)限制最多順延 3 次或總時(shí)長(zhǎng)不超過 2 小時(shí)。實(shí)現(xiàn)方式是在場(chǎng)次表加一個(gè)extend_count字段每次順延加一超過閾值就不再順延。不加這個(gè)限制測(cè)試階段會(huì)出現(xiàn)“怎么也結(jié)束不了”的詭異現(xiàn)象第一次遇到會(huì)以為是定時(shí)任務(wù)掛了其實(shí)是自己的延時(shí)邏輯在無限觸發(fā)。另一個(gè)細(xì)節(jié)是secondsLeft 0這個(gè)判斷。如果不加場(chǎng)次已經(jīng)過期但還沒被結(jié)算的那幾秒內(nèi)有人出價(jià)secondsLeft是負(fù)數(shù)plusMinutes會(huì)算出一個(gè)更早的時(shí)間等于把結(jié)束時(shí)間往前推越推越亂。4. 交易側(cè)功能落地車輛發(fā)布、保證金與后臺(tái)審核核心競(jìng)價(jià)跑通之后剩下的功能看著瑣碎但直接影響系統(tǒng)能不能演示完整。這一章按“賣家發(fā)布 → 平臺(tái)審核 → 買家繳保證金 → 參與競(jìng)拍”的實(shí)際使用順序展開每一步給出可運(yùn)行的接口和需要注意的參數(shù)。4.1 車輛發(fā)布與圖片上傳的路徑處理車輛信息包含品牌、型號(hào)、上牌日期、里程、排量、變速箱、車況描述和一組圖片。圖片存儲(chǔ)是這類項(xiàng)目最常見的翻車點(diǎn)本地開發(fā)用D:/upload/寫死絕對(duì)路徑換臺(tái)機(jī)器或部署到服務(wù)器就 404。正確的做法是路徑配置化通過資源映射對(duì)外暴露。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 重命名別用原始文件名中文名和特殊字符在部分容器里會(huì)出問題二是限制擴(kuò)展名白名單jpg、jpeg、png、webp不要只靠前端accept屬性那個(gè)隨手就能繞過。上傳成功后返回相對(duì)路徑/upload/2024/06/xxx.jpg前端拼接域名展示這樣換域名不用改數(shù)據(jù)庫(kù)。audit_status字段控制車輛能否上架值為 0 時(shí)管理端能看到用戶端列表查不到。這個(gè)字段別省很多同類項(xiàng)目直接發(fā)布即上架答辯時(shí)被問“虛假車源怎么處理”就答不上來。4.2 保證金凍結(jié)與退回的狀態(tài)流轉(zhuǎn)保證金是拍賣系統(tǒng)的信用基礎(chǔ)。設(shè)計(jì)上分三個(gè)狀態(tài)0 凍結(jié)、1 已退、2 已抵扣。繳納時(shí)插入一條凍結(jié)記錄競(jìng)拍失敗退回到 1成交后從凍結(jié)轉(zhuǎn)抵扣或在支付尾款時(shí)一并處理。Transactional(rollbackFor Exception.class) public void payDeposit(Long userId, Long auctionId, BigDecimal amount) { // 同一場(chǎng)次同一用戶只能有一筆有效保證金 Long exist depositMapper.selectCount(new LambdaQueryWrapperAuDeposit() .eq(AuDeposit::getUserId, userId) .eq(AuDeposit::getAuctionId, auctionId) .ne(AuDeposit::getStatus, 1)); if (exist 0) { throw new BizException(該場(chǎng)次已繳納保證金); } AuctionItem item auctionMapper.selectById(auctionId); if (item.getStatus() ! 0 item.getStatus() ! 1) { throw new BizException(該場(chǎng)次不接受保證金); } 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)這個(gè)條件的意思是把“已退回”的記錄排除在外允許用戶退款后再次繳納。如果寫成eq(status, 0)邏輯上也對(duì)但將來加“已過期”狀態(tài)時(shí)會(huì)漏掉。狀態(tài)判斷盡量用“排除法”而不是“枚舉法”擴(kuò)展性更好。保證金金額一般設(shè)起拍價(jià)的 5% 到 10%最低不低于 500 元。這個(gè)值放在場(chǎng)次表里跟著車走不要全局寫死因?yàn)楦邫n車的保證金要求明顯更高。4.3 管理端審核與接口鑒權(quán)管理端負(fù)責(zé)三件事車輛審核、場(chǎng)次創(chuàng)建、異常訂單處理。鑒權(quán)用 JWT 加攔截器普通用戶和管理員走同一套 token 機(jī)制靠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的類級(jí)別攔截里校驗(yàn)role 1。不要只靠前端隱藏菜單接口必須獨(dú)立鑒權(quán)這是安全底線。審核動(dòng)作本身很簡(jiǎn)單update car_vehicle set audit_status 1 where id ? and audit_status 0加上audit_status 0的條件是為了防止重復(fù)審核覆蓋掉拒絕原因。5. 避坑與排查這套系統(tǒng)最容易出問題的五處這一章全是實(shí)際調(diào)試中撞出來的每條按現(xiàn)象、原因、解決三段寫對(duì)照排查能省掉很多時(shí)間。5.1 出價(jià)成功但價(jià)格不漲現(xiàn)象接口返回成功bid_record也插入了但刷新頁面價(jià)格還是舊的。原因auction_item的更新語句里漏了version的自增或者用了updateById(item)但item是從緩存里取的舊對(duì)象Version注解雖然生效但比對(duì)的是舊版本號(hào)更新影響行數(shù)為 0 卻沒人檢查。解決所有涉及樂觀鎖的更新必須判斷rows為 0 時(shí)拋異常回滾。同時(shí)確認(rèn) XML 里寫的是version version 1而不是set version #{version}。5.2 金額出現(xiàn) 0.1 0.2 0.30000000000000004現(xiàn)象加價(jià)后價(jià)格出現(xiàn)一長(zhǎng)串小數(shù)或者兩個(gè)用戶出價(jià) 1000.10 和 1000.20比較時(shí)判定后者不高于前者。原因?qū)嶓w類用了double或float數(shù)據(jù)庫(kù)字段用了float。浮點(diǎn)數(shù)二進(jìn)制表示無法精確表達(dá)十進(jìn)制小數(shù)。解決Java 側(cè)一律BigDecimal數(shù)據(jù)庫(kù)一律decimal(12,2)比較用compareTo不用equalsequals會(huì)比 scale1000.0和1000.00不相等。這個(gè)坑我在三個(gè)項(xiàng)目里都見過屬于必踩。5.3 定時(shí)任務(wù)重復(fù)生成訂單現(xiàn)象同一場(chǎng)次出現(xiàn)兩條au_order記錄或者日志里同一場(chǎng)次結(jié)算了兩次。原因多實(shí)例部署或fixedRate導(dǎo)致任務(wù)重疊狀態(tài)更新和訂單插入之間沒有原子性。解決fixedRate換fixedDelay改狀態(tài)用條件更新?lián)屾i訂單表加auction_id唯一索引兜底。5.4 時(shí)間字段整體偏移 8 小時(shí)現(xiàn)象設(shè)定的結(jié)束時(shí)間是 20:00實(shí)際 12:00 就結(jié)束了。原因JDBC URL 沒寫serverTimezone或者實(shí)體用了java.util.Date配JsonFormat時(shí)區(qū)沒指定。解決URL 加serverTimezoneAsia/Shanghai實(shí)體統(tǒng)一用LocalDateTimeJackson 全局配置spring.jackson.time-zoneGMT8和date-formatyyyy-MM-dd HH:mm:ss。5.5 分頁查詢返回全表數(shù)據(jù)現(xiàn)象前端傳page1size10返回了 500 條。原因MyBatis-Plus 的分頁插件沒注冊(cè)Page對(duì)象被當(dāng)成普通參數(shù)忽略SQL 里沒有l(wèi)imit。解決加一個(gè)MybatisPlusInterceptor配置類注冊(cè)PaginationInnerInterceptor(DbType.MYSQL)。這個(gè)配置不寫編譯不報(bào)錯(cuò)運(yùn)行時(shí)才出問題屬于典型的靜默失敗。6. 并發(fā)驗(yàn)證用一個(gè)腳本把出價(jià)鏈路壓到邊界功能跑通不代表正確拍賣系統(tǒng)的正確性只有在并發(fā)下才暴露。我的習(xí)慣是上線前用腳本模擬 20 個(gè)用戶同時(shí)搶一輛車然后核對(duì)三件事最終價(jià)格是否等于最高出價(jià)、bid_record條數(shù)是否等于成功請(qǐng)求數(shù)、au_order是否只有一條。下面這段 Python 腳本不依賴 JMeter裝個(gè)requests就能跑改兩個(gè)參數(shù)就能復(fù)用到不同場(chǎng)次。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 個(gè)用戶 token results [] lock threading.Lock() def bid(token, price): headers {Authorization: fBearer {token}} body { auctionId: AUCTION_ID, bidPrice: price, requestId: str(uuid.uuid4()) # 每次請(qǐng)求唯一模擬正常用戶 } 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 個(gè)線程盡可能同時(shí)發(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(最高成功價(jià):, max([r[1] for r in ok], default0))腳本的關(guān)鍵在threading.Barrier它讓 20 個(gè)線程在同一個(gè)瞬間釋放比順序發(fā)請(qǐng)求更容易撞出并發(fā)問題。如果只是for循環(huán)發(fā)請(qǐng)求服務(wù)端處理太快根本壓不出競(jìng)爭(zhēng)。requestId每次都用新 UUID是模擬正常用戶如果想驗(yàn)證冪等把uuid.uuid4()換成固定字符串重復(fù)發(fā) 20 次正確結(jié)果是只有 1 次成功。跑完腳本后執(zhí)行這三條 SQL 核對(duì)-- 1. 最終價(jià)格應(yīng)等于最高成功出價(jià) SELECT current_price, current_winner_id, version FROM auction_item WHERE id 1001; -- 2. 流水條數(shù)應(yīng)等于成功請(qǐng)求數(shù) SELECT COUNT(*) FROM bid_record WHERE auction_id 1001; -- 3. 訂單只能有一條 SELECT COUNT(*) FROM au_order WHERE auction_id 1001;我第一次做這類驗(yàn)證時(shí)20 個(gè)并發(fā)里有 3 個(gè)請(qǐng)求返回成功但價(jià)格被覆蓋version字段只漲了 17。原因就是當(dāng)時(shí)更新語句里漏了eq(version)條件直接updateByIdMyBatis-Plus 的樂觀鎖插件只在updateById生效而我當(dāng)時(shí)用的是自定義 XML 的 update注解等于沒生效。后來養(yǎng)成的習(xí)慣是凡是帶樂觀鎖的表更新方法統(tǒng)一走LambdaUpdateWrapper并顯式寫eq(getVersion, oldVersion)不依賴注解的隱式行為也不寫裸的updateById。這行代碼多寫 20 個(gè)字符能省掉一整晚的排查。壓測(cè)的另一個(gè)價(jià)值是暴露連接池配置問題。20 并發(fā)下如果出現(xiàn)大量Connection is not available, request timed out先看 Hikari 的maximum-pool-size再看每個(gè)事務(wù)里有沒有在事務(wù)內(nèi)調(diào)外部接口比如發(fā)短信、調(diào)圖片處理有的話把外部調(diào)用挪到事務(wù)外事務(wù)只包數(shù)據(jù)庫(kù)操作。這個(gè)調(diào)整通常能把接口 P99 從 800ms 壓到 100ms 以內(nèi)。最后提醒一句壓測(cè)數(shù)據(jù)和真實(shí)數(shù)據(jù)要分開腳本跑完記得清掉測(cè)試場(chǎng)次和流水不然演示時(shí)列表里全是 50000 起的假車源。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取