2. 復(fù)盤(pán)蒼穹外賣(mài)知識(shí)點(diǎn)第一期做后端開(kāi)發(fā)的幾乎沒(méi)人不知道蒼穹外賣(mài)這個(gè)實(shí)戰(zhàn)項(xiàng)目。我當(dāng)年刷完它之后最大的感受不是“我會(huì)寫(xiě)接口了”而是終于明白了“一個(gè)真實(shí)的外賣(mài)系統(tǒng)到底是怎么從零到一被拆出來(lái)、做出來(lái)、然后扛住線上壓力的”。最近有不少同學(xué)問(wèn)我這個(gè)項(xiàng)目值不值得刷、該怎么刷所以我打算出幾期復(fù)盤(pán)把里面那些“文檔里不會(huì)寫(xiě)透”的知識(shí)點(diǎn)掰開(kāi)了聊一聊。先說(shuō)結(jié)論這個(gè)項(xiàng)目最核心的四個(gè)關(guān)鍵字是管理端、用戶端、訂單流轉(zhuǎn)、支付對(duì)接。這四個(gè)點(diǎn)基本涵蓋了Java后端面試?yán)锇俜种耸母哳l考點(diǎn)從基礎(chǔ)的MVC分層、MyBatis-Plus操作到稍微進(jìn)階一點(diǎn)的Redis緩存、Spring Cache、WebSocket再到真正能拉開(kāi)差距的Spring Task定時(shí)任務(wù)、微信支付流程項(xiàng)目里都有涉及。這一期我們先從宏觀架構(gòu)和數(shù)據(jù)庫(kù)設(shè)計(jì)講起慢慢往里鉆。1. 內(nèi)容整體設(shè)計(jì)與思路拆解1.1 為什么每個(gè)外賣(mài)項(xiàng)目都長(zhǎng)這樣如果你手頭有蒼穹外賣(mài)的源碼打開(kāi)之后第一反應(yīng)大概率是分模塊太多了。admin端、user端、common公共模塊三個(gè)大模塊堆在一起剛開(kāi)始很容易懵。但你別怕這種結(jié)構(gòu)恰恰是真實(shí)企業(yè)項(xiàng)目的縮影。你可以把這三層理解成一個(gè)餐廳的運(yùn)轉(zhuǎn)邏輯common模塊相當(dāng)于餐廳的“后廚標(biāo)準(zhǔn)操作規(guī)程”所有菜怎么做、配料怎么切標(biāo)準(zhǔn)都在這里admin模塊是“店長(zhǎng)后臺(tái)”管菜單、管員工、管營(yíng)業(yè)額user端是“顧客點(diǎn)餐小程序”用戶能看到什么菜、能下單、能催單。三者之間的依賴關(guān)系也很清晰user依賴commonadmin也依賴common但admin和user互不依賴。這種設(shè)計(jì)能帶來(lái)一個(gè)很實(shí)際的好處——改小程序邏輯的時(shí)候絕不可能影響到管理后臺(tái)反之亦然。如果你在一個(gè)工程里寫(xiě)過(guò)那種“五百個(gè)類(lèi)堆在一起”的代碼再回頭看你就會(huì)特別感激這種拆法。1.2 從零設(shè)計(jì)外賣(mài)系統(tǒng)先解決哪些問(wèn)題如果你要自己從零做一個(gè)外賣(mài)項(xiàng)目通常面臨的是下面這幾個(gè)問(wèn)題用戶身份怎么區(qū)分、菜品怎么分類(lèi)上架、購(gòu)物車(chē)怎么做、訂單狀態(tài)怎么流轉(zhuǎn)、超時(shí)未支付怎么處理。蒼穹外賣(mài)面對(duì)這些問(wèn)題的解法在業(yè)界其實(shí)是比較標(biāo)準(zhǔn)的方案業(yè)務(wù)問(wèn)題設(shè)計(jì)方案關(guān)鍵點(diǎn)用戶身份JWT登錄、雙端Token校驗(yàn)管理端與用戶端各自持有一套攔截器與登錄邏輯菜品展示分類(lèi)表與菜品表分離采用邏輯外鍵關(guān)聯(lián)方便后續(xù)擴(kuò)展口味、標(biāo)簽、起售停售狀態(tài)購(gòu)物車(chē)用戶維度持久化到數(shù)據(jù)庫(kù)不是Redis臨時(shí)緩存避免丟數(shù)據(jù)引發(fā)客訴訂單流轉(zhuǎn)狀態(tài)機(jī)機(jī)制待付款 → 待接單 → 待送達(dá) → 已完成各狀態(tài)之間有明確流轉(zhuǎn)條件超時(shí)訂單Spring Task定時(shí)掃描對(duì)待付款訂單做超時(shí)取消防止庫(kù)存與運(yùn)力被無(wú)效占用這些方案單拎出來(lái)看都是常規(guī)操作但把它們放在同一個(gè)業(yè)務(wù)閉環(huán)里協(xié)同工作你才能體會(huì)到“設(shè)計(jì)一個(gè)系統(tǒng)”和“寫(xiě)一個(gè)接口”的差別。2. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)2.1 數(shù)據(jù)庫(kù)設(shè)計(jì)先從兩張“不起眼”的表說(shuō)起很多同學(xué)刷項(xiàng)目時(shí)最容易忽略的就是建表腳本。因?yàn)榇a能跑他就不去關(guān)心表結(jié)構(gòu)為什么這么建。但這恰恰是蒼穹外賣(mài)里最值錢(qián)的部分之一。以菜品表dish和口味表dish_flavor為例。你去看單表結(jié)構(gòu)dish表里只存了菜品的基本信息菜品名、分類(lèi)id、價(jià)格、圖片、描述、狀態(tài)、創(chuàng)建時(shí)間、創(chuàng)建人等。而口味表單獨(dú)存了菜品對(duì)應(yīng)口味名字、值、菜品id。為什么要拆兩張表因?yàn)橐坏啦丝赡苡旨永庇秩ケ旨邮[這些多值屬性如果塞在dish表里要么搞出逗號(hào)分隔的一列要么就得冗余好幾列。拆一張子表用外鍵關(guān)聯(lián)查詢時(shí)再join回來(lái)這才是關(guān)系型數(shù)據(jù)庫(kù)的正確姿勢(shì)。我自己踩過(guò)一個(gè)坑之前做項(xiàng)目圖省事把所有口味都塞到一個(gè)字段里用JSON字符串存儲(chǔ)。前期數(shù)據(jù)量小倒沒(méi)啥感覺(jué)等用戶量上來(lái)想要“按口味篩選菜品”的時(shí)候才發(fā)現(xiàn)字符串里的內(nèi)容根本沒(méi)有辦法走索引只能全表掃描。后來(lái)老老實(shí)實(shí)拆表篩選查詢的速度馬上就提上來(lái)了。這里有個(gè)細(xì)節(jié)值得注意實(shí)體類(lèi)里對(duì)時(shí)間字段的處理。蒼穹外賣(mài)的公共字段創(chuàng)建時(shí)間、修改時(shí)間、創(chuàng)建人、修改人是通過(guò)MyBatis-Plus的字段填充自動(dòng)處理的。你在插入或更新數(shù)據(jù)時(shí)不需要手動(dòng)set這些字段只需要在對(duì)應(yīng)的實(shí)體屬性上加上TableField(fill FieldFill.INSERT)這類(lèi)注解。這個(gè)設(shè)計(jì)很成熟能避免大量重復(fù)代碼而且能保證每一條數(shù)據(jù)都有完整的審計(jì)信息。2.2 JWT雙端登錄一個(gè)系統(tǒng)里藏著兩套令牌體系蒼穹外賣(mài)里最繞不開(kāi)的一個(gè)知識(shí)點(diǎn)是JWT。光會(huì)調(diào)接口還不夠你必須清楚這兩套Token為什么要分開(kāi)。管理端的用戶是員工對(duì)應(yīng)的是employee表用戶端的用戶是C端顧客對(duì)應(yīng)的是user表。兩端登錄接口各自簽發(fā)各自的Token在網(wǎng)關(guān)層攔截的時(shí)候也各自校驗(yàn)各自的密鑰。我見(jiàn)過(guò)不少人在簡(jiǎn)歷里寫(xiě)“熟悉JWT”問(wèn)他如果管理端員工Token泄露了用戶端能用嗎他答不上來(lái)。答案很簡(jiǎn)單不能。因?yàn)镴WT的載荷里包含了身份標(biāo)識(shí)和權(quán)限范圍而接收方在驗(yàn)簽時(shí)會(huì)先確認(rèn)這是不是自己簽發(fā)的Token。兩端密鑰獨(dú)立就意味著即使某一端的密鑰泄露另一端也不會(huì)立即失控。在自測(cè)時(shí)候有個(gè)非常實(shí)用的工具是Swagger。蒼穹外賣(mài)里管理端的Controller都加了接口文檔注解你本地跑起來(lái)之后可以直接在Swagger頁(yè)面上做登錄把返回的Token復(fù)制出來(lái)然后在每個(gè)請(qǐng)求的Header里帶上它。只要Token沒(méi)過(guò)期你就能在瀏覽器里直接模擬所有管理端操作。這種方式調(diào)起B(yǎng)ug來(lái)比Postman一個(gè)個(gè)手填要快得多。3. 實(shí)操過(guò)程與核心環(huán)節(jié)實(shí)現(xiàn)3.1 菜品管理模塊從新增到起售停售的鏈路菜品管理這個(gè)模塊是蒼穹外賣(mài)里最適合用來(lái)打通“前后端分離開(kāi)發(fā)思維”的案例。先看新增菜品的請(qǐng)求參數(shù)結(jié)構(gòu){ name: 宮保雞丁, categoryId: 12, price: 28.00, image: https://xxx.com/1.jpg, description: 微辣花生米脆香, flavors: [ { name: 辣度, value: [微辣, 中辣, 特辣] }, { name: 忌口, value: [不要蔥, 不要蒜] } ] }注意這個(gè)參數(shù)結(jié)構(gòu)里面已經(jīng)隱含了一個(gè)重要信息接收對(duì)象不能直接用dish實(shí)體做入?yún)?。因?yàn)閐ish實(shí)體里沒(méi)有口味列表這個(gè)字段。所以蒼穹外賣(mài)里專(zhuān)門(mén)定義了一個(gè)DishDTO它不但包含dish實(shí)體的所有字段還在內(nèi)部放了一個(gè)ListDishFlavor用來(lái)接收前端傳過(guò)來(lái)的口味數(shù)組。這一層封裝不是多余的它解決的是前端傳參和數(shù)據(jù)庫(kù)結(jié)構(gòu)不完全一致的問(wèn)題。在實(shí)際企業(yè)開(kāi)發(fā)中這種DTO對(duì)象你幾乎天天都要寫(xiě)。很多人忽略DTO與實(shí)體分離的意義直接把前端的參數(shù)懟到實(shí)體上遇到“實(shí)體字段比參數(shù)少”或者“參數(shù)需要幾個(gè)實(shí)體拼接”的時(shí)候代碼就開(kāi)始變形。而DTO能讓你把接口入?yún)⒌目趶焦潭ㄏ聛?lái)哪怕后端實(shí)體重構(gòu)了只要DTO不變前端就不需要跟著動(dòng)。新增菜品的完整鏈路是Controller接收DTOService層手動(dòng)把DTO中的基礎(chǔ)字段拷貝到dish實(shí)體調(diào)用dishMapper插入菜品基本信息遍歷flavors列表逐個(gè)插入dish_flavor表事務(wù)控制任何一步失敗則整體回滾。這里最容易被忽視的是事務(wù)?？赡苡腥擞X(jué)得插入兩張表很平常但如果不用事務(wù)在執(zhí)行過(guò)程中某一條insert語(yǔ)句報(bào)錯(cuò)就會(huì)留下“菜品存在但口味沒(méi)有”的臟數(shù)據(jù)。臟數(shù)據(jù)在管理端會(huì)造成菜品編輯時(shí)口味為空在用戶端會(huì)引發(fā)查不到完整菜品的尷尬。蒼穹外賣(mài)里在Service層的add方法上加Transactional就是為了避免這種不一致。再聊一下“起售停售”這個(gè)功能。別看它只是一個(gè)開(kāi)關(guān)底層邏輯其實(shí)涉及緩存一致性。菜品起售時(shí)要把狀態(tài)改成1停售時(shí)改成0。但如果用戶端使用了Redis緩存菜品列表這里就必須聯(lián)動(dòng)清理緩存。蒼穹外賣(mài)的處理方式是調(diào)用Spring Cache的CacheEvict在修改菜品狀態(tài)時(shí)把對(duì)應(yīng)分類(lèi)下的緩存數(shù)據(jù)淘汰掉。這么做有個(gè)好處是下次用戶端請(qǐng)求過(guò)來(lái)緩存為空查詢數(shù)據(jù)庫(kù)生成新緩存展示出來(lái)的就是最新?tīng)顟B(tài)代價(jià)是首次請(qǐng)求會(huì)略微變慢但相比起用戶端每次都被舊數(shù)據(jù)坑到這個(gè)代價(jià)完全可接受。3.2 購(gòu)物車(chē)為什么存數(shù)據(jù)庫(kù)而不是Redis購(gòu)物車(chē)這個(gè)功能看起來(lái)簡(jiǎn)單但設(shè)計(jì)思路很有講究。蒼穹外賣(mài)選擇把購(gòu)物車(chē)綁定到用戶id上單獨(dú)建一張shopping_cart表。每一行記錄用戶加入的一個(gè)商品、數(shù)量、口味信息。之前有人問(wèn)我“購(gòu)物車(chē)這種高頻操作為什么不用Redis緩存頻繁寫(xiě)庫(kù)不是浪費(fèi)性能嗎”我當(dāng)時(shí)給他打了個(gè)比方購(gòu)物車(chē)就像你去超市購(gòu)物手里推的購(gòu)物車(chē)你肯定不希望超市因?yàn)橄到y(tǒng)故障把你購(gòu)物車(chē)?yán)锏臇|西清空。對(duì)于外賣(mài)場(chǎng)景也一樣用戶花了十分鐘慢慢挑好的菜結(jié)果因?yàn)榫彺孢^(guò)期就不見(jiàn)了這種體驗(yàn)是致命的。所以購(gòu)物車(chē)必須持久化用戶下次登錄還能看到這才符合業(yè)務(wù)預(yù)期。這里有一個(gè)非常隱蔽的坑用戶往購(gòu)物車(chē)?yán)锒啻渭油粋€(gè)商品時(shí)是插入新記錄還是增加數(shù)量蒼穹外賣(mài)的做法是先按userId dishId 口味查詢?nèi)绻呀?jīng)存在就更新數(shù)量加一如果不存在才插入新紀(jì)錄。這段代碼的邏輯雖然簡(jiǎn)單但它體現(xiàn)了一個(gè)原則購(gòu)物車(chē)的唯一性由“用戶商品具體口味”共同決定。同一個(gè)宮保雞丁一份不要蔥和一份不要蒜其實(shí)是兩條購(gòu)物車(chē)記錄。因?yàn)閿?shù)據(jù)庫(kù)里加入了購(gòu)物車(chē)表所以支付模塊取消訂單時(shí)也可以反過(guò)來(lái)回滾購(gòu)物車(chē)狀態(tài)。這種數(shù)據(jù)閉環(huán)靠純緩存方案很難做完整。3.3 訂單狀態(tài)流轉(zhuǎn)與超時(shí)取消Spring Task 的真正價(jià)值訂單模塊是蒼穹外賣(mài)里技術(shù)密度最高的部分。一張訂單表里包含了訂單號(hào)、下單人、下單時(shí)間、支付狀態(tài)、訂單狀態(tài)、預(yù)計(jì)送達(dá)時(shí)間、菜品詳情快照、地址快照等字段。對(duì)你沒(méi)看錯(cuò)里面存的是“快照”。這里解釋一下“快照”的概念。比如用戶下單時(shí)選的宮保雞丁是28元但商家在用戶下單后把價(jià)格調(diào)成了35元。那這筆訂單應(yīng)該按哪個(gè)價(jià)格結(jié)算答案必須是下單時(shí)的28元。所以訂單表不能只存菜品id它還必須在生成訂單那一刻把菜品的名稱(chēng)、價(jià)格、圖片全部冗余拷貝過(guò)來(lái)。這就是快照。這個(gè)設(shè)計(jì)可能在學(xué)校項(xiàng)目里不多見(jiàn)但在真實(shí)的電商系統(tǒng)里極其常見(jiàn)——它保護(hù)的是交易契約的穩(wěn)定性。訂單狀態(tài)流轉(zhuǎn)的核心邏輯都集中在OrderServiceImpl里。常見(jiàn)狀態(tài)包括待付款1待接單2已接單/配送中3已完成4已取消5退款6每個(gè)狀態(tài)只能通過(guò)特定動(dòng)作轉(zhuǎn)換比如用戶支付后從待付款變待接單商家接單后變配送中送達(dá)后自動(dòng)完成。如果你在寫(xiě)狀態(tài)更新時(shí)不加條件限制直接set一個(gè)新?tīng)顟B(tài)那么客戶端只要多傳一個(gè)狀態(tài)值訂單就能被惡意跳過(guò)流程。所以蒼穹外賣(mài)里的狀態(tài)更新基本都是UPDATE orders SET status ? WHERE id ? AND status ?這種樂(lè)觀鎖風(fēng)格的條件更新這也是應(yīng)付面試時(shí)一個(gè)很值得說(shuō)的細(xì)節(jié)。超時(shí)未支付的處理則是Spring Task在項(xiàng)目里最直接的落地場(chǎng)景。每過(guò)一定時(shí)間系統(tǒng)自動(dòng)執(zhí)行一次掃描任務(wù)把當(dāng)前時(shí)間減去下單時(shí)間超過(guò)15分鐘且狀態(tài)仍為“待付款”的訂單批量改成“已取消”。這種定時(shí)任務(wù)的成本很低也不追求實(shí)時(shí)性用Spring自帶的調(diào)度機(jī)制就夠用完全不需要上消息隊(duì)列。這里還牽扯到一個(gè)“庫(kù)存恢復(fù)”的隱藏邏輯用戶下單時(shí)鎖定的庫(kù)存在訂單取消之后必須釋放。雖然蒼穹外賣(mài)里商品庫(kù)存的概念沒(méi)有電商項(xiàng)目那么重但這個(gè)思路是一致的——取消訂單不只是改一個(gè)狀態(tài)背后關(guān)聯(lián)的資源釋放動(dòng)作也得跟上。3.4 微信支付模擬沒(méi)有真實(shí)商戶號(hào)怎么聯(lián)調(diào)這是很多同學(xué)卡住的地方。因?yàn)槲⑿胖Ц缎枰鎸?shí)的商戶號(hào)、證書(shū)和回調(diào)域名本地開(kāi)發(fā)環(huán)境根本沒(méi)法完成完整流程。蒼穹外賣(mài)這里做了一個(gè)很務(wù)實(shí)的折中支付功能只需要生成支付參數(shù)真正發(fā)起支付時(shí)跳到模擬頁(yè)面并把支付結(jié)果手動(dòng)置為成功。但在知識(shí)點(diǎn)復(fù)盤(pán)時(shí)我們依然要理解微信支付的完整時(shí)序用戶下單后后端調(diào)用微信支付的下單接口傳入訂單號(hào)、金額、回調(diào)地址微信返回一個(gè)支付鏈接或支付參數(shù)前端拉起支付用戶支付完成后微信服務(wù)器異步通知后端回調(diào)接口后端校驗(yàn)簽名、金額訂單號(hào)確認(rèn)無(wú)誤后修改訂單狀態(tài)為已支付并向微信返回應(yīng)答。本地沒(méi)有真實(shí)商戶號(hào)時(shí)調(diào)試重點(diǎn)放到第5步的回調(diào)邏輯。你可以用內(nèi)網(wǎng)穿透工具把本地服務(wù)暴露到公網(wǎng)再用第三方支付測(cè)試工具模擬微信的異步通知。只要你能正確解析回調(diào)里的XML并完成驗(yàn)簽這筆訂單就算通了。等以后真拿到商戶號(hào)你只需要換成真實(shí)的HTTP請(qǐng)求調(diào)用業(yè)務(wù)邏輯幾乎不用動(dòng)。4. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄4.1 JWT攔截器放行了不該放行的路徑這是所有人都會(huì)遇到的第一個(gè)問(wèn)題。明明配了攔截器但某些匿名接口比如用戶端登錄、管理端登錄、用戶端菜品瀏覽依然被攔截前端一片401。排查思路很簡(jiǎn)單打開(kāi)攔截器配置類(lèi)把excludePathPatterns里配的路徑和Controller上RequestMapping的路徑逐個(gè)比對(duì)。很多人栽在這里是因?yàn)槁窂綄?xiě)得不一致比如Controller是/user/user但攔截器里配的是/user這當(dāng)然放行不了。經(jīng)驗(yàn)之談配置放行列表時(shí)一定要把完整路徑寫(xiě)對(duì)盡量以/user/**這種通配符覆蓋子路徑。如果本地自測(cè)時(shí)覺(jué)得麻煩可以先臨時(shí)注釋掉攔截邏輯跑通了再加回來(lái)但記得最后一定要恢復(fù)。4.2 菜品列表查不出來(lái)先確認(rèn)Redis里有沒(méi)有臟緩存用戶端菜品分類(lèi)查詢用的是Spring Cache Redis。最典型的Bug場(chǎng)景是管理端修改了菜品用戶端看到的還是老樣子。原因基本集中在緩存沒(méi)有失效。檢查步驟三步走確認(rèn)管理端修改菜品時(shí)有沒(méi)有觸發(fā)CacheEvict確認(rèn)CacheEvict的key和用戶端查詢時(shí)Cacheable的key是否一致直接進(jìn)Redis用keys命令查看所有相關(guān)緩存比對(duì)數(shù)據(jù)時(shí)間和菜品最新更新時(shí)間。這里有個(gè)坑是key生成策略。Spring Cache默認(rèn)的key是“參數(shù)組合”如果管理端清除緩存用的key和用戶端讀取用的key完全不是一回事那緩存永遠(yuǎn)清不掉。解決辦法就是統(tǒng)一定義緩存key的前綴和拼接規(guī)則比如dish_category_分類(lèi)id不要圖省事兒不寫(xiě)key直接用默認(rèn)規(guī)則。4.3 超時(shí)訂單沒(méi)被掃描到先查time條件Spring Task定時(shí)任務(wù)跑了日志也打了但數(shù)據(jù)庫(kù)里過(guò)期的訂單就是沒(méi)被取消。大多數(shù)情況下是SQL里的時(shí)間比較寫(xiě)錯(cuò)了。比如你把“下單時(shí)間小于當(dāng)前時(shí)間減15分鐘”寫(xiě)成了“下單時(shí)間大于”或者直接拿字符串比較時(shí)間都會(huì)導(dǎo)致篩選結(jié)果為空。在本地復(fù)現(xiàn)這個(gè)功能時(shí)我建議你造一條訂單把下單時(shí)間改成20分鐘以前然后手動(dòng)執(zhí)行一次定時(shí)方法觀察日志和數(shù)據(jù)庫(kù)。如果按真實(shí)場(chǎng)景等15分鐘調(diào)試效率太低了。4.4 菜品口味新增失敗多半是事務(wù)沒(méi)生效在一個(gè)Service方法里同時(shí)插入dish和dish_flavor如果插入口味時(shí)報(bào)錯(cuò)而菜品卻插入成功大概率是事務(wù)沒(méi)包住。通常原因有兩個(gè)類(lèi)沒(méi)有被Spring容器管理即缺Service注解方法被同類(lèi)內(nèi)部調(diào)用導(dǎo)致AOP代理失效。解決方式也很簡(jiǎn)單在public方法上加Transactional并確保調(diào)用方和被調(diào)用方在Spring容器中不要用this內(nèi)部調(diào)用。要是你為了啟動(dòng)速度把某些Service排除出了包掃描范圍那事務(wù)自然也不生效。4.5 支付回調(diào)驗(yàn)簽失敗先看證書(shū)和密鑰格式模擬聯(lián)調(diào)中回調(diào)驗(yàn)簽失敗的當(dāng)場(chǎng)不必急著懷疑代碼邏輯更常見(jiàn)的情況是你配置的API密鑰是微信商戶平臺(tái)的老版密鑰不是V3版本的APIv3密鑰或者證書(shū)解出來(lái)多了一行換行符。最簡(jiǎn)單有效的方式是先把完整的回調(diào)報(bào)文原樣打日志人工核對(duì)該報(bào)文里的字段再單獨(dú)測(cè)試驗(yàn)簽函數(shù)是否能對(duì)已知簽名的數(shù)據(jù)返回true。驗(yàn)簽單獨(dú)通過(guò)之后再串進(jìn)回調(diào)接口里看整體流程。5. 避坑經(jīng)驗(yàn)分享個(gè)人實(shí)操心得刷蒼穹外賣(mài)這種項(xiàng)目切忌眼高手低。代碼輪子很容易敲出來(lái)但真正值的是把每條鏈路背后的“為什么”想明白。我個(gè)人的實(shí)操心得可以濃縮成三條第一先跑通再重構(gòu)最后刪了重寫(xiě)一遍。你跟著教程敲完整個(gè)項(xiàng)目只能算入門(mén)把它從自己腦子里按記憶重新實(shí)現(xiàn)一遍才算消化。刪掉自己剛寫(xiě)完的代碼這件事聽(tīng)起來(lái)很刺激但效果出奇地好。第二遍重寫(xiě)的時(shí)候你會(huì)開(kāi)始考慮異常處理、狀態(tài)枚舉、DTO設(shè)計(jì)這些東西因?yàn)橛械谝槐榈娜忠暯悄銜?huì)更自然地做出更好的設(shè)計(jì)決策。第二每做完一個(gè)模塊就畫(huà)一張模塊關(guān)系圖。不一定是正式文檔可以是草稿紙上的圈圈線線。這個(gè)動(dòng)作能幫你把Controller、Service、Mapper、數(shù)據(jù)庫(kù)表之間的關(guān)系印在腦子里。面試官問(wèn)“你做過(guò)的項(xiàng)目有哪些模塊”你不至于只記得一堆方法名而是能講清楚模塊間怎么協(xié)作。第三不要跳過(guò)支付回調(diào)的模擬。很多人覺(jué)得本地沒(méi)有商戶號(hào)支付這塊看看視頻就好。但你一旦跳過(guò)后面面試被追問(wèn)支付流程就會(huì)露怯?；ㄒ粋€(gè)下午用模擬工具走通一遍回調(diào)收益遠(yuǎn)比你想象的大。以后再聊到具體的模塊時(shí)我們可以一個(gè)個(gè)把它們打透。比如訂單狀態(tài)機(jī)可以再細(xì)化出“取消訂單”的庫(kù)存回補(bǔ)邏輯比如用戶端菜品瀏覽如何結(jié)合Redis做分類(lèi)分頁(yè)緩存比如管理端營(yíng)業(yè)統(tǒng)計(jì)里的數(shù)據(jù)如何用SQL一次性聚合出來(lái)。慢慢來(lái)把每一期都吃透面試和實(shí)操就都不怕了。