滿幫全棧（後端）一面面經流傳：26題橫跨秒殺庫存、RAG攔截到MySQL索引，留言聚焦「怎麼問八股」

牛客網近日流傳一篇標題為「滿幫全棧一面（後端）」的面經帖，原發者自述面試發生於10月15日下午，全程以問答形式記錄了26道題目，並附帶「#發面經攢人品#」「#秋招面試記錄#」等標籤。帖子發布後引來數則留言，討論集中在題量與考題型態。

面試整體輪廓

原發者對面試過程的評價偏向正面，稱「面試感受還挺好的，面試官感覺非常專業，語氣也很好」。考題以問答為主，最後一道為手撕題，原發者註明「只讓說做題思路」，題目是LeetCode第74題「搜尋二維矩陣」，未要求現場寫出程式碼。

題目序列的前半段圍繞專案經歷展開。面試官首先確認專案是自行程開發或實習產出，接著追問技術選型細節，包括為何在秒殺場景以Lua腳本判斷庫存增減而非直接使用Redisson、Redis在Java體系下的分散式鎖機制，以及商品資訊與庫存預熱時的注意事項。

快取與資料一致性考題密集

快取主題在本篇面經中佔比明顯。面試官依序問及客戶端快取與Redis快取的選型差異、本地快取無法覆蓋的場景、扣減庫存後的持久化同步與兜底機制、資料庫讀寫分離情境下的快取同步方案、延遲雙刪的實作方式，以及「先更新資料庫再刪快取」仍可能讀到髒資料時的補救措施。

這類考點與本臺先前整理的9月20日得物後端一面面經高度重疊，該場同樣從Redis高可用問到AI幻覺處理，顯示快取一致性與訊息佇列選型已是後端一面的常見題組。本篇第25題也問及Redis Stream與RocketMQ、RabbitMQ等專業訊息佇列的差異，以及當初選型未採用後者的原因。

RAG與知識庫追問鏈

不同於純後端考題，這場面試花了相當篇幅追問知識庫搭建。面試官問及知識單元的拆分思路，並針對原發者使用的「1000字元、200重疊」切分參數追問數字如何定義、改為500重疊是否可行。

場景題部分設在物流情境：若用戶要求直接退款，如何保證模型不會自主回覆「好的，我幫你退款」，以及如何處理與知識庫文件無關的用戶問題、在哪個環節攔截。後續還問到對話摘要的實作方式、若由大模型執行摘要，用戶端等待thinking過程過長的體驗權衡。此類RAG追問鏈亦見於本臺整理過的快手AI應用開發與Agent開發一面面經，兩者題組結構相近。

資料庫與JVM題組

資料庫考題從select count(*)、count(1)與count(2)的區別及日常建議用法，問到MySQL常用函式、索引失效場景。針對原發者專案中的優惠券表，面試官追問若需查詢某用戶近N天的優惠券該建什麼索引，以及user_id與create_time欄位順序對調會產生什麼問題，並進一步問A、B、C三欄位複合索引實際上等同於建了幾個索引。

JVM與並發部分僅兩題：系統頻繁Full GC時的排查方向與方法，以及ConcurrentHashMap解決的問題與其鎖機制。

留言區討論樣態

截至帖內可見留言，討論有三個方向。一則來自福建、發布於10月16日的留言寫道「我去，你面試官怎麼問八股啊」，質疑考題偏重教條式背誦；一則來自陝西的留言表示「問的問題挺多的啊，看著都有壓力」；另有一則來自福建的留言詢問「有後續了嗎」，原發者未在帖內回覆後續進度。

原發者未說明面試結果，帖內亦無二面或offer相關資訊。面經中記載的題目數量為26題，全部以問答與思路口述構成，與同週期流傳的其他大廠一面面經相比，本篇的特色在於後端基礎題與RAG應用題各佔約半，且未出現要求現場撰寫程式碼的手撕環節。