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