簡介在Java后端開發(fā)中SpringBoot憑借自動配置機(jī)制大幅降低了環(huán)境搭建成本已成為構(gòu)建企業(yè)級應(yīng)用的主流框架。而校園二手交易平臺作為典型的業(yè)務(wù)閉環(huán)項目天然覆蓋用戶認(rèn)證、商品狀態(tài)機(jī)、訂單并發(fā)控制等核心場景非常適合用來理解框架原理與工程實(shí)踐的配合。圍繞這一主題文章從業(yè)務(wù)模塊拆分出發(fā)梳理了用戶、商品、交易三大核心域的表結(jié)構(gòu)設(shè)計方法強(qiáng)調(diào)了價格用分存儲、狀態(tài)流轉(zhuǎn)、事務(wù)邊界等細(xì)節(jié)同時深入解析了基于樂觀鎖的防超賣下單邏輯以及JWT鑒權(quán)、文件上傳、Docker部署等落地技術(shù)。對于正在準(zhǔn)備畢業(yè)設(shè)計或希望提升SpringBoot實(shí)戰(zhàn)能力的開發(fā)者這套完整方案既提供了可復(fù)用的數(shù)據(jù)庫設(shè)計方法論也給出了從源碼到可運(yùn)行系統(tǒng)的避坑指南。 做畢設(shè)選題的時候十個Java方向的人里有九個會刷到“校園二手交易平臺”這句話毫不夸張。但真正把源碼下載下來能順利跑起來、還能跟面試官講清楚技術(shù)點(diǎn)的人十個里未必有一個。我做過一套基于SpringBoot的校園二手交易平臺源碼和數(shù)據(jù)庫設(shè)計都完整整理過這中間踩了不少坑——SpringBoot版本兼容、MySQL表結(jié)構(gòu)反復(fù)推倒重來、并發(fā)下單一不小心就超賣。這篇文章就把這套項目的經(jīng)驗從頭梳理一遍不堆砌源碼文件而是把模塊劃分、數(shù)據(jù)庫設(shè)計、核心代碼、部署坑點(diǎn)以及面試怎么答都講透。無論你是剛學(xué)完Java基礎(chǔ)想找項目練手還是準(zhǔn)備用SpringBoot做畢業(yè)設(shè)計或者想從“會抄代碼”進(jìn)步到“能講設(shè)計”這篇都值得認(rèn)真看完。1. 為什么這個項目比“合租系統(tǒng)”“博客系統(tǒng)”更適合做Java練手項目1.1 校園二手交易的業(yè)務(wù)閉環(huán)決定了它的技術(shù)含量很多人選畢設(shè)題目時會考慮圖書管理系統(tǒng)、博客系統(tǒng)、在線商城。這些系統(tǒng)確實(shí)簡單但做完之后你會發(fā)現(xiàn)它們大多只是“多個表的CRUD”沒有多少業(yè)務(wù)邏輯可講。校園二手交易平臺不一樣它有自己的完整業(yè)務(wù)閉環(huán)學(xué)生注冊后進(jìn)行校園身份認(rèn)證認(rèn)證通過后可以發(fā)布閑置買家通過搜索、分類、收藏找到商品買賣雙方經(jīng)過站內(nèi)聊天溝通細(xì)節(jié)買家下單后走站內(nèi)余額模擬支付賣家發(fā)貨、買家確認(rèn)收貨交易完成后雙方可以互相評價如果出現(xiàn)問題還有舉報和申訴流程管理員在后端進(jìn)行商品審核、用戶封禁、數(shù)據(jù)統(tǒng)計。這套流程決定了項目不是一堆孤立的表而是各個模塊相互咬合的狀態(tài)流轉(zhuǎn)。比如商品不是刪掉就消失而是有草稿、待審核、在售、預(yù)訂、已售、強(qiáng)制下架的狀態(tài)路徑訂單不是簡單的insert而是先檢查商品是否在售再樂觀鎖更新商品狀態(tài)最后創(chuàng)建訂單、扣減余額。這些邏輯寫下來才是真正的“業(yè)務(wù)開發(fā)”。1.2 為什么要選SpringBootMyBatis-Plus這套組合選型的理由很多人答不上來。我的看法是SpringBoot的價值不是“快”而是它通過自動配置把環(huán)境差異收斂掉了。你在A機(jī)器上能跑換到B機(jī)器也能跑這對訓(xùn)練項目和實(shí)際交付太重要了。MyBatis-Plus把單表CRUD封裝好了寫起來比原生MyBatis少很多代碼但它不是萬能藥像訂單狀態(tài)變更、庫存扣減這種強(qiáng)一致性的寫操作我都是寫自定義SQL加樂觀鎖完全依賴BaseMapper是不合適的。我在這套項目里的推薦組合是SpringBoot 2.7.18 JDK 8 MySQL 8.0 MyBatis-Plus 3.5.3 Redis MinIO JWT。這套組合偏保守但穩(wěn)定。后面章節(jié)我會專門說為什么不要一上來就追SpringBoot 3.x。2. 模塊拆解先畫清楚“人、貨、單”三個核心域2.1 用戶域不是簡單地建一張user表用戶模塊最容易被做成一張只包含賬號密碼的user表我見過很多半成品就是這么干的。但校園二手平臺有個特殊點(diǎn)用戶需要證明自己是該校學(xué)生。于是在user表外我還設(shè)計了一張student_certification表用來存學(xué)號、姓名、所在院系、學(xué)生卡圖片URL、認(rèn)證狀態(tài)。user表本身只放通用登錄字段認(rèn)證信息單獨(dú)放原因是認(rèn)證是一次性的低頻操作拆開既能減少user表寬度也方便后臺審核時只查認(rèn)證表。user表核心字段id、username、password、nickname、avatar、phone、role0普通用戶1管理員、status0禁用1正常、points信譽(yù)積分、create_time、update_time。密碼存的是BCrypt加密后的字符串不是明文。這里有一個容易被忽略的點(diǎn)用戶狀態(tài)和登錄邏輯要聯(lián)動。如果賬號被管理員禁用登錄時不能只查用戶名和密碼還要校驗status字段否則被處罰的用戶依然可以正常登錄。2.2 商品域發(fā)布到下架的完整狀態(tài)機(jī)商品域的靈魂是狀態(tài)。如果你的goods表里只有一個status字段但代碼里沒有一套狀態(tài)流轉(zhuǎn)邏輯那和普通文章表沒有區(qū)別。我的狀態(tài)設(shè)計為0草稿、1待審核、2在售、3預(yù)訂中、4已售出、5下架、6管理員強(qiáng)制下架。為什么要有待審核因為不是所有學(xué)生都會規(guī)范發(fā)布商品后臺管理員需要審核圖片和標(biāo)題防止出現(xiàn)違規(guī)品類。為什么要區(qū)分“預(yù)訂中”和“已售出”因為線下交易存在“我先預(yù)訂然后當(dāng)面交付”的環(huán)節(jié)沒有這個狀態(tài)用戶并發(fā)下單就控制不住。商品表字段包括id、user_id發(fā)布者、category_id、title、description、price單位分、original_price、quality成色、image_urlsJSON數(shù)組存圖集、status、stock_version樂觀鎖版本號、view_count、create_time、update_time。價格我建議統(tǒng)一用“分”來表示不要用double否則訂單金額計算會出現(xiàn)浮點(diǎn)誤差這是個老生常談但很容易踩的坑。2.3 交易域二手交易不是標(biāo)準(zhǔn)電商訂單是所有模塊里最容易出錯的。二手交易和標(biāo)準(zhǔn)電商最大的差異是庫存永遠(yuǎn)是1不允許超賣。標(biāo)準(zhǔn)電商可以扣減庫存二手場景則應(yīng)該是“下單即鎖定商品”成功創(chuàng)建訂單后商品狀態(tài)從在售變?yōu)轭A(yù)訂中其他人不能再下單。所以order表不能單純當(dāng)作訂單記錄表它實(shí)際承擔(dān)了商品狀態(tài)的“觸發(fā)器”。訂單表字段id、order_no、goods_id、buyer_id、seller_id、amount單位分、status0待支付1待發(fā)貨2待收貨3已完成4退款中5已關(guān)閉、pay_type0站內(nèi)余額1線下交付、pay_time、deliver_time、receive_time、close_time、remark、create_time。另外還要一張trade_record表用來記錄每次余額扣減和收入增加類似流水賬對賬和排查問題都用得上。3. 數(shù)據(jù)庫設(shè)計9張核心表4張擴(kuò)展表表和表之間的業(yè)務(wù)邏輯要能講明白3.1 核心表的結(jié)構(gòu)設(shè)計與建表SQL數(shù)據(jù)庫設(shè)計不能一上來就建表而是先把業(yè)務(wù)對象拆成“主表子表狀態(tài)流水”四個層次。以訂單為例orders是主表記錄一次交易的核心內(nèi)容訂單操作記錄是流水表記錄狀態(tài)變更歷史如果涉及退款還要有refund_record表。下表是我歸納出的核心表清單表名職責(zé)關(guān)鍵字段user賬號登錄與基本信息username、password、role、statusstudent_certification學(xué)生認(rèn)證資料user_id、student_no、campus_card_url、auth_statusgoods_category商品分類name、parent_id、sortgoods商品信息user_id、category_id、status、stock_versiongoods_image商品圖片goods_id、url、sortorders訂單主表order_no、goods_id、buyer_id、seller_id、statustrade_record余額流水user_id、type、amount、balance_before、balance_afterfavorite收藏user_id、goods_id、create_timemessage站內(nèi)私信from_user_id、to_user_id、content、is_read這里給出goods表的建表SQL注意索引和注釋CREATE TABLE goods ( id bigint(20) NOT NULL AUTO_INCREMENT, user_id bigint(20) NOT NULL COMMENT 發(fā)布者ID, category_id bigint(20) DEFAULT NULL COMMENT 分類ID, title varchar(120) NOT NULL COMMENT 標(biāo)題, description text COMMENT 描述, price bigint(20) NOT NULL COMMENT 價格單位分, original_price bigint(20) DEFAULT NULL COMMENT 原價單位分, quality tinyint(4) DEFAULT NULL COMMENT 成色1-10, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 0草稿 1待審核 2在售 3預(yù)訂中 4已售出 5下架 6強(qiáng)制下架, stock_version int(11) NOT NULL DEFAULT 0 COMMENT 樂觀鎖版本號, view_count bigint(20) DEFAULT 0 COMMENT 瀏覽量, create_time datetime DEFAULT NULL, update_time datetime DEFAULT NULL, PRIMARY KEY (id), KEY idx_category_status (category_id,status), KEY idx_user_id (user_id), KEY idx_create_time (create_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT商品表;注意幾個設(shè)計細(xì)節(jié)價格用bigint存“分”不用decimal避免MyBatis里類型轉(zhuǎn)換麻煩也方便Long接收status加上category_id聯(lián)合索引因為首頁分類展示是最常見的查詢場景圖片不單獨(dú)建表用goods.image_urls字段存JSON數(shù)組減少一次關(guān)聯(lián)查詢?nèi)绻麑D片查詢很頻繁再拆表3.2 擴(kuò)展表留言、舉報、通知、瀏覽記錄核心表之外要支撐完整業(yè)務(wù)閉環(huán)還需要四張擴(kuò)展表。message表站內(nèi)私信from_user_id、to_user_id、content、is_read、create_time。站點(diǎn)內(nèi)聊天時需要根據(jù)from_user_id和to_user_id查會話記錄這里可以加聯(lián)合索引(from_user_id, to_user_id, create_time)report表舉報target_type舉報商品還是評論、target_id、reason、status、handle_user_id、handle_time。后臺管理員處理舉報后狀態(tài)要能回溯notice表通知user_id、title、content、type、is_read。比如訂單狀態(tài)變化、審核結(jié)果都要推通知給用戶browse_record表瀏覽記錄user_id、goods_id、browse_time。用瀏覽記錄做“猜你喜歡”時查詢最近N條記錄這些擴(kuò)展表不一定每個頁面都用到但設(shè)計時先留好回頭加功能時就不用再動大表。我的習(xí)慣是凡是需要追溯歷史的信息都單獨(dú)建流水表不要在原表上改得面目全非。3.3 索引和事務(wù)設(shè)計索引不是越多越好事務(wù)也不是越寬越好很多初學(xué)者拿到表結(jié)構(gòu)后把所有字段都加一遍索引這是不對的。索引會降低寫入速度占用磁盤空間。這個項目里真正熱點(diǎn)查詢是商品列表按分類、狀態(tài)、時間排序商品標(biāo)題模糊搜索訂單按買家或賣家查列表交易流水按用戶查對應(yīng)的索引就是goods(category_id, status, create_time)、goods(title)全文索引或簡單用LIKE、orders(buyer_id, status)、orders(seller_id, status)、trade_record(user_id, create_time)。注意不要給description加索引大字段加索引沒意義。事務(wù)設(shè)計更重要。下單這個操作需要把“更新商品狀態(tài)”“創(chuàng)建訂單”“扣減買家余額”“增加賣家余額”“寫入交易流水”放在同一個事務(wù)里任何一個失敗都要回滾。另外事務(wù)不是包得越寬越好。查詢操作不要加Transactional否則數(shù)據(jù)庫連接占用時間太長高并發(fā)時會把連接池打滿。4. 核心源碼解析把登錄、商品發(fā)布、下單這三段代碼吃透4.1 JWT登錄鑒權(quán)的完整鏈路登錄模塊我用JWT做無狀態(tài)鑒權(quán)。服務(wù)端不保存Session客戶端每次請求在Header里帶一個Authorization: Bearer token攔截器校驗token合法性并從token里取出當(dāng)前用戶ID和角色。這樣做的優(yōu)點(diǎn)是方便前后端分離缺點(diǎn)是需要自己處理token過期和續(xù)期。JwtUtil核心代碼public class JwtUtil { private static final String SECRET your-secret-key; public static String generateToken(User user) { return Jwts.builder() .setSubject(user.getId().toString()) .claim(username, user.getUsername()) .claim(role, user.getRole()) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() 3600_000)) .signWith(SignatureAlgorithm.HS256, SECRET) .compact(); } public static Long getUserId(String token) { Claims claims Jwts.parser() .setSigningKey(SECRET) .parseClaimsJws(token) .getBody(); return Long.valueOf(claims.getSubject()); } }攔截器里要注意兩點(diǎn)一是白名單放行比如登錄、注冊、商品瀏覽、圖片訪問不需要token二是用戶被禁用后已經(jīng)發(fā)出的token要立即失效。我的處理方式是在Redis里存一個黑名單管理員封禁用戶時把該用戶的token版本號加1攔截器里比對版本號不匹配就拒絕訪問。4.2 商品發(fā)布的實(shí)現(xiàn)文件上傳與參數(shù)校驗商品發(fā)布有兩個核心點(diǎn)圖片上傳和字段校驗。圖片上傳我用MinIO做對象存儲不把圖片文件存到數(shù)據(jù)庫。MinIO兼容S3協(xié)議本地部署很方便和OSS相比沒有外網(wǎng)依賴。上傳流程是前端用MultipartFile上傳圖片后端把文件流轉(zhuǎn)成輸入流寫入MinIO返回圖片URL然后把URL數(shù)組存入goods.image_urls字段。代碼示例PostMapping(/goods) public Result addGoods(RequestBody Valid GoodsDTO dto, RequestHeader(Authorization) String token) { Long userId JwtUtil.getUserId(token); goodsService.addGoods(userId, dto); return Result.ok(); }GoodsDTO里用javax.validation注解做入?yún)⑿ｒ灡热鏝otBlank(message 標(biāo)題不能為空)、NotNull(message 價格不能為空)。這里有個小經(jīng)驗不要相信前端傳的任何值特別是status。用戶提交商品時status只能固定為待審核不能讓前端傳什么就存什么否則可以繞過審核直接上架。4.3 下單防并發(fā)樂觀鎖把“庫存為1”的坑填平下單是這個項目里最有技術(shù)含量的方法。前面說過二手商品庫存永遠(yuǎn)是1所以不能用常規(guī)的“先查庫存再扣減”否則并發(fā)請求同時通過檢查就會超賣。我的方案是使用自定義SQL加樂觀鎖Transactional(rollbackFor Exception.class) public Order createOrder(Long goodsId, Long buyerId) { Goods goods goodsMapper.selectById(goodsId); if (goods null || !goods.getStatus().equals(GoodsStatus.ON_SALE)) { throw new BizException(商品不存在或不在售); } int rows goodsMapper.lockStock(goodsId, goods.getStockVersion()); if (rows 0) { throw new BizException(手慢了商品已被下單); } // 生成訂單號、創(chuàng)建訂單、扣減買家余額、增加賣家余額 // 記錄交易流水 return order; }對應(yīng)的Mapper XMLupdate idlockStock update goods set status 3, stock_version stock_version 1 where id #{goodsId} and status 2 and stock_version #{stockVersion} /update這段SQL的作用是只有當(dāng)商品仍然是“在售”狀態(tài)且版本號沒有變化時才會更新成功。update影響行數(shù)為0說明商品已經(jīng)被別人下單或狀態(tài)已變化。我之所以不用select for update悲觀鎖是因為同一件商品并發(fā)下單的沖突概率其實(shí)不高樂觀鎖在絕大多數(shù)情況下不會沖突對數(shù)據(jù)庫的壓力更小而悲觀鎖會讓所有請求都排隊等待商品詳情頁也可能被鎖影響。5. 從源碼到可運(yùn)行SpringBoot版本、MySQL初始化、Docker部署這些坑一次說清5.1 環(huán)境選型JDK8還是17SpringBoot 2.7.x還是3.x我見過很多新手用IDEA創(chuàng)建項目時默認(rèn)生成SpringBoot 3.x然后引入老教程的MyBatis-Plus和各類工具結(jié)果就是一堆jar包沖突。SpringBoot 3.x基于Jakarta EE之前寫javax.validation、javax.servlet的地方全部要改成jakarta.*MyBatis-Plus必須用3.5.5以上版本很多老博客里的寫法直接編譯不過。所以個人建議做校園二手交易這個體量的項目直接選擇SpringBoot 2.7.18JDK用8或11。它支持JDK17但不用新特性就不影響。等以后真正需要升級再遷現(xiàn)階段沒必要給自己增加“遷移類錯誤”的排查負(fù)擔(dān)。5.2 MySQL初始化和application.yml的完整配置數(shù)據(jù)庫初始化時要注意如果MySQL是8.0連接URL必須加上時區(qū)和SSL參數(shù)否則啟動會報錯。我的application.yml關(guān)鍵配置如下spring: datasource: url: jdbc:mysql://localhost:3306/campus_secondhand?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse username: root password: yourpassword driver-class-name: com.mysql.cj.jdbc.Driver redis: host: localhost port: 6379 servlet: multipart: max-file-size: 5MB max-request-size: 20MB mybatis-plus: mapper-locations: classpath:mapper/*.xml configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl jwt: secret: your-secret-key expire: 3600000啟動前先執(zhí)行CREATE DATABASE campus_secondhand DEFAULT CHARACTER SET utf8mb4;再導(dǎo)入SQL腳本。這里容易踩的一個坑是數(shù)據(jù)庫字符集沒設(shè)utf8mb4導(dǎo)致發(fā)布商品時中文表情符號存不進(jìn)去。5.3 Docker部署和常見報錯Docker部署SpringBoot項目其實(shí)很簡單本質(zhì)是打成一個jar包再丟進(jìn)容器。我給一個最簡DockerfileFROM openjdk:8-jdk-alpine VOLUME /tmp ARG JAR_FILEtarget/*.jar COPY ${JAR_FILE} app.jar EXPOSE 8080 ENTRYPOINT [java,-jar,/app.jar]構(gòu)建命令mvn clean package -DskipTests docker build -t campus-secondhand:1.0 . docker run -d -p 8080:8080 --name campus campus-secondhand:1.0下面是我排查過程中經(jīng)常遇到的幾個問題報錯信息原因解決辦法The server time zone value is unrecognizedMySQL連接URL缺少時區(qū)參數(shù)在url后加serverTimezoneAsia/ShanghaiFailed to configure a DataSource啟動時沒有找到數(shù)據(jù)源配置檢查application.yml是否在classpath數(shù)據(jù)庫是否已啟動java.io.FileNotFoundException: /tmp/...容器內(nèi)沒有上傳目錄權(quán)限D(zhuǎn)ockerfile里加RUN mkdir -p /data/upload并掛載volumeOutOfMemoryError: insufficient memory容器內(nèi)存限制啟動命令加-Xmx512m6. 這套代碼藏在SpringBoot框架里的面試考點(diǎn)防八股問倒6.1 自動配置到底是怎么回事“SpringBoot為什么能自動配置”是必問題。套用這個項目回答最合適項目里引入了spring-boot-starter-data-redisSpringBoot通過EnableAutoConfiguration去讀取META-INF/spring.factories或AutoConfiguration.imports里的自動配置類再配合ConditionalOnClass(RedisOperations.class)、ConditionalOnMissingBean這類條件注解自動幫我們創(chuàng)建RedisTemplate、StringRedisTemplate這些Bean。表面上是“自動配置”本質(zhì)上還是條件和工廠的結(jié)合。如果你需要定制可以在自己的配置類里聲明一個RedisTemplate的BeanConditionalOnMissingBean檢測到已經(jīng)存在就跳過自動創(chuàng)建。這段邏輯平時不顯眼但理解了之后排查“為什么我配置沒生效”會快很多。6.2 項目中哪些地方用到了AOP和事務(wù)事務(wù)用的是Transactional。面試官特別喜歡問“事務(wù)失效場景”我在項目里實(shí)際踩過createOrder方法調(diào)用本類另一個事務(wù)方法結(jié)果內(nèi)部方法的Transactional沒生效。原因很簡單Spring的事務(wù)是通過AOP代理實(shí)現(xiàn)的同類調(diào)用走的是this而不是代理對象所以代理切面根本沒執(zhí)行。解決辦法要么把內(nèi)部方法拆到另一個Service要么用AopContext.currentProxy()。AOP除了事務(wù)我還用它做管理員操作審計日志。比如審核商品、處理舉報這類后臺操作定義一個自定義注解AdminLog再寫一個Aspect切面在方法執(zhí)行前后記錄操作人、操作類型、操作參數(shù)、耗時。這樣比在每個Controller里手寫日志要清爽得多也展示了你對AOP的理解。6.3 表設(shè)計通用方法論和WMS數(shù)據(jù)庫設(shè)計是同一個套路有人問“WMS系統(tǒng)怎么設(shè)計數(shù)據(jù)庫表”時我意識到其實(shí)和二手交易平臺設(shè)計是同一套方法論。可以把“系統(tǒng)里所有重要業(yè)務(wù)對象”拆成四層主表記錄核心對象及其當(dāng)前狀態(tài)例如訂單表、入庫單表子表/明細(xì)表記錄核心對象包含的具體條目例如訂單明細(xì)、入庫單明細(xì)流水表記錄所有歷史變更例如交易流水、庫存變動流水唯一業(yè)務(wù)單號每張主表都生成一個全局唯一的業(yè)務(wù)編號order_no、入庫單號并建立唯一索引用于冪等和問題追溯這套方法論不是只能用在校園二手平臺WMS里的庫存管理、ERP里的訂單處理本質(zhì)上都是這樣一層一層拆出來的。聊到這個不僅能體現(xiàn)你會寫SQL還能體現(xiàn)你對系統(tǒng)設(shè)計的思考深度。7. 持續(xù)迭代方向不要把項目停在“演示可用”7.1 什么情況下不需要拆微服務(wù)很多人做完單體項目就想往上堆Nacos、Gateway、Feign覺得微服務(wù)顯得“高級”。我也曾經(jīng)這么做過但最后發(fā)現(xiàn)沒有千萬級用戶、沒有多團(tuán)隊并行開發(fā)微服務(wù)帶來的服務(wù)治理成本遠(yuǎn)大于收益。校園二手交易平臺用單體架構(gòu)完全合理真正需要演進(jìn)的方向不是拆服務(wù)而是把單體的代碼質(zhì)量和可觀測性做好比如加接口限流、日志采集、慢SQL監(jiān)控。7.2 想真正落地還需要補(bǔ)什么要讓這套系統(tǒng)在學(xué)校真正投入使用至少要補(bǔ)齊這幾塊真實(shí)支付微信/支付寶需要商戶資質(zhì)校園場景可以用模擬支付演示但代碼里要預(yù)留支付回調(diào)接口消息推送下單后需要通知賣家可以用RabbitMQ做異步通知避免下單響應(yīng)時間被郵件或短信拖慢內(nèi)容審核發(fā)布商品時圖片和文字需要先經(jīng)過云服務(wù)審核防止違規(guī)內(nèi)容數(shù)據(jù)脫敏管理員查看用戶列表時手機(jī)號、學(xué)號不能明文展示接口防刷用Redis實(shí)現(xiàn)滑動窗口限流避免商品詳情和登錄接口被惡意刷最后分享一個很實(shí)際的調(diào)試技巧。下單并發(fā)是一個容易翻車也特別容易出彩的測試點(diǎn)在本地啟動項目后用JMeter建20個線程同時搶同一件商品觀察請求返回和數(shù)據(jù)庫里該商品的stock_version、status變化。我第一次跑的時候出現(xiàn)了兩條訂單同時成功的現(xiàn)象后來正是在這條復(fù)現(xiàn)路徑上定位到問題——更新SQL漏了status2條件導(dǎo)致已經(jīng)預(yù)訂的商品還能被update。很多表面上“有源碼就完事”的項目恰恰在這種并發(fā)細(xì)節(jié)里見高下。本文還有配套的精品資源點(diǎn)擊獲取