做 Java 后端開發(fā)的人應(yīng)該都見過或者寫過寵物領(lǐng)養(yǎng)救助平臺這類項目?；?Java Spring Boot 的寵物領(lǐng)養(yǎng)救助系統(tǒng)核心是把寵物發(fā)布、領(lǐng)養(yǎng)申請、救助登記、后臺審核這些事串成一條完整業(yè)務(wù)鏈而不是簡單堆幾個增刪改查頁面。這套項目對剛接觸 Spring Boot 的人特別合適也能幫準(zhǔn)備做課程設(shè)計或畢業(yè)設(shè)計的人少走彎路。我陸續(xù)看過幾套類似源碼很多代碼思路大同小異這篇文章把這類項目從需求、表結(jié)構(gòu)、后端實現(xiàn)到部署排查一條線講清楚。如果你手頭已經(jīng)有一套源碼文檔運行視頻講解視頻配合這篇來理解效果會好很多。1. 先搞清楚平臺要給誰用需求拆解與模塊設(shè)計很多同學(xué)拿到這種項目第一反應(yīng)就是趕緊把數(shù)據(jù)庫導(dǎo)進(jìn)去、把后端跑起來結(jié)果看頁面時才發(fā)現(xiàn)“不知道這個按鈕對應(yīng)哪段代碼”。所以我不建議急著啟動先把需求盤一遍。所謂寵物領(lǐng)養(yǎng)救助平臺表面上是在做寵物信息管理實際上是在做兩條業(yè)務(wù)線。第一條是領(lǐng)養(yǎng)線機構(gòu)或個人發(fā)布待領(lǐng)養(yǎng)寵物普通用戶瀏覽、申請、等待審核審核通過后完成領(lǐng)養(yǎng)。第二條是救助線發(fā)現(xiàn)流浪或受傷寵物的人發(fā)布求助信息救助站或志愿者接單平臺記錄救助進(jìn)度和結(jié)果。兩條線都會落到用戶、寵物、申請、救助記錄這些核心數(shù)據(jù)上所以數(shù)據(jù)庫設(shè)計必須圍繞這幾類實體展開。1.1 三類用戶畫像與業(yè)務(wù)場景最常見的用戶角色有三種。普通用戶是平臺的主要使用者主要做四件事注冊登錄、瀏覽寵物、提交領(lǐng)養(yǎng)申請、查看自己的申請進(jìn)度。救助站管理員是內(nèi)容維護(hù)者負(fù)責(zé)發(fā)布待領(lǐng)養(yǎng)寵物、上傳寵物照片、審核領(lǐng)養(yǎng)申請、登記救助記錄。平臺超級管理員則負(fù)責(zé)用戶管理、內(nèi)容下架、統(tǒng)計報表等更高權(quán)限的操作。舉一個典型場景某用戶在馬路上發(fā)現(xiàn)一只被遺棄的小貓先拍照發(fā)布一條救助信息救助站接手后給小貓做體檢再把小貓的檔案生成寵物信息并標(biāo)記為“待領(lǐng)養(yǎng)”。這時另一位用戶看到小貓信息覺得合適就提交領(lǐng)養(yǎng)申請。管理員在后臺看到這條申請核對養(yǎng)寵條件和家庭情況審核通過后寵物狀態(tài)自動變成“已領(lǐng)養(yǎng)”。這個過程中救助信息、寵物信息、申請記錄是分離的但又通過用戶和寵物建立關(guān)聯(lián)。這套流程想通了代碼結(jié)構(gòu)也就不容易跑偏。1.2 功能模塊到底要拆成幾塊按業(yè)務(wù)場景拆整個系統(tǒng)可以分成五個核心模塊用戶認(rèn)證模塊注冊、登錄、個人資料、JWT Token 管理。寵物信息模塊寵物列表、詳情、分類篩選、發(fā)布、圖片上傳、狀態(tài)管理。領(lǐng)養(yǎng)申請模塊提交申請、取消申請、后臺審核、領(lǐng)養(yǎng)記錄查詢。救助模塊發(fā)布求助、救助進(jìn)度更新、救助記錄展示。后臺管理模塊用戶管理、寵物審核、申請審核、救助信息管理、數(shù)據(jù)統(tǒng)計。救助模塊容易被人忽略很多實現(xiàn)只是把它做成了靜態(tài)新聞公告。實際上救助記錄和領(lǐng)養(yǎng)申請是兩套完全不同的狀態(tài)流救助記錄關(guān)注“是否已有人接手、救助進(jìn)展到哪一步”領(lǐng)養(yǎng)申請關(guān)注“是否通過審核、寵物是否完成領(lǐng)養(yǎng)”。如果強行合在同一張表里后面寫狀態(tài)判斷時會很痛苦。1.3 為什么采用 Spring Boot 單體分層架構(gòu)第一次接觸這類項目的人常問既然技術(shù)棧里有 Spring Boot、MyBatis、Redis、Vue為什么不做成微服務(wù)我的看法是這種校園項目、課程設(shè)計或者中小型平臺用單體分層架構(gòu)是性價比最高的選擇。微服務(wù)的好處是模塊隔離和獨立擴展但代價是服務(wù)注冊、配置中心、分布式事務(wù)、鏈路追蹤這些額外復(fù)雜度。寵物領(lǐng)養(yǎng)平臺的用戶量、業(yè)務(wù)復(fù)雜度完全沒到需要拆分的地步單體應(yīng)用部署簡單、調(diào)試方便一個 Spring Boot 進(jìn)程就能把后端全部跑起來。再加上 Spring Boot 本身自帶自動配置、內(nèi)嵌 Tomcat、眾多 Starter配合 MyBatis-Plus 做數(shù)據(jù)訪問幾天時間就能把骨架搭完。分層結(jié)構(gòu)也足夠清晰Controller 接收請求Service 處理業(yè)務(wù)Mapper 訪問數(shù)據(jù)庫Entity 映射表結(jié)構(gòu)。先用單體把業(yè)務(wù)邏輯想清楚比一上來就追新架構(gòu)靠譜得多。2. 數(shù)據(jù)庫設(shè)計狀態(tài)字段定好了后面少寫很多改動表結(jié)構(gòu)設(shè)計是這類項目最容易決定后期工作量的地方。我每次拿到一套源碼不會先看代碼而是先打開 SQL 文件看三張核心表寵物表、領(lǐng)養(yǎng)申請表、用戶表。這幾張表的結(jié)構(gòu)設(shè)計基本能反映整個項目的質(zhì)量。2.1 核心表結(jié)構(gòu)與字段說明一套完整但不過度設(shè)計的表結(jié)構(gòu)通常包括下面這些表表名主要作用關(guān)鍵字段user普通用戶和管理員id, username, password, phone, avatar, user_type, statuspet寵物信息id, pet_name, breed, age, sex, city, cover_image, description, publisher_id, statusadoption_application領(lǐng)養(yǎng)申請id, pet_id, user_id, applicant_name, phone, address, reason, status, audit_remarkrescue_record救助記錄id, title, address, description, images, contact_phone, status, create_timeadmin管理員賬號id, username, password, rolenotice平臺公告id, title, content, create_time寵物表里的 publisher_id 關(guān)聯(lián) user 表表示這條寵物信息是誰發(fā)布的。adoption_application 表通過 pet_id 和 user_id 把申請人和寵物關(guān)聯(lián)起來后臺審核時只要依據(jù)這兩個外鍵關(guān)系去更新狀態(tài)即可。表字段不一定要多豪華重點是能支撐狀態(tài)流轉(zhuǎn)并且保證之后加字段不傷筋動骨。2.2 狀態(tài)字段與業(yè)務(wù)狀態(tài)流轉(zhuǎn)狀態(tài)字段是整個項目里最容易寫錯邏輯的地方。我會在數(shù)據(jù)庫里把狀態(tài)都定義成 tinyint并用注釋寫明含義避免代碼里到處是魔法數(shù)字。寵物表的狀態(tài)建議這樣設(shè)計status含義0待審核1待領(lǐng)養(yǎng)2已領(lǐng)養(yǎng)3已下架領(lǐng)養(yǎng)申請表的狀態(tài)建議這樣設(shè)計status含義0待審核1已通過2已拒絕狀態(tài)流轉(zhuǎn)的核心規(guī)則是管理員審核通過寵物發(fā)布后寵物從 0 變?yōu)?1用戶提交領(lǐng)養(yǎng)申請后申請記錄為 0管理員審核申請通過后申請變?yōu)?1同時寵物表從 1 變?yōu)?2如果審核拒絕申請變?yōu)?2寵物繼續(xù)保持在 1等待下一位申請者。這里有一個很常見的坑同一只寵物可能有多條待審核申請如果管理員通過了其中一條另外幾條申請應(yīng)該自動變成已拒絕或已取消否則就會造成同一只寵物被“重復(fù)領(lǐng)養(yǎng)”。很多初級項目沒有處理這個邏輯導(dǎo)致寵物狀態(tài)已經(jīng)變成 2其他申請還是待審核狀態(tài)。處理方式很簡單在領(lǐng)養(yǎng)申請審核通過的代碼里額外更新同寵物下所有狀態(tài)為 0 的申請。2.3 外鍵、索引與刪除策略的取舍很多教材里強調(diào)外鍵約束但真實項目里我一般不建議加物理外鍵。物理外鍵會讓插入、刪除順序變得很嚴(yán)格比如先刪寵物還是先刪申請一旦順序反了就會報錯而且系統(tǒng)后期拆分或遷移數(shù)據(jù)時物理外鍵還會成為負(fù)擔(dān)。正確做法是在 Java 代碼里通過 Service 層保證數(shù)據(jù)一致性只在表字段上建普通索引。需要重點關(guān)注的索引有三個pet 表的 status 和 city 聯(lián)合索引adoption_application 表的 pet_id 和 user_id 聯(lián)合索引rescue_record 表的 status 索引。這些字段都是查詢和篩選的高頻條件。刪除策略上不太建議直接物理刪除寵物信息。用戶已經(jīng)提交過申請且申請記錄里關(guān)聯(lián)了寵物 id如果寵物被物理刪除后臺查看歷史申請時會變成空數(shù)據(jù)。更好的做法是用邏輯刪除給表加一個 deleted 字段查詢時統(tǒng)一過濾?；蛘吒唵我稽c直接用 status3已下架來替代刪除既保留數(shù)據(jù)又方便用戶申訴和后臺追蹤。3. 后端功能實現(xiàn)從登錄到領(lǐng)養(yǎng)審核的完整鏈路后端代碼看起來模塊很多但真正撐起業(yè)務(wù)核心的只有幾個部分統(tǒng)一返回結(jié)構(gòu)、登錄鑒權(quán)、文件上傳、領(lǐng)養(yǎng)審核、列表查詢。把這五塊吃透項目的骨架就明白了。3.1 統(tǒng)一返回體、異常處理與分層約定前后端聯(lián)調(diào)最容易出現(xiàn)的問題就是接口返回格式不統(tǒng)一。今天返回{data: xxx}明天返回{result: xxx}前端寫起來非常痛苦。所以項目里必須有一個統(tǒng)一返回體。Data public class ResultT { private Integer code; private String msg; private T data; public static T ResultT ok(T data) { ResultT r new Result(); r.code 200; r.msg ok; r.data data; return r; } public static T ResultT fail(Integer code, String msg) { ResultT r new Result(); r.code code; r.msg msg; return r; } }配合一個全局異常處理器可以把業(yè)務(wù)異常和技術(shù)異常統(tǒng)一攔截。比如用戶提交領(lǐng)養(yǎng)申請時寵物已經(jīng)不存在Service 層直接拋出BusinessException由RestControllerAdvice統(tǒng)一轉(zhuǎn)成Result.fail(400, e.getMessage())。這樣 Controller 層就不用每個方法都寫 try-catch代碼會干凈很多。分層時記住一條紅線Controller 不寫業(yè)務(wù)邏輯只做參數(shù)接收和結(jié)果轉(zhuǎn)換Service 不做 SQL 拼接只調(diào) Mapper 方法復(fù)雜查詢才在 Mapper XML 里寫 SQL。3.2 JWT 登錄鑒權(quán)與密碼處理HTTP 接口本身是無狀態(tài)的登錄之后怎么知道調(diào)用者是誰主流做法就是 JWT。用戶登錄成功后后端生成一個 token 返回給前端前端在后續(xù)請求的 Header 里帶上Authorization: token后端通過攔截器解析 token 得到用戶 id 和角色。String token Jwts.builder() .setSubject(user.getId().toString()) .claim(username, user.getUsername()) .setExpiration(new Date(System.currentTimeMillis() 1000 * 60 * 60 * 24 * 7)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact();攔截器里需要做三件事讀取 Header 里的 token解析 token 是否過期把解析出的用戶信息放到當(dāng)前請求上下文中。注意放行登錄、注冊、寵物列表這些公開接口不要一棍子把所有接口都攔掉否則前端在未登錄狀態(tài)連首頁都打不開。密碼處理這塊不管項目復(fù)雜度多高都不要存明文。至少要用 MD5 加鹽更好的是用 BCrypt。加鹽的目的是防止彩虹表直接反推BCrypt 則自帶鹽值和強度參數(shù)安全性更高。3.3 寵物發(fā)布、圖片上傳與靜態(tài)資源映射寵物信息里圖片是剛需上傳接口要解決的問題有三個文件存到哪里、怎么防止文件名沖突、前端怎么訪問到這張圖。我比較推薦的做法是把文件保存到本機某個業(yè)務(wù)目錄比如項目根目錄下的upload/文件夾文件名用 UUID 重命名數(shù)據(jù)庫只存相對路徑。這樣數(shù)據(jù)庫和磁盤文件不會因為重名互相覆蓋而且未來如果要遷移到云存儲只需要改動上傳方法數(shù)據(jù)庫字段不用變。PostMapping(/upload) public ResultString upload(RequestParam(file) MultipartFile file) { if (file.isEmpty()) { return Result.fail(400, 文件不能為空); } String originalFilename file.getOriginalFilename(); String suffix originalFilename ! null ? originalFilename.substring(originalFilename.lastIndexOf(.)) : .jpg; String fileName UUID.randomUUID() suffix; Path targetPath Paths.get(uploadDir).resolve(fileName); file.transferTo(targetPath); return Result.ok(/uploads/ fileName); }上傳之后還要配置靜態(tài)資源映射否則/uploads/xxx.jpg會直接 404。Configuration public class WebMvcConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/uploads/**) .addResourceLocations(file: uploadDir /); } }這里有個細(xì)節(jié)uploadDir最好用絕對路徑并且提前創(chuàng)建目錄。很多人用相對路徑結(jié)果在 IDE 里啟動正常打成 jar 包后路徑就變了圖片全部丟失。3.4 領(lǐng)養(yǎng)申請與后臺審核的事務(wù)實現(xiàn)領(lǐng)養(yǎng)審核是整個系統(tǒng)里最需要寫事務(wù)的地方。它的核心邏輯是更新申請的審核狀態(tài)如果審核通過還要同步更新寵物狀態(tài)。這兩步必須在一個事務(wù)里完成否則可能出現(xiàn)申請已通過但寵物還是待領(lǐng)養(yǎng)的情況。Transactional(rollbackFor Exception.class) public void auditAdoption(Long applicationId, Integer auditStatus, String remark) { AdoptionApplication app adoptionApplicationMapper.selectById(applicationId); if (app null || app.getStatus() ! 0) { throw new BusinessException(申請不存在或已處理); } app.setStatus(auditStatus); app.setAuditRemark(remark); app.setAuditTime(LocalDateTime.now()); adoptionApplicationMapper.updateById(app); if (auditStatus 1) { Pet pet petMapper.selectById(app.getPetId()); pet.setStatus(2); petMapper.updateById(pet); // 同一寵物其他待審核申請自動置為已拒絕 LambdaUpdateWrapperAdoptionApplication updateWrapper new LambdaUpdateWrapper(); updateWrapper.eq(AdoptionApplication::getPetId, app.getPetId()) .eq(AdoptionApplication::getStatus, 0) .set(AdoptionApplication::getStatus, 2) .set(AdoptionApplication::getAuditRemark, 該寵物已被領(lǐng)養(yǎng)); adoptionApplicationMapper.update(null, updateWrapper); } }為什么老項目會在這里出問題最常見的原因是把Transactional加在 Controller 方法上或者在同類的另一個方法里直接調(diào)用結(jié)果事務(wù)沒有生效。正確玩法是把事務(wù)加在 Service 實現(xiàn)類的 public 方法上并且保證異常能被 Spring 捕獲。如果方法內(nèi)部自己 try-catch 把異常吞掉Spring 是不會回滾的。3.5 列表篩選和分頁查詢的常規(guī)寫法寵物列表頁是用戶第一眼看到的東西接口要支持分頁還要支持按城市、品種、狀態(tài)篩選。用 MyBatis-Plus 的LambdaQueryWrapper可以寫得很清晰不需要在 XML 里拼 SQL。PagePet page petMapper.selectPage( new Page(pageNum, pageSize), new LambdaQueryWrapperPet() .eq(StringUtils.isNotBlank(city), Pet::getCity, city) .like(StringUtils.isNotBlank(breed), Pet::getBreed, breed) .eq(Pet::getStatus, 1) .orderByDesc(Pet::getCreateTime) );使用 LambdaQueryWrapper 的好處有兩個一是字段名用方法引用不會寫錯列名二是條件對象是StringUtils.isNotBlank當(dāng)參數(shù)為空時這段條件自動拼不上避免了 SQL 注入風(fēng)險。分頁對象自帶 total、current、pages 這些字段前端直接展示即可。特別注意如果有多個篩選條件一定不要在 Java 代碼里字符串拼接 SQL這是項目里的高危行為。4. 前端頁面與接口聯(lián)調(diào)別只盯著后端代碼很多人的注意力全放在后端結(jié)果啟動項目后發(fā)現(xiàn)頁面白屏、接口 404。前端和后端是配合關(guān)系哪怕源碼里已經(jīng)有現(xiàn)成頁面也得知道每個頁面在調(diào)哪個接口。4.1 用戶端和管理端的頁面劃分用戶端重點看六個頁面首頁寵物列表、寵物詳情頁、領(lǐng)養(yǎng)申請頁、救助信息發(fā)布頁、個人中心、登錄注冊頁。管理端重點看寵物管理、領(lǐng)養(yǎng)審核、救助管理、用戶管理、數(shù)據(jù)統(tǒng)計。每個管理頁面背后基本都是一個分頁列表接口加上一個新增加、修改、刪除接口。如果前端是 Vue 單頁應(yīng)用核心在路由配置和請求封裝。路由對應(yīng)頁面請求封裝統(tǒng)一處理 token 注入和返回體解析。如果前端是簡單模板頁面那更要注意表單提交的字段名和后端實體字段是否一致。不一致是最常見的聯(lián)調(diào)問題比如后端字段叫phone前端提交的是tel后臺直接收到 null。4.2 接口路徑和返回格式約定接口設(shè)計建議統(tǒng)一 RESTful 風(fēng)格方便前后端記憶方法路徑說明POST/api/user/register用戶注冊POST/api/user/login用戶登錄GET/api/pet/list寵物分頁列表GET/api/pet/detail/{id}寵物詳情POST/api/adoption/apply提交領(lǐng)養(yǎng)申請POST/api/admin/adoption/audit審核領(lǐng)養(yǎng)申請GET/api/rescue/list救助列表POST/api/upload圖片上傳鑒權(quán)規(guī)則上普通用戶接口要求帶 token管理員接口還要校驗角色。攔截器在進(jìn)入 Controller 之前把角色信息解析出來如果普通用戶訪問 admin 接口直接返回 403。這樣權(quán)限判斷不會散落到每個業(yè)務(wù)方法里。4.3 聯(lián)調(diào)時最容易出問題的幾個位置第一個是跨域。前端跑在 5173 或 8081后端跑在 8080瀏覽器默認(rèn)會攔截跨域請求。后端需要配置 CorsFilter 或者實現(xiàn)WebMvcConfigurer的addCorsMappings。第二個是日期格式。Java 的LocalDateTime默認(rèn)序列化出來是一串?dāng)?shù)組前端根本沒法用要配置 Jackson 的日期格式。第三個是文件路徑。前端拿到的圖片地址是不是完整 URL能不能直接放進(jìn) img 標(biāo)簽這些都要提前約定好。5. 本地部署運行拿到源碼后從0跑起來的完整步驟我不建議拿到項目就直接點啟動按鈕因為大概率會因為環(huán)境問題報一堆錯。先按順序做好環(huán)境確認(rèn)和配置修改整個過程會順暢很多。5.1 環(huán)境版本與安裝注意點不同源碼用到的基礎(chǔ)版本差異很大先看項目的 pom.xml 和前端 package.json 再動手組件推薦版本說明JDK1.8 或 11Spring Boot 2.x 用 1.8 最穩(wěn)Maven3.6 以上管理后端依賴MySQL5.7 或 8.05.7 兼容性最好Redis5.0 以上如果項目引用了 Redis 依賴才需要Node.js14 或 16前端 Vue 項目構(gòu)建用IDEIntelliJ IDEA直接導(dǎo)入 Maven 工程有個小技巧啟動前先檢查 pom.xml 里是否引用了 Redis、RabbitMQ 這類中間件如果引用了本地環(huán)境沒有啟動對應(yīng)服務(wù)后端會直接啟動失敗。確認(rèn)依賴都齊全后再進(jìn)入下一步。5.2 修改配置文件的核心地方后端核心配置集中在 application.yml主要改數(shù)據(jù)庫連接和文件上傳路徑。server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/pet_adoption?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver servlet: multipart: max-file-size: 10MB max-request-size: 20MB mybatis-plus: mapper-locations: classpath*:mapper/**/*.xml configuration: map-underscore-to-camel-case: true這里要注意三個細(xì)節(jié)。serverTimezoneAsia/Shanghai不寫MySQL 8 下經(jīng)常報時間連接錯誤。map-underscore-to-camel-case必須開否則數(shù)據(jù)庫里的create_time映射不到 Java 的createTime。文件上傳大小限制默認(rèn)只有 1MB寵物圖片稍微大一點就會被攔所以手動放大到 10MB。前端項目的接口地址也要看一眼如果寫死了localhost:8080本地運行沒問題如果寫的是測試服務(wù)器地址必須改成后端實際地址。5.3 啟動驗證順序按照下面的順序操作基本不會出現(xiàn)“卡住看不懂”的情況。第一步用 Navicat 或命令行創(chuàng)建數(shù)據(jù)庫然后把項目提供的 SQL 文件導(dǎo)入。導(dǎo)入后點開 pet 表看一眼確認(rèn)有數(shù)據(jù)還是空表。第二步修改 application.yml 里的賬號密碼保證能連上剛才創(chuàng)建的庫。第三步如果 pom.xml 里有 Redis啟動本地 Redis 服務(wù)。第四步運行 Spring Boot 啟動類看到 “Started Application in x seconds” 才說明后端起來了。第五步啟動前端執(zhí)行 npm install 和 npm run serve瀏覽器打開頁面。第六步隨便注冊一個賬號走一遍發(fā)布寵物到申請領(lǐng)養(yǎng)的流程確認(rèn)狀態(tài)流轉(zhuǎn)正常。這一步不要省。很多項目表面能啟動但實際業(yè)務(wù)鏈路是斷的早期發(fā)現(xiàn)總比寫代碼寫到一半再排查強。6. 常見問題排查與避坑實錄這部分是我覺得最值錢的內(nèi)容。項目運行不起來、頁面數(shù)據(jù)不對90% 的原因就集中在下面這些點。6.1 高頻報錯速查表現(xiàn)象可能原因處理方法Application 啟動時報數(shù)據(jù)源錯誤數(shù)據(jù)庫沒建、賬號密碼錯、URL 寫錯先確認(rèn)數(shù)據(jù)庫連接是否能 ping 通再檢查 yml 配置訪問頁面白屏 404前端接口地址寫錯、后端 context-path 不一致查看瀏覽器 Network確認(rèn)請求有沒有發(fā)到后端圖片上傳后訪問 404沒有配置靜態(tài)資源映射或 uploadDir 路徑不對檢查addResourceHandlers是否生效接口報 401 或 403token 沒傳、token 過期、角色權(quán)限不足查看請求 Header 是否有 AuthorizationInvalid bound statementMapper 接口和 XML 文件沒對應(yīng)上檢查mapper-locations和 namespace時間字段返回數(shù)字?jǐn)?shù)組LocalDateTime 序列化問題配置 Jackson JavaTimeModule 和日期格式Redis連接失敗Redis 服務(wù)未啟動或地址配置錯誤啟動 Redis確認(rèn)端口中文亂碼數(shù)據(jù)庫字符集不是 utf8mb4重新建庫時指定 utf8mb46.2 一套通用的排查思路遇到問題不要只盯著瀏覽器報錯我自己通常按這三步走。第一步看控制臺日志。后端啟動失敗時先看第一個異常類型而不是最后一行看不懂的 Caused by 開端。日志最前面的異常類名幾乎能直接指向問題方向比如ClassNotFoundException就是缺依賴CannotCreateTransactionException就是數(shù)據(jù)庫連接出問題。第二步確認(rèn)基礎(chǔ)環(huán)境。數(shù)據(jù)庫能不能連上、端口有沒有被占用、前端代理有沒有配置這些問題用最快的手動操作驗證一遍比花半小時看代碼更有效。第三步還原操作路徑。把出問題的接口調(diào)用鏈走一遍看是前端沒發(fā)請求還是后端收到了但返回異常還是數(shù)據(jù)庫里數(shù)據(jù)狀態(tài)不對。前端 Network 面板、后端日志、數(shù)據(jù)庫三個對照著看很快就能定位。6.3 幾個項目里容易忽略的細(xì)節(jié)事務(wù)異常被吞掉是最隱蔽的坑。Service 方法加了Transactional里面卻自己 try-catch 了異常代碼看起來不報錯但數(shù)據(jù)寫到一半就斷了最難受。事務(wù)方法里的異常一定要往上拋交給全局異常處理器處理。文件上傳路徑不要用相對路徑。相對路徑在 IDE 里跑和打成 jar 跑工作目錄不一樣圖片一會兒有、一會兒沒有。建議代碼里用配置屬性動態(tài)指定絕對路徑或者臨時用System.getProperty(user.dir)拼一個項目運行目錄。領(lǐng)養(yǎng)申請并發(fā)的問題建議盡早考慮。同一只寵物如果被兩個人同時提交申請并且管理員同時審核可能出現(xiàn)兩個審核操作都把寵物狀態(tài)改成 2 的臟讀。嚴(yán)謹(jǐn)一點的做法是在審核方法里用樂觀鎖比如在 pet 表加 version 字段更新時校驗版本號或者最簡單地在審核前用select ... for update鎖住寵物記錄。7. 二次開發(fā)擴展讓系統(tǒng)從“能跑”變成“好用”能把一套現(xiàn)成的寵物領(lǐng)養(yǎng)救助平臺跑起來只能算完成了第一步。真正拉開差距的是你在這個基礎(chǔ)上加了什么、改了什么。7.1 建議優(yōu)先加的功能如果要在這個項目上做二次開發(fā)我強烈建議先加寵物健康檔案。寵物領(lǐng)養(yǎng)不是商品交易領(lǐng)養(yǎng)人很關(guān)心寵物疫苗、驅(qū)蟲、絕育情況。新建一張 pet_health_record 表關(guān)聯(lián) pet_id記錄疫苗名稱、接種時間、下次接種日期頁面放在寵物詳情里會讓系統(tǒng)完整度立刻上一個檔次。第二個建議加領(lǐng)養(yǎng)回訪。很多救助站會要求領(lǐng)養(yǎng)人定期反饋寵物近況用一個回訪任務(wù)表加上定時任務(wù)到時間自動生成回訪工單管理員跟進(jìn)后記錄結(jié)果。這個功能很貼合實際業(yè)務(wù)也是面試時能拿出來講的亮點。第三個建議加在線協(xié)商功能。用戶在提交申請前常想和救助站溝通一下寵物性格、領(lǐng)養(yǎng)條件用 WebSocket 做一個簡單聊天室比反復(fù)刷新列表和打電話體驗好得多。7.2 代碼層可以做的優(yōu)化業(yè)務(wù)之外代碼層有幾個值得優(yōu)化的點。列表接口可以把寵物信息和圖片分離減少大字段查詢熱點數(shù)據(jù)用 Redis 做緩存比如首頁推薦寵物列表一分鐘更新一次就夠了接口返回值不要直接返回數(shù)據(jù)庫實體因為實體里的密碼、手機號等敏感字段可能被前端看到建議補一層 DTO。數(shù)據(jù)庫這塊可以把救助記錄的類型、寵物品種這些重復(fù)性高的字段改成字典表減少維護(hù)成本。接口層可以補充參數(shù)校驗注解比如手機號格式、申請理由長度避免前端繞過頁面直接調(diào)接口。7.3 關(guān)于學(xué)習(xí)這類項目的一點個人體會我拿到一套新項目習(xí)慣是“倒著學(xué)”。先看 SQL 文件里的表結(jié)構(gòu)把狀態(tài)字段和關(guān)聯(lián)字段畫出來再打開講解視頻按模塊跳著看重點看領(lǐng)養(yǎng)審核、文件上傳、權(quán)限攔截這幾個核心環(huán)節(jié)最后自己動手改一個小需求比如給寵物表加一個“是否已絕育”字段從前端表單到后端接口到數(shù)據(jù)庫全鏈路改一遍。這樣做的好處是你不是被動地把代碼看了一遍而是真正理解了每個模塊的來龍去脈。后面再遇到類似的項目哪怕表名不同核心邏輯也都能一眼看穿。這套寵物領(lǐng)養(yǎng)救助平臺系統(tǒng)價值不只是“能跑”。你看懂了狀態(tài)流轉(zhuǎn)、事務(wù)控制、文件上傳、權(quán)限攔截這幾個關(guān)鍵點再去做任何后臺管理系統(tǒng)都會順手很多。最后提醒一句拿到配套的文檔和講解視頻后先定位目錄再動手改代碼這個順序能幫你省下大把試錯時間。