做 Java 旅游推薦類項(xiàng)目的時候幾乎所有人都會遇到同一個場景景點(diǎn)庫里躺著幾千條數(shù)據(jù)用戶打開首頁卻不知道選哪個。個性化旅游景點(diǎn)推薦網(wǎng)站要解決的就是這種“選擇焦慮”。這類 Java 實(shí)戰(zhàn)項(xiàng)目最近特別常見核心其實(shí)就是用 SpringBoot 搭一個服務(wù)端平臺把景點(diǎn)展示、用戶偏好分析、個性化推薦、行程規(guī)劃、門票預(yù)訂這些環(huán)節(jié)串成一條完整的業(yè)務(wù)鏈路。它不只是一個簡單的 CRUD 后臺真正的價值在于“怎么根據(jù)用戶行為把合適的景點(diǎn)放在合適的推薦位”。這篇文章我會從需求拆解開始把表結(jié)構(gòu)、推薦打分邏輯、SpringBoot 核心接口、預(yù)訂并發(fā)控制都講一遍最后再分享一批我在實(shí)際項(xiàng)目里踩過的坑。如果你正在做 Java 方向的項(xiàng)目想接觸 SpringBoot 綜合開發(fā)或者對旅游推薦這類業(yè)務(wù)場景感興趣下面這些內(nèi)容基本可以拿來當(dāng)參考。1. 項(xiàng)目概述與需求拆解一臺“懂用戶”的旅游服務(wù)平臺要做什么1.1 個性化旅游推薦的業(yè)務(wù)痛點(diǎn)傳統(tǒng)旅游平臺的首頁通常是一個“熱門景點(diǎn)排行榜”加上搜索框。熱門榜看著省事但有個致命的問題它是給所有人看的不是給“當(dāng)前這個用戶”看的。一個經(jīng)常帶娃出門的用戶和一個喜歡打卡拍照的用戶理想中的推薦列表應(yīng)該是完全不同的。如果系統(tǒng)只按銷量排序親子用戶大概率會反復(fù)看到酒吧街、極限運(yùn)動這類不匹配的內(nèi)容點(diǎn)了幾次沒興趣用戶就走了。個性化推薦網(wǎng)站要解決的問題就是把“景點(diǎn)的屬性”和“用戶的偏好”做一個動態(tài)匹配。落到業(yè)務(wù)上系統(tǒng)需要做三件事第一記錄用戶點(diǎn)擊、收藏、下單等行為第二給每個景點(diǎn)打上可計(jì)算的標(biāo)簽第三用一套打分規(guī)則把行為數(shù)據(jù)和標(biāo)簽數(shù)據(jù)換算成一個推薦分最后按分?jǐn)?shù)排序展示。這三個環(huán)節(jié)缺一個推薦就只是“偽個性化”本質(zhì)上還是熱門排序。這個項(xiàng)目里我經(jīng)常把業(yè)務(wù)模塊拆成四個部分用戶端負(fù)責(zé)瀏覽和預(yù)訂推薦引擎負(fù)責(zé)生成候選列表行程規(guī)劃負(fù)責(zé)把景點(diǎn)排進(jìn)具體某一天管理后臺負(fù)責(zé)維護(hù)景點(diǎn)與標(biāo)簽。四個部分之間通過 SpringBoot 的 Restful 接口通信數(shù)據(jù)統(tǒng)一走 MySQL熱點(diǎn)數(shù)據(jù)走 Redis。整體邏輯不復(fù)雜但每個部分都有不少細(xì)節(jié)。1.2 為什么技術(shù)選型鎖定SpringBoot很多 Java 項(xiàng)目的老底子是 SSM也就是 Spring SpringMVC MyBatis。SSM 不是不能做但每次新建項(xiàng)目都要配一大堆 XML數(shù)據(jù)源、事務(wù)管理器、視圖解析器、過濾器每一樣都得手工聲明。SpringBoot 把這些東西大部分收斂成了“自動配置”一個 spring-boot-starter-web 依賴?yán)M(jìn)來寫一個 main 方法就能啟動 Web 服務(wù)。對旅游推薦這種業(yè)務(wù)鏈路比較長的項(xiàng)目開發(fā)效率會差很多。另外SpringBoot 的生態(tài)對中小型系統(tǒng)特別友好。拿數(shù)據(jù)持久層來說可以選 Spring Data JPA也可以選 MyBatis-Plus兩者都能在 SpringBoot 里通過 starter 快速集成推薦結(jié)果要緩存直接 spring-boot-starter-data-redis接口要做登錄校驗(yàn)可以用 Spring Security 或者寫一個簡單的 HandlerInterceptor。這種“要什么加什么”的方式非常貼合業(yè)務(wù)迭代節(jié)奏。從學(xué)習(xí)角度講SpringBoot 也是 Java 崗位面試?yán)锢@不開的關(guān)鍵詞。做這個項(xiàng)目時我建議不要停留在“能啟動、能寫接口”的層面而是把自動配置原理、Bean 生命周期、事務(wù)傳播機(jī)制這些底層問題一并搞明白。項(xiàng)目本身是業(yè)務(wù)載體真正沉淀下來的是你對 SpringBoot 運(yùn)行時機(jī)制的理解。1.3 功能模塊規(guī)劃先畫清楚邊界動手寫代碼之前先花半小時把功能模塊拆出來比直接建表重要得多。我的習(xí)慣是畫一張模塊清單區(qū)分“用戶端”和“管理端”再區(qū)分“核心流程”和“支撐流程”。用戶端核心流程有四個用戶注冊登錄手機(jī)號或郵箱 密碼登錄后簽發(fā) Token。景點(diǎn)瀏覽與搜索支持按城市、類型、關(guān)鍵詞篩選。個性化推薦首頁推薦、相似景點(diǎn)推薦、猜你喜歡。行程規(guī)劃與預(yù)訂選擇日期和城市系統(tǒng)生成行程并對行程中的景點(diǎn)門票下單。管理端核心流程相對簡單主要是景點(diǎn)信息維護(hù)、標(biāo)簽管理、訂單管理、用戶行為查詢。支撐流程包括 Redis 緩存、定時任務(wù)清理失效數(shù)據(jù)、統(tǒng)一異常處理、接口參數(shù)校驗(yàn)。邊界清楚了后面建表、寫接口、做分頁都會有方向。很多項(xiàng)目做到一半改來改去就是因?yàn)橐婚_始沒想清楚“推薦”和“搜索”到底是不是一回事。在這個系統(tǒng)里搜索是用戶主動表達(dá)需求推薦是系統(tǒng)猜測用戶需求前者用 SQL 過濾后者用打分排序兩者不能混在一個邏輯里。2. 系統(tǒng)架構(gòu)與核心數(shù)據(jù)模型設(shè)計(jì)2.1 分層架構(gòu)從Controller到Mapper的職責(zé)劃分SpringBoot 項(xiàng)目最常用的分層方式是 Controller、Service、Mapper、Entity、DTO。很多新手喜歡把業(yè)務(wù)邏輯寫在 Controller 里接口一多就亂套。這個項(xiàng)目我推薦按下面這種結(jié)構(gòu)組織controller只接收請求參數(shù)調(diào)用 Service把 DTO 轉(zhuǎn)成 JSON 返回。service處理業(yè)務(wù)邏輯推薦算法、行程規(guī)劃、下單事務(wù)都放在這一層。mapper操作數(shù)據(jù)庫一個方法對應(yīng)一條 SQL 或一個 MyBatis 映射。entity數(shù)據(jù)庫表的映射實(shí)體字段和表結(jié)構(gòu)保持一致。dto接口傳輸對象按前端需要裁剪字段避免把實(shí)體直接暴露出去。實(shí)體和 DTO 為什么要分開最典型的場景是推薦接口。景點(diǎn)實(shí)體里有創(chuàng)建時間、管理員 ID、上下架狀態(tài)前端根本不需要。如果你直接把實(shí)體序列化返回不僅多傳了一堆無用字段還可能因?yàn)閷?shí)體里的懶加載關(guān)聯(lián)對象觸發(fā)序列化異常。這個坑我后面會詳細(xì)說。2.2 數(shù)據(jù)庫表設(shè)計(jì)推薦系統(tǒng)能不能跑靠的是這5張表旅游推薦系統(tǒng)的表結(jié)構(gòu)并不復(fù)雜但設(shè)計(jì)時一定要圍繞“標(biāo)簽”和“行為”這兩個核心來建。我把最常用的幾張表列出來表名作用核心字段user用戶基本信息id, nickname, phone, password, register_timescenic景點(diǎn)信息id, name, city, address, cover_url, description, score, stocktag標(biāo)簽字典id, tag_name, tag_typescenic_tag景點(diǎn)與標(biāo)簽關(guān)聯(lián)id, scenic_id, tag_iduser_behavior用戶行為記錄id, user_id, scenic_id, behavior_type, create_time其中scenic_tag是典型的多對多關(guān)聯(lián)表用來打破景點(diǎn)與標(biāo)簽之間的“多對多”關(guān)系。user_behavior是整個推薦系統(tǒng)的數(shù)據(jù)基礎(chǔ)每一次點(diǎn)擊、收藏、下單都會往這張表里寫一條記錄。如果項(xiàng)目需要做更復(fù)雜的偏好分析也可以加上user_tag_pref表專門存儲用戶對某個標(biāo)簽的累計(jì)偏好分避免每次推薦都實(shí)時掃描行為表。在字段設(shè)計(jì)上有幾個細(xì)節(jié)值得強(qiáng)調(diào)。第一scenic.stock必須設(shè)為非負(fù)并在 SQL 里加約束這是后面做庫存扣減的基礎(chǔ)。第二行為類型的字段不要用字符串亂寫最好用數(shù)字枚舉比如 1 瀏覽、2 收藏、3 下單。第三所有關(guān)聯(lián)字段都要建索引尤其是user_behavior.user_id和scenic_tag.tag_id不然推薦接口一上線就是慢查詢。2.3 用戶行為與景點(diǎn)標(biāo)簽推薦系統(tǒng)的“原料倉”推薦系統(tǒng)能不能給出可信的結(jié)果取決于“原料”干不干凈。這里的原料就是用戶行為和景點(diǎn)標(biāo)簽。景點(diǎn)標(biāo)簽要盡量可控不要任由管理員隨便亂填。我習(xí)慣在管理后臺限制標(biāo)簽必須從字典里選擇并且規(guī)定一個景點(diǎn)最多打 5 個標(biāo)簽。太少了信息量不足太多了會讓相似度計(jì)算失去區(qū)分度。用戶行為的記錄要選對埋點(diǎn)位置。比如瀏覽行為應(yīng)該記錄在景點(diǎn)詳情頁的打開動作上而不是列表頁的曝光。因?yàn)榱斜眄摽赡芤豢跉庹故玖?20 個景點(diǎn)用戶只是掃了一眼并不能說明他對這些都感興趣。收藏和下單行為更接近真實(shí)意圖權(quán)重應(yīng)該更高。行為數(shù)據(jù)會有很多噪音。比如用戶誤點(diǎn)了詳情頁剛進(jìn)去就退出來這條瀏覽記錄如果參與打分會把推薦帶偏。我后來加了個簡單過濾瀏覽詳情頁超過 10 秒才算有效行為。雖然不太精確但成本很低效果提升很明顯。3. 個性化推薦機(jī)制的實(shí)現(xiàn)思路3.1 行為采集與權(quán)重定義推薦引擎的第一步是把原始行為轉(zhuǎn)換成可計(jì)算的數(shù)值。我用的權(quán)重方案很簡單有效瀏覽1 分收藏2 分加入行程3 分下單購買5 分為什么要這樣設(shè)因?yàn)椴煌袨榇淼男睦頍岫韧耆煌?。用戶可能隨便瀏覽十個景點(diǎn)但只會收藏兩三個真正愿意下單的更少。如果一個景點(diǎn)能觸發(fā)用戶下單說明它和用戶偏好的匹配度遠(yuǎn)高于“被劃到了一眼”。這里沒有標(biāo)準(zhǔn)答案你可以根據(jù)自己的業(yè)務(wù)場景調(diào)整但切記要保持“下單大于收藏、收藏大于瀏覽”的直覺邏輯。行為記錄不需要實(shí)時寫入推薦分。我一般是先寫user_behavior表然后通過一個定時任務(wù)或者延遲隊(duì)列每隔幾分鐘把新增行為批量折算進(jìn)用戶偏好緩存里。如果每次請求推薦接口都實(shí)時算原始行為數(shù)據(jù)庫壓力會非常大。3.2 基于偏好標(biāo)簽的用戶畫像打分用戶畫像打分的過程其實(shí)就是“把用戶歷史行為映射到景點(diǎn)標(biāo)簽再做加權(quán)求和”。我舉一個具體的計(jì)算例子。假設(shè)用戶最近有 4 條行為記錄瀏覽了景點(diǎn) AA 的標(biāo)簽是“親子”、“公園”行為權(quán)重 1。收藏了景點(diǎn) BB 的標(biāo)簽是“親子”、“動物園”行為權(quán)重 2。瀏覽了景點(diǎn) CC 的標(biāo)簽是“歷史”、“博物館”行為權(quán)重 1。下單了景點(diǎn) DD 的標(biāo)簽是“歷史”、“古建筑”行為權(quán)重 5。那么用戶對“親子”標(biāo)簽的偏好分 1 2 3對“歷史”標(biāo)簽的偏好分 1 5 6對“公園”、“動物園”、“博物館”、“古建筑”這些標(biāo)簽也分別按行為權(quán)重累加。這樣得到的就是一個「標(biāo)簽 - 偏好分」的 Map。接下來給候選景點(diǎn)打分邏輯是景點(diǎn) E 的標(biāo)簽是“歷史”、“古建筑”景點(diǎn) E 的推薦分 6 6 12。景點(diǎn) F 的標(biāo)簽是“親子”、“動物園”推薦分 3 2 5。最后按分?jǐn)?shù)排序歷史類景點(diǎn)排在前面。真實(shí)現(xiàn)實(shí)中還要對偏好分做歸一化比如把最高分壓到 1.0避免某個行為特別高頻的用戶把所有推薦結(jié)果都鎖死在同一個標(biāo)簽上。歸一化公式不復(fù)雜finalScore score / maxScore。如果你看到推薦結(jié)果里全是同類景點(diǎn)多半是漏了這一步。3.3 基于景點(diǎn)的物品相似度推薦除了按用戶偏好打分我還喜歡加一路“基于物品相似度”的候選來源。原理是用戶喜歡景點(diǎn) X系統(tǒng)就去計(jì)算哪個景點(diǎn)和 X 的標(biāo)簽最像然后把相似景點(diǎn)也推薦給用戶。這在推薦算法里叫 Item-based Collaborative Filtering。計(jì)算相似度最簡單的方式是余弦相似度。每個景點(diǎn)可以表示成一個標(biāo)簽向量比如景點(diǎn) X 的向量是[親子:1, 公園:1, 攝影:1]景點(diǎn) Y 的向量是[親子:1, 公園:1, 徒步:1]兩者重合的標(biāo)簽越多、向量夾角越小相似度越高。如果直接用 SQL 算太復(fù)雜可以做成內(nèi)存計(jì)算每次景點(diǎn)標(biāo)簽變更時預(yù)計(jì)算好一份“相似景點(diǎn) Top 10”列表存到 Redis 里用戶請求時直接取。為什么不用更復(fù)雜的 User-based 協(xié)同過濾因?yàn)檫@個項(xiàng)目的用戶規(guī)模沒有那么理想“用戶 A 和用戶 B 相似所以把 B 看過的推薦給 A”這種邏輯在冷啟動階段很難生效而且實(shí)時計(jì)算用戶間相似矩陣的成本很高?；谖锲废嗨贫雀€(wěn)解釋起來也更直觀。3.4 冷啟動與推薦結(jié)果兜底新用戶沒有歷史行為新景點(diǎn)沒有用戶反饋這就是推薦系統(tǒng)里的冷啟動問題。我的處理策略分三層新用戶注冊時讓用戶主動勾選興趣標(biāo)簽比如親子、歷史、美食、徒步。這個動作能直接生成初始畫像跳過“攢行為”的過程。用戶沒有做任何選擇時推薦全局熱門景點(diǎn)。熱門不是單純按瀏覽量排序而是按“瀏覽 收藏 下單”加權(quán)后的熱度排序避免大量無效點(diǎn)擊上榜。新景點(diǎn)上線后如果沒有任何行為數(shù)據(jù)先按標(biāo)簽匹配進(jìn)推薦流同時給一個基礎(chǔ)加權(quán)分讓運(yùn)營可以手動“置頂推廣”。兜底策略還要考慮一個細(xì)節(jié)用戶已經(jīng)下單或者明確不感興趣的景點(diǎn)不應(yīng)該再出現(xiàn)在推薦列表里。我每次推薦查詢都會帶上一個EXCLUDE_SCENIC_IDS參數(shù)從用戶已購記錄里取出來在 SQL 或內(nèi)存里直接過濾掉。有些系統(tǒng)不做這步用戶剛買完東西首頁還在推同一個景點(diǎn)體驗(yàn)非常差。4. 基于SpringBoot的核心接口與業(yè)務(wù)實(shí)現(xiàn)4.1 推薦接口的設(shè)計(jì)與落地推薦接口我習(xí)慣設(shè)計(jì)成 GET 請求返回一個帶推薦理由的列表。請求參數(shù)包括用戶 ID、城市、條數(shù)上限比如GET /api/recommend/scenic?userId1city杭州limit10響應(yīng)結(jié)構(gòu)大致是這樣的{ code: 0, data: [ { scenicId: 101, name: 西湖, score: 98.5, reason: 近30天你有3次歷史類景點(diǎn)瀏覽記錄 } ], total: 10 }推薦理由這個東西很容易被忽略但對用戶體驗(yàn)影響很大。用戶看到一個“為什么推薦給我”的說明會覺得系統(tǒng)是懂自己的而不是一個冰冷算法扔出來的結(jié)果。實(shí)現(xiàn)時我是在推薦打分過程中把“命中的標(biāo)簽”保留下來然后根據(jù)權(quán)重最高的標(biāo)簽生成一句模板文案。核心 Service 的邏輯可以這樣理解public ListScenicRecommendVO recommend(Long userId, String city, int limit) { MapString, Double tagPref buildUserTagPreference(userId); if (tagPref.isEmpty()) { return listHotScenic(city, limit); } ListScenic candidates scenicMapper.selectByCity(city); ListScenicRecommendVO result new ArrayList(); for (Scenic scenic : candidates) { double score calcRecommendScore(scenic, tagPref); ScenicRecommendVO vo ScenicRecommendVO.from(scenic); vo.setScore(score); vo.setReason(buildReason(scenic, tagPref)); result.add(vo); } result.sort((a, b) - Double.compare(b.getScore(), a.getScore())); return result.stream().limit(limit).collect(Collectors.toList()); }這里有一個在實(shí)際開發(fā)中很重要的點(diǎn)不要把整個推薦邏輯一股腦塞進(jìn) Controller 或 Mapper。上面的buildUserTagPreference、calcRecommendScore、buildReason都是獨(dú)立的私有方法方便單元測試。我后來把打分和理由生成拆成了獨(dú)立策略類接其他推薦算法時只需要替換實(shí)現(xiàn)。4.2 行程規(guī)劃把推薦結(jié)果排成一張能執(zhí)行的時間表推薦出景點(diǎn)之后用戶往往還有“幫我安排一下路線”的需求。行程規(guī)劃模塊的核心是把選中的多個景點(diǎn)分配到某一天盡量讓路線順路、時間不漏。我采用的方式是貪心排序先按景點(diǎn)經(jīng)緯度計(jì)算用戶指定出發(fā)點(diǎn)到各個景點(diǎn)的距離把距離近的排在前面再按“游玩時長 交通時長”累加單日總時長控制在 8 小時左右。比如上午 9 點(diǎn)出發(fā)景點(diǎn) 1 游玩 2 小時交通 0.5 小時下一個景點(diǎn) 11 點(diǎn)半開始中午預(yù)留吃飯時間下午接著排。如果當(dāng)天排不下就把剩余景點(diǎn)順延到第二天。SpringBoot 實(shí)現(xiàn)時行程單itinerary和行程明細(xì)itinerary_item是一對多關(guān)系。生成行程是一個事務(wù)性操作先插入主單再插入多個明細(xì)。如果某個景點(diǎn)已經(jīng)下架或者庫存不足整個生成事務(wù)回滾。我遇到過把Transactional加在私有方法上導(dǎo)致事務(wù)失效的情況所以這里要提醒一下Spring 的事務(wù)代理是基于接口或類代理的自調(diào)用不生效。事務(wù)注解要加在 public 方法上并且通過注入的 Service Bean 調(diào)用。4.3 門票預(yù)訂與庫存并發(fā)控制預(yù)訂功能最考驗(yàn)細(xì)節(jié)。用戶選好景點(diǎn)后要給該景點(diǎn)對應(yīng)的門票庫存扣減一條。表設(shè)計(jì)時我在scenic表里直接維護(hù)了一個stock字段。扣減時絕對不能先查庫存再在 Java 代碼里判斷因?yàn)椴l(fā)請求下兩個線程可能同時讀到相同的庫存數(shù)然后一起執(zhí)行減一導(dǎo)致超賣。一個簡單的正確做法是使用數(shù)據(jù)庫的條件更新UPDATE scenic SET stock stock - 1 WHERE id ? AND stock 0;如果后端收到的影響行數(shù)是 1說明扣減成功影響行數(shù)是 0說明庫存已經(jīng)為 0要返回“已售罄”的提示。這個方案在并發(fā)量不是特別高的時候完全夠用。如果預(yù)期并發(fā)很大可以把庫存先放到 Redis 里用 Lua 腳本保證“判斷庫存 扣減庫存”原子執(zhí)行。下單成功后再把訂單寫入 MySQL通過異步消息或者定時任務(wù)做最終一致性。這個項(xiàng)目里我出于簡單考慮用了數(shù)據(jù)庫條件更新加 Redis 預(yù)扣減的組合邏輯簡單也足夠穩(wěn)定。4.4 后臺管理與接口鑒權(quán)推薦系統(tǒng)不只是給用戶看前端頁面的管理員還需要維護(hù)景點(diǎn)、標(biāo)簽和訂單。后臺接口和用戶端接口要隔離最直接的做法是分別放在/admin/**和/api/**路徑下再用攔截器做權(quán)限控制。我用 SpringBoot 的HandlerInterceptor實(shí)現(xiàn)了 Token 校驗(yàn)。用戶登錄成功后服務(wù)端生成一個 UUID 作為 Token存到 Redis 里并設(shè)置過期時間。前端每次請求帶上Authorization頭攔截器里查一下 Redis 是否存在這個 Token。管理端則額外校驗(yàn)用戶角色只有ADMIN角色能訪問/admin/**。這個方案比直接用 Spring Security 簡單也更容易理解。要注意的是Token 過期時間不要太長我通常設(shè)置成 7 天。管理后臺操作要記錄操作日志至少包括操作人、操作時間、操作內(nèi)容。這些日志在排查推薦位數(shù)據(jù)異常時特別有用。5. 實(shí)操過程與高頻問題排查5.1 從零搭建SpringBoot項(xiàng)目環(huán)境準(zhǔn)備上我用的是 JDK 17、Maven 3.8、MySQL 8.0、Redis 6.2。創(chuàng)建 SpringBoot 項(xiàng)目時官方推薦的 Spring Initializr 已經(jīng)很好用了。核心依賴只有這幾個spring-boot-starter-web提供 Web 能力與內(nèi)嵌 Tomcat。spring-boot-starter-validation做參數(shù)校驗(yàn)。mybatis-plus-spring-boot3-starter數(shù)據(jù)持久層。spring-boot-starter-data-redis緩存與 Token 存儲。mysql-connector-jMySQL 驅(qū)動。依賴版本最好選一個穩(wěn)定的正式版不要一味追求最新。最近很多項(xiàng)目啟動報錯都是因?yàn)榘?SpringBoot 升級到了太高版本導(dǎo)致第三方的 starter 還沒有適配啟動時要么 ClassNotFoundException要么 Bean 循環(huán)依賴。做項(xiàng)目講究“能跑優(yōu)先”等業(yè)務(wù)穩(wěn)定后再考慮升級。5.2 經(jīng)典報錯JPA懶加載導(dǎo)致JSON序列化失敗如果你用 Spring Data JPA 而不是 MyBatis會經(jīng)常遇到LazyInitializationException。原因是實(shí)體里的關(guān)聯(lián)關(guān)系設(shè)置成fetch FetchType.LAZY后在事務(wù)結(jié)束、Session 關(guān)閉的情況下Jackson 序列化時還會嘗試加載關(guān)聯(lián)對象結(jié)果底層連接已經(jīng)不可用。這個報錯我見的太多了。解決方案有三種在實(shí)體關(guān)聯(lián)字段上加JsonIgnore讓序列化忽略關(guān)聯(lián)對象。使用 DTO 對象不直接返回實(shí)體。查詢時用EntityGraph把需要關(guān)聯(lián)的字段一次性查出來。我個人最推薦第二種DTO。它不僅能解決懶加載問題還能避免把敏感字段比如用戶密碼一起返回前端。如果你用的是 MyBatis 或者 MyBatis-Plus可以配置合理的 resultMap 或者用擴(kuò)展類思路是一樣的。5.3 推薦結(jié)果不準(zhǔn)、重復(fù)怎么辦推薦結(jié)果不準(zhǔn)先不要急著換算法八成是數(shù)據(jù)問題。我排查的順序是用戶行為是否成功寫入很多“不準(zhǔn)”其實(shí)是行為記錄丟失導(dǎo)致畫像為空。標(biāo)簽是否合理如果 A 景點(diǎn)同時打上“親子”和“夜店”畫像自然混亂。權(quán)重是否生效可以打印出用戶標(biāo)簽偏好 Map看看歷史分?jǐn)?shù)是否和自己手工算的一致。是否有緩存如果 Redis 里緩存了舊推薦結(jié)果新行為可能需要一段時間才生效。推薦結(jié)果重復(fù)的問題多半是沒有做聯(lián)合去重。我的做法是最終推薦列表先放“用戶偏好推薦”再去掉用戶已經(jīng)下單、收藏過的景點(diǎn)最后再按分?jǐn)?shù)排序。如果還有重復(fù)檢查是不是同一個景點(diǎn)的多個門票規(guī)格被當(dāng)成了多條記錄。5.4 性能優(yōu)化接口從800ms降到120ms的小改動推薦接口早期上線時響應(yīng)時間經(jīng)常超過 800ms。為了低于 300ms我做了一次性能優(yōu)化。先定位瓶頸發(fā)現(xiàn)每次推薦都要查用戶行為表、查候選景點(diǎn)、再查每個景點(diǎn)的標(biāo)簽SQL 執(zhí)行了幾十條是典型的 N1 問題。優(yōu)化方式是三層第一層用戶行為查詢改成只查最近 30 天數(shù)據(jù)避免掃描歷史全表。第二層景點(diǎn)標(biāo)簽批量查出后放到內(nèi)存 Map不再循環(huán)查單條。第三層推薦結(jié)果按城市和用戶標(biāo)簽維度緩存到 Redis有效期 5 分鐘。用戶請求時直接命中緩存只有緩存過期才重新計(jì)算。改完之后接口平均耗時降到 120ms 左右。這里想強(qiáng)調(diào)的是性能優(yōu)化不是炫技而是先把 SQL 和對象模型調(diào)順再引入緩存。很多項(xiàng)目一上來就加 Redis結(jié)果緩存穿透、雪崩問題一大堆得不償失。6. 常見問題速查表與我的經(jīng)驗(yàn)總結(jié)6.1 高頻問題速查表問題常見原因解決方式推薦接口返回很慢循環(huán)查數(shù)據(jù)庫導(dǎo)致 N1批量查詢減少循環(huán)數(shù)據(jù)庫訪問用戶看到重復(fù)景點(diǎn)已購景點(diǎn)未過濾推薦查詢前排除已購和已收藏 ID收藏功能一直報 500懶加載序列化異常返回 DTO不返回實(shí)體下單庫存超賣先查庫存再扣減使用UPDATE ... WHERE stock 0條件更新中文亂碼數(shù)據(jù)庫連接未指定 UTF-8在 JDBC URL 加characterEncodingutf8新用戶沒有推薦內(nèi)容冷啟動策略缺失注冊時選擇興趣標(biāo)簽或返回?zé)衢T榜Token 校驗(yàn)失效Redis 過期策略配置問題設(shè)置合理的過期時間并刷新 Token行程生成一半失敗事務(wù)邊界設(shè)置錯誤確保事務(wù)注解在 public Service 方法上6.2 項(xiàng)目落地時容易被忽略的5個細(xì)節(jié)第一個細(xì)節(jié)是接口參數(shù)校驗(yàn)。推薦接口的limit如果傳 10000你的排序和內(nèi)存計(jì)算都可能被打滿。我會用Min、Max注解限制參數(shù)范圍同時在 Service 里做二次防御。第二個細(xì)節(jié)是日志。推薦算法是“黑盒”如果沒有日志出了問題基本無從查起。我習(xí)慣在關(guān)鍵節(jié)點(diǎn)打印結(jié)構(gòu)化日志比如用戶 ID、候選景點(diǎn)數(shù)量、最終推薦列表前 5 個 ID。這樣用戶反饋“推薦不準(zhǔn)”時可以直接追到當(dāng)時的輸入輸出。第三個細(xì)節(jié)是數(shù)據(jù)庫索引。user_behavior表我只建了兩個索引一個是user_id create_time一個是scenic_id。這個字段組合能覆蓋 90% 的查詢場景不要給每個字段都建索引否則寫入性能會明顯下降。第四個細(xì)節(jié)是配置文件的環(huán)境隔離。開發(fā)環(huán)境、測試環(huán)境、生產(chǎn)環(huán)境的數(shù)據(jù)庫地址和 Redis 地址是不同的。用application-dev.yml、application-prod.yml分開管理啟動時通過spring.profiles.active指定能避免很多線上事故。第五個細(xì)節(jié)是統(tǒng)一異常處理。我用RestControllerAdvice做了一個全局異常處理器把參數(shù)異常、業(yè)務(wù)異常、系統(tǒng)異常分別歸類返回。前端只需要處理一個統(tǒng)一結(jié)構(gòu)的錯誤 JSON不用每個接口寫 try-catch。6.3 做完這個項(xiàng)目之后我想說幾句實(shí)話這個項(xiàng)目讓我最深的體會是推薦系統(tǒng)不是越復(fù)雜越好。很多架構(gòu)文章會講 TensorFlow、向量數(shù)據(jù)庫但實(shí)際做業(yè)務(wù)系統(tǒng)時可能一張user_behavior表加一套標(biāo)簽打分規(guī)則就能解決大部分問題。與其盲目追新不如先把手里的行為數(shù)據(jù)和標(biāo)簽質(zhì)量打磨好。另一個體會是SpringBoot 項(xiàng)目能不能做得順很大程度上取決于數(shù)據(jù)模型。表結(jié)構(gòu)設(shè)計(jì)清楚關(guān)聯(lián)關(guān)系明朗后面寫接口就是一層層翻譯業(yè)務(wù)表結(jié)構(gòu)混亂每寫一個功能都像在補(bǔ)窟窿。如果你正在準(zhǔn)備類似的項(xiàng)目我建議把六成時間花在需求和表設(shè)計(jì)上寫代碼反而是最快的一部分。最后再分享一個小技巧推薦接口上線后一定要留一個“人工干預(yù)”的口子。運(yùn)營可以手動調(diào)整某個景點(diǎn)的基礎(chǔ)權(quán)重、置頂或者下線。再智能的系統(tǒng)也需要業(yè)務(wù)兜底這個口子看著不起眼但能幫你和運(yùn)營同學(xué)都省下大量溝通成本。做技術(shù)不是只會寫代碼能把業(yè)務(wù)順暢地跑起來才是真正有價值的事。