簡介這份資源是基于微信小程序的旅游服務(wù)軟件完整項目后端采用Java與SSM框架開發(fā)配套數(shù)據(jù)庫腳本面向計算機相關(guān)專業(yè)畢業(yè)設(shè)計或初學(xué)小程序全棧開發(fā)的讀者。項目可在IntelliJ IDEA及微信開發(fā)者工具中直接導(dǎo)入運行數(shù)據(jù)庫為MySQL 8.0環(huán)境配置已做精簡適合快速啟動學(xué)習(xí)。壓縮包共22個文件包括19張界面截圖、2個源碼壓縮包和1個SQL數(shù)據(jù)庫文件整體約61.15MB結(jié)構(gòu)清晰便于按模塊查閱。功能覆蓋旅游攻略、旅游資訊、景點搜索、酒店信息、論壇中心、門票與酒店預(yù)訂、推薦路線、發(fā)帖互動及用戶管理等從用戶端到后端管理均有體現(xiàn)可幫助理解小程序與Java后端的數(shù)據(jù)交互、SSM框架分層設(shè)計和數(shù)據(jù)庫建模。目前已有2604人學(xué)習(xí)下載對有畢業(yè)設(shè)計需求或想系統(tǒng)掌握旅游類小程序開發(fā)流程的讀者具有較高參考價值。1. 微信小程序旅游服務(wù)軟件為什么后端Java開發(fā)才是項目源碼的重頭戲做旅游類微信小程序的人十個里有八個卡在同一步小程序端代碼拿到了數(shù)據(jù)庫文件導(dǎo)入了后端卻怎么都跑不起來。這個標(biāo)題其實點透了畢設(shè)和課設(shè)的核心——前端只是皮相真正的設(shè)計工作藏在Java后端和數(shù)據(jù)庫表結(jié)構(gòu)里。這篇文章從項目源碼的組織形式出發(fā)講清楚后端Spring Boot項目怎么搭、數(shù)據(jù)庫怎么設(shè)計、小程序怎么對接再把最容易翻車的幾個坑提前給你打上預(yù)防針。適合正在做這類項目的學(xué)生也適合想快速上手前后端分離項目實戰(zhàn)的初級Java開發(fā)。跟著走一遍你會知道這套方案能不能落地、值不值得往里投入時間。2. 搭起Spring Boot后端骨架選型、包結(jié)構(gòu)與第一個能跑的接口2.1 為什么選Spring Boot MyBatis-Plus而不是SSH或Servlet旅游服務(wù)軟件這類業(yè)務(wù)核心是用戶、景點、線路、訂單四組關(guān)系業(yè)務(wù)邏輯并不算復(fù)雜但接口數(shù)量多、表與表之間的關(guān)聯(lián)也多。Spring Boot的自動配置和Starter機制能省掉大量樣板代碼對拿到項目源碼后想快速跑起來的場景特別友好。更重要的一點是Spring Boot 2.x MyBatis-Plus的組合在中小型項目和畢業(yè)設(shè)計里已經(jīng)是事實標(biāo)準(zhǔn)網(wǎng)上能搜到的報錯和解決方案都很多遇到問題不至于卡死。MyBatis-Plus的價值在于把單表CRUD的代碼幾乎抹平了。景點表、評論表這類低頻變更的單表操作不需要為每個實體寫一套insert、select、update繼承一個BaseMapper就完事。旅游項目里最高頻的列表分頁查詢用它的Wrapper構(gòu)造條件兩行代碼就能寫出來。我不建議在這個階段引入過度復(fù)雜的架構(gòu)。很多人拿到源碼跑不起來往往不是因為功能多而是因為塞了Dubbo、Redis緩存、消息隊列這些重東西。旅游服務(wù)軟件的核心訴求是能跑、能講、能演示技術(shù)棧收斂到Spring Boot MyBatis-Plus MySQL 微信小程序原生開發(fā)已經(jīng)足夠撐起整個項目。2.2 包結(jié)構(gòu)劃分按業(yè)務(wù)模塊劃而非按技術(shù)層次劃拿到源碼后第一件事是看包結(jié)構(gòu)。我見過不少翻車的項目把controller、service、mapper按技術(shù)棧堆三層結(jié)果一個旅游項目幾十個接口全塞在一個Controller里改一個字段要翻十分鐘。常見的做法是按業(yè)務(wù)模塊分包結(jié)構(gòu)大概是這樣com.example.travel ├── config // 全局配置跨域、攔截器、文檔配置 ├── controller // 對外接口auth、spot、line、order ├── service // 業(yè)務(wù)邏輯 │ └── impl ├── mapper // MyBatis-Plus的Mapper接口 ├── entity // 數(shù)據(jù)庫實體 ├── dto // 前端入?yún)ο?├── vo // 返回給前端的視圖對象 └── common // 統(tǒng)一返回結(jié)構(gòu)、異常處理controller按auth、spot、line、order四個模塊拆開每個Controller只負責(zé)一類資源的接口。entity和dto分開是很多新手容易忽略的細節(jié)——如果數(shù)據(jù)庫字段直接暴露給前端一旦表結(jié)構(gòu)調(diào)整小程序端就得跟著改。用VO把返回字段裁剪一下是前后端分離項目實戰(zhàn)里最基本的解耦手段答辯時也能講出設(shè)計依據(jù)。2.3 最小可運行配置pom.xml與application.yml不管項目源碼長什么樣最終跑起來都靠這兩個文件。先看pom.xml的核心依賴我用Maven坐標(biāo)的方式列出來dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency dependency groupIdorg.springdoc/groupId artifactIdspringdoc-openapi-ui/artifactId version1.7.0/version /dependencyspring-boot-starter-web提供MVC能力mybatis-plus-boot-starter負責(zé)數(shù)據(jù)庫操作mysql-connector-java在運行期加載驅(qū)動。springdoc是Swagger的OpenAPI實現(xiàn)畢設(shè)答辯時直接打開/swagger-ui.html就能看到一個可交互的接口文檔頁面比現(xiàn)場翻代碼講更直觀。注意MyBatis-Plus 3.5.x配Spring Boot 2.7是經(jīng)過大量項目驗證的搭配版本不要隨便升到4.x否則很多配置項會變。application.yml里最關(guān)鍵的三個配置是數(shù)據(jù)源、MyBatis-Plus的駝峰映射、日期格式server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/travel_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver mybatis-plus: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0url里必須帶serverTimezoneAsia/Shanghai否則MySQL 8.x會直接報時區(qū)錯誤這是最常見的啟動失敗原因之一。map-underscore-to-camel-case打開后數(shù)據(jù)庫的spot_name字段能自動映射到實體的spotName屬性不用寫繁瑣的resultMap。日志輸出打開開發(fā)階段每個SQL都會打印到控制臺排查問題時這是第一手線索。到這里一個最小后端已經(jīng)具備跑起來的條件。寫一個測試接口驗證RestController RequestMapping(/api/health) public class HealthController { GetMapping public ResultString health() { return Result.success(travel backend is running); } }調(diào)用GET /api/health能返回success就說明骨架通了。這里的Result是統(tǒng)一返回包裝類后面的所有接口都會復(fù)用這個結(jié)構(gòu)。我不建議在這個階段急著往下寫業(yè)務(wù)先把跨域配置和全局異常處理加上。小程序端本身沒有CORS機制的限制但如果你用H5方式調(diào)試頁面CORS就繞不開。在config包下加一個WebMvcConfigurer實現(xiàn)類addCorsMappings里放行所有路徑和本地開發(fā)端口即可。提示如果啟動時提示8080端口被占用先執(zhí)行netstat -ano | findstr 8080找到占用進程再決定是換端口還是清理進程。至此項目源碼的后端部分已經(jīng)從一堆文件變成了一個能響應(yīng)的服務(wù)。接下來進入真正有設(shè)計含量的部分——數(shù)據(jù)庫表結(jié)構(gòu)這決定了景點、線路、訂單三塊業(yè)務(wù)能不能在答辯時講出邏輯閉環(huán)。3. 旅游業(yè)務(wù)數(shù)據(jù)模型用戶、景點、訂單三張核心表的設(shè)計細節(jié)3.1 用戶表與微信登錄字段的設(shè)計不含支付功能的旅游小程序用戶表不需要存密碼。核心字段是openid、昵稱、頭像、手機號。openid是微信體系下用戶的唯一標(biāo)識小程序端通過wx.login拿到code后端用code換openid這張表就是整個登錄體系的錨點。CREATE TABLE user ( id bigint(20) NOT NULL AUTO_INCREMENT, openid varchar(64) NOT NULL COMMENT 微信openid, nickname varchar(64) DEFAULT NULL COMMENT 昵稱, avatar varchar(255) DEFAULT NULL COMMENT 頭像URL, phone varchar(20) DEFAULT NULL COMMENT 手機號, gender tinyint(1) DEFAULT 0 COMMENT 性別 0未知 1男 2女, create_time datetime DEFAULT CURRENT_TIMESTAMP, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, deleted tinyint(1) DEFAULT 0, PRIMARY KEY (id), UNIQUE KEY uk_openid (openid) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用戶表;openid字段一定要加唯一索引。同一用戶重復(fù)調(diào)用登錄接口時后端應(yīng)該按openid去更新用戶信息而不是重復(fù)插入。deleted字段配合MyBatis-Plus的邏輯刪除用戶注銷時不會物理刪除數(shù)據(jù)歷史訂單還能關(guān)聯(lián)上。create_time和update_time直接由數(shù)據(jù)庫維護不需要在實體里手動賦值MyBatis-Plus的insert和update語句會自動跳過這兩個字段。3.2 景點與線路別把兩張表合成一張旅游項目的核心資源是景點和線路。景點是靜態(tài)資源線路是動態(tài)組合。新手常見的設(shè)計錯誤是把線路直接做成一個字段存景點ID列表比如line_detail字段存1,2,3,4看起來方便但要查某個景點被哪些線路包含時必須用LIKE %2%去模糊匹配——不僅慢還會匹配錯誤。正確的做法是線路主表加一張線路-景點關(guān)聯(lián)表CREATE TABLE line_spot ( id bigint(20) NOT NULL AUTO_INCREMENT, line_id bigint(20) NOT NULL COMMENT 線路ID, spot_id bigint(20) NOT NULL COMMENT 景點ID, sort_order int(11) DEFAULT 0 COMMENT 游覽順序, PRIMARY KEY (id), KEY idx_line_id (line_id), KEY idx_spot_id (spot_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT線路景點關(guān)聯(lián)表;sort_order字段記錄景點的游覽順序這是旅游線路區(qū)別于一般商品列表的地方。查詢線路詳情時按line_id過濾、sort_order排序就能還原出一條完整的游覽動線。關(guān)聯(lián)表是數(shù)據(jù)庫多對多關(guān)系的標(biāo)準(zhǔn)拆法答辯時能講清楚這一點比堆技術(shù)名詞更讓老師信服。景點表本身相對簡單但要注意幾個字段的類型取舍。景點描述用TEXT不要用VARCHAR(255)因為真實景點的介紹文案動輒幾百字。封面圖URL用VARCHAR(512)現(xiàn)在云存儲的URL普遍帶簽名參數(shù)長度經(jīng)常超255。景點經(jīng)緯度用DECIMAL(10,6)而不是FLOAT避免浮點精度導(dǎo)致地圖定位偏移。3.3 訂單表價格快照與狀態(tài)機的設(shè)計價值訂單表是整個項目里數(shù)據(jù)設(shè)計含金量最高的部分。旅游訂單的特點是下單時的價格和出行時的價格可能不同因此必須做價格快照。如果訂單表只存line_id再去關(guān)聯(lián)查詢當(dāng)前價格一旦后臺改了線路價格歷史訂單就失真了。CREATE TABLE order ( id bigint(20) NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 訂單號, user_id bigint(20) NOT NULL COMMENT 用戶ID, line_id bigint(20) DEFAULT NULL COMMENT 線路ID, spot_id bigint(20) DEFAULT NULL COMMENT 景點ID單景點門票時使用, title varchar(100) NOT NULL COMMENT 訂單展示名稱快照, cover varchar(512) DEFAULT NULL COMMENT 封面圖快照, price decimal(10,2) NOT NULL COMMENT 成交單價快照, quantity int(11) DEFAULT 1 COMMENT 數(shù)量, total_amount decimal(10,2) NOT NULL COMMENT 成交總價, contact_name varchar(20) NOT NULL COMMENT 聯(lián)系人, contact_phone varchar(20) NOT NULL COMMENT 聯(lián)系電話, travel_date date DEFAULT NULL COMMENT 出行日期, status tinyint(2) DEFAULT 0 COMMENT 0待支付 1已支付 2已完成 3已取消, create_time datetime DEFAULT CURRENT_TIMESTAMP, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, deleted tinyint(1) DEFAULT 0, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_user_id (user_id), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT旅游訂單表;title、cover、price這三個快照字段是重點。下單那一刻的線路名稱、封面、價格被復(fù)制到訂單表里之后后臺修改線路信息訂單數(shù)據(jù)不受影響。這種做法在電商系統(tǒng)里叫快照模式是答辯時實打?qū)嵉脑O(shè)計亮點。status字段用tinyint存數(shù)字狀態(tài)值比用字符串更節(jié)省空間也便于后期擴展?fàn)顟B(tài)機。建議在Java代碼里用枚舉類維護這些狀態(tài)值而不是在業(yè)務(wù)代碼里寫0、1、2這種魔法數(shù)字。3.4 數(shù)據(jù)庫文件交付SQL腳本的四個細節(jié)項目源碼里帶的數(shù)據(jù)庫文件通常是.sql格式。交付時要注意四個細節(jié)。第一導(dǎo)出要包含CREATE DATABASE語句很多初學(xué)者拿到庫文件不知道要先建庫。第二初始化數(shù)據(jù)要覆蓋三個層級一個測試用戶、至少10條景點記錄、5條線路記錄這樣小程序端一打開就有內(nèi)容可看。第三字符集統(tǒng)一用utf8mb4否則用戶昵稱里的emoji表情會插入失敗。第四SQL文件里不要包含本地絕對路徑或數(shù)據(jù)庫密碼明文保護基本信息。導(dǎo)入數(shù)據(jù)庫時最常見的報錯是排序規(guī)則不兼容。utf8mb4_0900_ai_ci是MySQL 8.0的默認(rèn)排序規(guī)則如果導(dǎo)出用的8.0而本地跑的是5.7會直接導(dǎo)入失敗。解決辦法是導(dǎo)出時在Navicat或命令行里指定排序規(guī)則為utf8mb4_general_ci或者導(dǎo)入前用文本編輯器批量替換文件里的規(guī)則串。注意數(shù)據(jù)庫文件和你自己的后端代碼一樣是項目源碼的重要組成部分。答辯前導(dǎo)出一份干凈的初始數(shù)據(jù)備份比任何講解都更有說服力。4. 小程序端與Java后端對接登錄、列表、詳情頁的最小閉環(huán)4.1 wx.login換openid會話token的處理流程微信小程序的登錄跟傳統(tǒng)網(wǎng)頁完全不同沒有cookie機制也不適合每次請求都拿著openid去查用戶表。標(biāo)準(zhǔn)做法是小程序wx.login拿到code請求后端/auth/login接口后端拿著code向微信服務(wù)器換openid再用openid查詢或創(chuàng)建用戶最后生成一個自定義token返回給小程序端。小程序端把token存進storage后續(xù)所有請求都在header里帶上token。后端登錄接口的Controller層代碼大致是這樣PostMapping(/login) public ResultLoginVO login(RequestBody LoginDTO dto) { String code dto.getCode(); String openid wechatService.code2openid(code); User user userService.findOrCreate(openid); String token jwtUtil.generateToken(user.getId()); return Result.success(new LoginVO(token, user)); }code2openid方法封裝了向微信服務(wù)器發(fā)請求的邏輯用Spring的RestTemplate即可不需要額外引入HTTP庫。微信接口返回的是JSON其中openid和session_key是核心字段。session_key不要返回給小程序端它是后續(xù)解密手機號等敏感操作的密鑰暴露出去會有安全風(fēng)險。token生成用JWT而不是UUID因為JWT自包含后端不需要把token存在內(nèi)存里驗證時用密鑰解析即可適合小程序這種無狀態(tài)請求模型。JWT載荷里只放用戶ID和過期時間過期時間建議2小時旅游類應(yīng)用用戶使用頻率不高過期后重登一次成本很低。小程序端的請求封裝也很關(guān)鍵。wx.request每寫一次就要重復(fù)設(shè)置header、處理錯誤碼所以常見做法是封裝一個request.js統(tǒng)一管理const request (url, method GET, data {}) { return new Promise((resolve, reject) { wx.request({ url: getApp().globalData.baseUrl url, method: method, data: data, header: { Authorization: Bearer wx.getStorageSync(token) }, success: (res) { if (res.statusCode 401) { wx.navigateTo({ url: /pages/login/login }); reject(res); } else if (res.data.code 0) { resolve(res.data.data); } else { wx.showToast({ title: res.data.msg, icon: none }); reject(res.data); } }, fail: reject }); }); };這段代碼的邏輯是所有請求自動帶上Authorization頭后端攔截器對未攜帶token或token過期的請求返回401小程序端統(tǒng)一捕獲401并跳轉(zhuǎn)登錄頁。業(yè)務(wù)狀態(tài)用code0表示成功非0時用toast直接展示后端返回的msg。這樣前端不需要為每個接口單獨寫錯誤處理這個模式在前后端分離項目里是通用做法能把接口對接的代碼量減少三分之一。4.2 景點列表分頁后端參數(shù)與小程序端渲染的配合旅游小程序首頁通常是景點列表涉及分頁、搜索、排序三個參數(shù)。后端接口設(shè)計時分頁參數(shù)我習(xí)慣用一個統(tǒng)一的PageDTO作為入?yún)ublic class PageDTO { private Integer pageNum 1; private Integer pageSize 10; private String keyword; private String sort; }pageNum從1開始pageSize上限設(shè)置20防止有人一次性拉全量數(shù)據(jù)把數(shù)據(jù)庫拖垮。keyword用于按名稱模糊搜索景點sort支持default和price兩種排序模式。后端用MyBatis-Plus的Page對象做分頁查詢public PageSpotVO getSpotPage(PageDTO dto) { LambdaQueryWrapperSpot wrapper new LambdaQueryWrapper(); if (StringUtils.hasText(dto.getKeyword())) { wrapper.like(Spot::getName, dto.getKeyword()); } PageSpot page spotMapper.selectPage( new Page(dto.getPageNum(), dto.getPageSize()), wrapper); PageSpotVO result new Page(dto.getPageNum(), dto.getPageSize()); result.setTotal(page.getTotal()); result.setRecords(spotConverter.toVOList(page.getRecords())); return result; }LambdaQueryWrapper是MyBatis-Plus的條件構(gòu)造器spotMapper.selectPage第一個參數(shù)是分頁對象第二個是查詢條件。這里把實體轉(zhuǎn)成VO再返回避免數(shù)據(jù)庫字段直接暴露給前端。total總數(shù)對小程序端的滾動加載特別重要——當(dāng)已加載條數(shù)大于等于total時就該停止上拉分頁請求。小程序端用onReachBottom實現(xiàn)觸底加載維護pageNum和pageSize兩個data字段每次請求返回后累加列表數(shù)據(jù)而不是覆蓋。這里有一個新手常犯的錯誤pageNum放在data里但請求回調(diào)里忘記在成功后再1導(dǎo)致同一頁數(shù)據(jù)被重復(fù)加載。4.3 圖片資源與后端靜態(tài)資源映射旅游項目的圖片量很大景點封面、線路詳情圖、用戶頭像每張圖都走后端轉(zhuǎn)發(fā)不現(xiàn)實。常見做法是后端只存圖片URL圖片本身放云存儲。開發(fā)階段圖片放到后端項目的static目錄下通過Spring Boot的靜態(tài)資源映射訪問。Spring Boot默認(rèn)把classpath:/static/映射為根路徑所以把upload文件夾放在resources/static/upload下訪問http://localhost:8080/upload/spot1.jpg就能直接拿到圖片。圖片上傳接口是另一個容易踩坑的點。小程序端用wx.uploadFile上傳后端接收MultipartFile。Spring Boot的單個文件大小默認(rèn)限制是1MB景點高清圖動輒3MB以上必須提前調(diào)大限制spring: servlet: multipart: max-file-size: 10MB max-request-size: 20MBmax-file-size限制單個文件max-request-size限制整個請求體。文件上傳成功后返回給前端的應(yīng)該是可訪問的完整URL而不是一個相對路徑。我踩過這個坑接口返回了upload/20240601.jpg小程序端直接往域名后面拼接卻404原因就是沒有正確拼接請求根路徑。注意上線前圖片資源必須遷移到對象存儲并開啟CDN加速本地static目錄方案只適合開發(fā)和演示環(huán)境。5. 微信小程序旅游后端避坑指南5個讓我翻車的真實案例5.1 真機預(yù)覽請求全部失敗但開發(fā)工具里一切正常現(xiàn)象小程序在開發(fā)者工具里調(diào)后端接口全部成功一換成真機預(yù)覽所有請求全部超時報錯。原因微信小程序的網(wǎng)絡(luò)請求有嚴(yán)格的域名限制。開發(fā)者工具里可以勾選不校驗合法域名來跳過限制但真機上這個開關(guān)不起作用。后端localhost地址在真機上根本找不到而且小程序要求所有請求域名必須是HTTPS且在后臺配置過白名單。解決開發(fā)階段用手機連電腦的局域網(wǎng)IP訪問后端把后端啟動host改成0.0.0.0前端baseUrl改成http://局域網(wǎng)IP:8080。要真機調(diào)試HTTPS效果就用映射工具把本地的8080端口映射成一個公網(wǎng)HTTPS地址再把域名加到小程序后臺的request合法域名里。最終上線前必須配好備案域名和SSL證書云廠商一般都有免費證書申請入口在Nginx里配置HTTPS是固定套路這部分不是玄學(xué)照著官方文檔配一遍就能跑通。5.2 訂單時間總是差了8小時現(xiàn)象后端返回的create_time字段小程序端顯示比本地時間慢了8小時。數(shù)據(jù)庫里存的時間是正確的響應(yīng)JSON里卻變成了帶T的UTC格式。原因Jackson在序列化LocalDateTime時默認(rèn)使用UTC時區(qū)。后端服務(wù)器的系統(tǒng)時區(qū)、MySQL連接串里的serverTimezone、Jackson的時區(qū)配置三者不一致就會造成時間偏移。解決保持三重配置一致。第一application.yml里加spring.jackson.time-zoneGMT8和date-formatyyyy-MM-dd HH:mm:ss。第二MySQL連接串保持serverTimezoneAsia/Shanghai。第三實體里的時間字段加JsonFormat(patternyyyy-MM-dd HH:mm:ss, timezoneGMT8)注解兜底。改完這三處重啟后端再測一遍時間就對齊了。5.3 數(shù)據(jù)庫連接池耗盡頁面隨機卡死現(xiàn)象小程序端高頻請求后后端日志出現(xiàn)Connection is not available, request timed out部分接口偶發(fā)性超時重啟后才恢復(fù)。原因這是典型的數(shù)據(jù)庫連接池被打滿。某個Service方法內(nèi)加了事務(wù)注解事務(wù)內(nèi)又調(diào)用了外部HTTP接口HTTP接口響應(yīng)慢數(shù)據(jù)庫連接被事務(wù)長時間占用。默認(rèn)連接池大小只有1010個連接都被慢請求占滿后新請求全部排隊等連接。解決第一排查所有Transactional方法事務(wù)內(nèi)不要做遠程HTTP調(diào)用先完成數(shù)據(jù)庫操作再調(diào)外部接口或者用編程式事務(wù)精確控制邊界。第二把連接池調(diào)大并加監(jiān)控Spring Boot默認(rèn)使用HikariCPspring: datasource: hikari: maximum-pool-size: 30 minimum-idle: 10 connection-timeout: 30000把maximum-pool-size調(diào)到30只是緩解癥狀根因還是事務(wù)內(nèi)不要做遠程調(diào)用?？梢杂靡粋€AOP切面把執(zhí)行超過1秒的事務(wù)方法打印到日志里快速定位慢事務(wù)才能真正解決問題。5.4 用戶連續(xù)點擊下單生成了兩條重復(fù)訂單現(xiàn)象用戶在小程序端雙擊立即預(yù)訂按鈕后端收到兩個幾乎同時到達的下單請求數(shù)據(jù)庫里出現(xiàn)了兩條相同的訂單記錄。原因前端只做了按鈕loading狀態(tài)但loading生效前的瞬間兩個請求已經(jīng)發(fā)出。后端沒有做任何冪等校驗insert語句被重復(fù)執(zhí)行。解決訂單表上已經(jīng)建了order_no唯一索引但如果訂單號生成邏輯放在事務(wù)內(nèi)用時間戳生成同一毫秒的兩次請求仍可能撞號。常見的做法是前端在點擊下單時生成一個requestId傳給后端后端判斷requestId是否處理過處理過就直接返回已有訂單。更穩(wěn)的方案是在訂單表上建(user_id, line_id, travel_date)的聯(lián)合唯一索引讓重復(fù)插入直接拋異常再在Service層捕獲異常返回請勿重復(fù)操作。這個方案不依賴前端配合數(shù)據(jù)庫層直接兜底。5.5 圖片加載白屏控制臺報錯圖片鏈接未授權(quán)現(xiàn)象小程序端打開景點詳情頁輪播圖區(qū)域白屏控制臺提示下載圖片失敗。原因圖片URL是后端拼接的域名可能是localhost或IP地址微信小程序?qū)W(wǎng)絡(luò)圖片有緩存和域名校驗機制。更隱蔽的原因是圖片URL中包含了符號被解析成多個參數(shù)實際訪問的URL被截斷了。解決第一所有圖片URL統(tǒng)一返回完整路徑即https://域名/ 相對路徑不要返回相對路徑讓前端自己拼。第二后端生成URL時對查詢參數(shù)做encodeURIComponent編碼前端拿到后用decodeURIComponent還原避免特殊字符被截斷。第三如果用了云存儲圖片域名必須加入小程序后臺的downloadFile合法域名否則真機上永遠加載不出來。6. 項目驗收前的三個驗證技巧讓代碼在答辯時不出丑到這里項目已經(jīng)能跑起來了。但能跑和能演示之間還有一段距離。我總結(jié)三個自己驗收前必做的驗證動作每個都能提前暴露問題。第一個是接口全量冒煙測試。用Postman或Apifox把項目里的所有接口按業(yè)務(wù)鏈路串起來跑一遍從登錄拿到token到創(chuàng)建訂單、查詢訂單、取消訂單覆蓋整條主流程。重點觀察返回狀態(tài)碼和響應(yīng)耗時。我習(xí)慣在Postman里設(shè)一個全局變量token登錄接口里用一段test腳本自動提取token后續(xù)請求全部引用{{token}}這樣能真實模擬前端調(diào)用順序。第二個是事務(wù)回滾驗證。找一個修改類接口故意讓SQL執(zhí)行失敗比如給一個不存在的ID傳參看接口是否正確返回錯誤碼以及數(shù)據(jù)庫里是否發(fā)生了部分更新。這個驗證直接對應(yīng)答辯時老師最常問的問題如果下單流程里第二步失敗了第一步的訂單會留下來嗎在Service層加上Transactional并驗證回滾后你就能有底氣地回答。第三個是日志檢查。把后端控制臺日志打開跑一遍核心流程看有沒有MyBatis打印出select *全量查詢有沒有重復(fù)執(zhí)行的相同SQL。全量查詢在景點列表這種接口里非常常見原因通常是實體關(guān)聯(lián)字段沒做懶加載。把慢SQL日志打開你會發(fā)現(xiàn)很多接口的耗時集中在某幾張表的關(guān)聯(lián)上這時候在JOIN字段上補索引比加Redis緩存更直接有效。最后分享一個我的習(xí)慣答辯前一周把數(shù)據(jù)庫導(dǎo)出一份干凈的備份放到項目源碼的database目錄下。這樣不管演示時數(shù)據(jù)被改成什么樣隨時能一鍵還原回初始狀態(tài)。這個習(xí)慣救過我很多次也希望幫到你。本文還有配套的精品資源點擊獲取