簡介面向微信小程序與前端崗位求職者的一份高頻面試題速查手冊以PDF形式整理了二十道常見問題。內(nèi)容覆蓋必備文件與全局配置、事件傳值、數(shù)據(jù)請求封裝、頁面間傳參、路由跳轉(zhuǎn)等核心模塊并將小程序與Vue.js在數(shù)據(jù)綁定、事件綁定、雙向綁定上的差異以及WXML與HTML、WXSS與CSS的異同做了對照歸納還梳理了onLoad、onShow等生命周期函數(shù)與wx.navigateTo、wx.redirectTo等路由方式。整個資源包只有1個PDF文件大小182KB篇幅緊湊適合離線閱讀或面試前集中翻閱。文件以問答形式逐題給出結(jié)論、關(guān)鍵寫法和易錯點(diǎn)例如data-*傳值不能包含大寫字母、WXSS僅支持部分選擇器等能幫助開發(fā)者快速搭建小程序知識框架、查漏補(bǔ)缺。目前已有747人學(xué)習(xí)下載對準(zhǔn)備前端或小程序面試的讀者有較好的參考價值。1. 小程序常見面試題到底在考什么一份《小程序常見面試題20題》放在你面前從目錄看每題都有標(biāo)準(zhǔn)答案可真到了面試現(xiàn)場面試官只挑其中一道往深了問問到你接不住話。小程序面試題不是網(wǎng)頁開發(fā)題的簡單換皮它考的是在雙線程架構(gòu)、分包限制、組件化約束下你怎么設(shè)計(jì)數(shù)據(jù)流、怎么理解生命周期、怎么做性能取舍。這篇文章不打算逐題給答案而是把 20 題背后的考點(diǎn)拆成一條知識鏈路架構(gòu)、生命周期、通信機(jī)制、答題框架、避坑經(jīng)驗(yàn)最后給你一套能遷移到任何前端方向的面試準(zhǔn)備方法。適合已經(jīng)寫過小程序但答題不成體系的前端開發(fā)者也適合準(zhǔn)備轉(zhuǎn)小程序方向、想快速建立完整知識框架的同學(xué)。我按原理 → 操作 → 避坑 → 自查的順序展開每章給的代碼都能在開發(fā)者工具里直接跑給的答題結(jié)構(gòu)都能在面試現(xiàn)場直接套。讀完你會發(fā)現(xiàn)面試官手里的 20 道題其實(shí)是在用不同問法反復(fù)確認(rèn)同一條知識鏈?zhǔn)欠裢暾?. 小程序架構(gòu)與生命周期第一道題就把候選人分成兩檔面試開始五分鐘內(nèi)面試官通常會拋出一道請說說小程序的運(yùn)行架構(gòu)。這道題看似基礎(chǔ)實(shí)際上能把候選人分成兩檔一檔只能說小程序是雙線程的另一檔能解釋清楚為什么必須雙線程、冷啟動和熱啟動有什么區(qū)別、生命周期誰先誰后。如果你還能把頁面棧、組件生命周期、數(shù)據(jù)通信串成一條清晰的鏈路面試官對你的判斷會直接升一檔。這一章先把這條鏈路完整走一遍最后用一個日志 Demo 讓你親手驗(yàn)證觸發(fā)順序避免背了答案卻說不清原理。2.1 雙線程模型為什么渲染層和邏輯層必須分開小程序運(yùn)行環(huán)境不是普通瀏覽器頁面而是由邏輯層App Service和渲染層多個 WebView組成。邏輯層負(fù)責(zé)業(yè)務(wù)邏輯、數(shù)據(jù)處理、接口請求和狀態(tài)管理渲染層負(fù)責(zé)把 WXML 模板和 WXSS 樣式渲染成用戶看到的界面。兩層之間沒有直接共享數(shù)據(jù)的通道所有數(shù)據(jù)交換都要經(jīng)過一層數(shù)據(jù)序列化——跨線程傳遞——渲染層解析執(zhí)行的通道。也就是說你每次調(diào)用 setData都不只是改一個對象而是在做一次跨線程通信。面試追問為什么必須分開時建議從三個角度回答。第一是安全隔離邏輯層拿不到渲染層的 DOM渲染層也碰不到邏輯層的完整運(yùn)行時權(quán)限邊界清晰惡意腳本能做的事被限制在一個可控范圍內(nèi)。第二是穩(wěn)定性與性能渲染層是 WebView某個頁面渲染崩潰不至于把整個邏輯層一起拖垮邏輯層跑在獨(dú)立引擎里不受單頁面復(fù)雜 DOM 操作的干擾。第三是跨端一致性小程序要跑在多種平臺容器里渲染層在不同端可能是不同的 WebView 實(shí)現(xiàn)而邏輯層由框架統(tǒng)一接管業(yè)務(wù)代碼可以保持盡量一致。能答出這三層這道送分題才會變成你的加分題。2.2 生命周期觸發(fā)順序頁面與組件誰先誰后小程序生命周期是面試必考而且專門喜歡交叉著問。頁面生命周期五個onLoad、onShow、onReady、onHide、onUnload。組件生命周期五個created、attached、ready、moved、detached。單獨(dú)背這兩個列表并不難難點(diǎn)在于交錯時的先后順序。我把總結(jié)的順序表放在下面建議直接記進(jìn)筆記。場景觸發(fā)順序冷啟動小程序App onLaunch → App onShow → Page onLoad → Page onShow → Page onReady組件首次掛載組件 created → 組件 attached → 組件 ready → 頁面 onReady組件 ready 在頁面 onReady 之前頁面 A 跳頁面 BA onHide → B onLoad → B onShow → B onReady → A 保持在 onHide 狀態(tài)從 B 返回 AA onShow → B onUnload切后臺再回前臺App onHide → Page onHide → 回到前臺后 App onShow → Page onShow頁面棧深層邏輯同樣要懂每調(diào)一次 wx.navigateTo 就壓入一個新頁面棧深度上限是十層超過十層 navigateTo 會失敗。我一般會封裝一個跳轉(zhuǎn)工具用 getCurrentPages().length 判斷棧深度接近上限時改走 wx.redirectTo 或 wx.reLaunch避免用戶在頁面鏈里無限往下鉆。面試時能主動提這個封裝思路說明你不只是背了限制而是真的被十層?？舆^。2.3 冷啟動、熱啟動、頁面棧三個容易被含糊帶過的考點(diǎn)冷啟動指用戶首次打開小程序或小程序進(jìn)程已被系統(tǒng)回收后再次打開此時需要重新創(chuàng)建邏輯層與渲染層、重新加載代碼包所以耗時明顯更長。熱啟動指小程序已經(jīng)在后臺存活用戶重新進(jìn)入此時不需要重新加載代碼包只觸發(fā) App 的 onShow 和頁面的 onShow。這個區(qū)別直接關(guān)聯(lián)到一個高頻優(yōu)化問題為什么小程序啟動這么慢冷啟動慢的根因通常集中在三塊主包體積過大、啟動階段同步邏輯過多、首屏依賴的接口過慢。常見方案是把非首屏頁面拆到分包讓首屏只加載主包資源同時避免在 onLaunch 里做大量同步讀寫尤其不要一啟動就把大對象從 storage 拉到內(nèi)存。熱啟動慢的場景一般不是加載慢而是數(shù)據(jù)陳舊——用戶在后臺掛了一小時再回來列表頁展示的還是舊緩存這時在 onShow 里做增量刷新才是正確姿勢?；卮鹄锶绻軈^(qū)分冷啟動要減資源、熱啟動要管時效面試官就會確認(rèn)你是有實(shí)戰(zhàn)體感的。2.4 打開開發(fā)者工具驗(yàn)證最小生命周期日志 Demo理論講再多都不如把日志打出來看一遍。我建議在開發(fā)者工具里新建一個測試頁面把 App 和 Page 的生命周期回調(diào)全部加上 console.log然后分別執(zhí)行四個操作冷啟動、切后臺、回前臺、關(guān)閉頁面。你看到的輸出順序會幫你徹底搞清楚哪些回調(diào)重復(fù)觸發(fā)哪些只在創(chuàng)建時觸發(fā)一次。// app.js App({ onLaunch() { console.log([app] onLaunch); }, onShow() { console.log([app] onShow); }, onHide() { console.log([app] onHide); } });// pages/trace/trace.js Page({ onLoad(options) { console.log([page] onLoad, options); }, onShow() { console.log([page] onShow); }, onReady() { console.log([page] onReady); }, onHide() { console.log([page] onHide); }, onUnload() { console.log([page] onUnload); } });邏輯說明App 生命周期隨小程序整體的啟動與前后臺切換觸發(fā)Page 生命周期隨頁面實(shí)例的創(chuàng)建、顯示、隱藏、銷毀觸發(fā)。兩者交錯后固定的規(guī)律是先 App 后 Page。參數(shù)說明onLoad 的 options 是頁面跳轉(zhuǎn)時拼接在 url 上的 query 參數(shù)首次創(chuàng)建必傳冷啟動時還能從 options 里讀到場景值用來區(qū)分用戶是從哪里進(jìn)入小程序的。跑完 Demo 你會發(fā)現(xiàn)頁面從后臺回前臺只觸發(fā) onShow不會重新觸發(fā) onLoad 和 onReady。這個觀察很值錢——很多列表頁刷新邏輯寫在 onLoad 里從詳情頁返回時數(shù)據(jù)永遠(yuǎn)是舊的。以后面試被問為什么我的頁面數(shù)據(jù)不刷新根因就在這里。3. 小程序數(shù)據(jù)與通信機(jī)制面試?yán)镒钊菀妆蛔穯柕膮^(qū)域20 道題里直接考 setData 的至少五道變著法追問setData 是同步還是異步為什么 this.data 已經(jīng)新了視圖卻還舊頻繁 setData 會有什么后果另一類高頻題考頁面間通信navigateTo 之后怎么回傳數(shù)據(jù)tabBar 頁面怎么感知變化組件和頁面之間怎么傳事件。這一章把通信機(jī)制拆成三個層次數(shù)據(jù)到視圖、頁面到頁面、組件到頁面每層都給出可運(yùn)行代碼和參數(shù)說明。3.1 setData 的雙軌更新為什么 this.data 同步而視圖異步先說結(jié)論調(diào)用 setData 后 this.data 立即更新視圖渲染異步完成。這個雙軌更新讓很多人翻車因?yàn)槊嬖嚬贂穯杢his.data 都同步了你怎么還說 setData 是異步的你要分清兩件事邏輯層本地?cái)?shù)據(jù)確實(shí)是同步替換的但從邏輯層到渲染層的傳輸、解析、繪制全程異步。所以嚴(yán)格說setData 是數(shù)據(jù)同步、渲染異步。另一個高頻追問點(diǎn)是 setData 的性能損耗。每次調(diào)用都要做一次跨線程序列化傳輸傳的數(shù)據(jù)越大、頻率越高損耗越明顯。面試時講優(yōu)化方向就三個減少調(diào)用次數(shù)、縮小更新范圍、降低觸發(fā)頻率。縮小范圍有個很實(shí)用的技巧就是路徑更新this.setData({ list[0].name: newName })只更新數(shù)組里某一項(xiàng)而不是把整個 list 重新傳過去。滾動場景則是節(jié)流的經(jīng)典應(yīng)用場景。// 反例滾動回調(diào)里高頻 setData一幀一次數(shù)據(jù)量還在漲 onPageScroll(e) { this.setData({ scrollTop: e.scrollTop }); }// 正例節(jié)流合并更新一百毫秒最多一次只傳最后的值 onPageScroll(e) { this._latestScrollTop e.scrollTop; if (this._throttled) return; this._throttled true; setTimeout(() { this.setData({ scrollTop: this._latestScrollTop }); this._throttled false; }, 100); }邏輯說明節(jié)流的核心是先用實(shí)例變量存最新滾動位置再按固定間隔把位置寫入 setData這樣渲染線程收到的更新頻率被壓住首屏和滾動都不容易卡頓。參數(shù)說明setData 的第二個參數(shù)是渲染完成回調(diào)適合放依賴新視圖的代碼比如查詢節(jié)點(diǎn)高度第一個參數(shù)支持路徑 key這是官方支持的字段級更新方式性能優(yōu)于傳整個對象。3.2 頁面通信三選一EventChannel、globalData、storage 的邊界頁面間怎么傳數(shù)據(jù)會以各種形式出現(xiàn)B 頁面怎么把結(jié)果回傳給 AtabBar 頁面之間怎么共享登錄狀態(tài)跨頁面分發(fā)通知用什么核心都是讓你做方案選型。三個候選沒有絕對好壞只有邊界是否合適。我這里給出我的判斷標(biāo)準(zhǔn)。第一種 EventChannel適合頁面跳轉(zhuǎn)場景下的即時雙向通信。在 wx.navigateTo 的 success 回調(diào)里通過 res.eventChannel.emit 給目標(biāo)頁面發(fā)消息目標(biāo)頁面在 onLoad 里用 this.getOpenerEventChannel().on 接收。這套機(jī)制比在 url 上拼參數(shù)靈活也不會污染全局狀態(tài)。要注意它是頁面實(shí)例級管道頁面卸載后管道銷毀不能當(dāng)全局事件總線用。// 頁面 A 跳轉(zhuǎn)并向 B 發(fā)初始數(shù)據(jù) wx.navigateTo({ url: /pages/detail/detail?id1, success(res) { res.eventChannel.emit(initData, { from: A, id: 1 }); } });// 頁面 B 接收消息并回傳結(jié)果 Page({ onLoad() { const channel this.getOpenerEventChannel(); channel.on(initData, (data) { console.log(B 收到, data); channel.emit(result, { ok: true, value: 42 }); }); } });邏輯說明emit 是單向發(fā)送on 是注冊監(jiān)聽。B 頁面在 onLoad 拿到 channel 后可以通過同一個 channel 再 emit 回 A。參數(shù)說明A 頁面接收回傳結(jié)果的時機(jī)要注意——如果 A 在跳轉(zhuǎn)成功回調(diào)里注冊監(jiān)聽此時頁面棧頂層還是 BA 的實(shí)例沒有進(jìn)入 onShow建議在 A 的 onShow 里注冊監(jiān)聽確保返回時能收到消息。第二種 globalData適合低頻變更、讀取頻繁、不需要持久化的全局?jǐn)?shù)據(jù)比如用戶信息、配置項(xiàng)。但 globalData 不是響應(yīng)式的修改后不會通知頁面刷新頁面要想感知變化只能在 onShow 里重新讀取或者自己寫一套簡單的訂閱通知。第三種 storage適合需要跨啟動保存的數(shù)據(jù)比如登錄態(tài)、草稿。它的缺點(diǎn)也明顯頻繁寫 storage 會增加 IO 開銷而且它和內(nèi)存對象不保持引用關(guān)系修改后不會自動同步到頁面。把 storage 當(dāng)全局狀態(tài)管理用早晚會踩坑。3.3 組件通信細(xì)節(jié)properties、observers、triggerEvent 的參數(shù)組件化是前端面試必考的。小程序組件題通常盯著三個點(diǎn)外部屬性怎么傳入、內(nèi)部狀態(tài)怎么聯(lián)動、子組件怎么向外部發(fā)消息。對應(yīng)機(jī)制是 properties、observers、triggerEvent。我以計(jì)數(shù)器組件為例外部傳初始值組件內(nèi)部維護(hù)計(jì)數(shù)每次變化都通知外部。// components/counter/counter.js Component({ properties: { initValue: { type: Number, value: 0, observer(newVal) { // 外部屬性變化時同步內(nèi)部狀態(tài) this.setData({ count: newVal }); } } }, data: { count: 0 }, observers: { count: function (val) { console.log(count 變成, val); } }, methods: { handleTap() { this.setData({ count: this.data.count 1 }); this.triggerEvent(change, { value: this.data.count }); } } });!-- components/counter/counter.wxml -- view classcounter text{{count}}/text button sizemini bindtaphandleTap1/button /view邏輯說明properties 定義外部接口observer 在屬性變化時回調(diào)observers 監(jiān)聽 data 或 properties 上任何字段的變化適合做數(shù)據(jù)聯(lián)動methods 里的 handleTap 被模板 bindtap 觸發(fā)先更新自身再用 triggerEvent 把新值拋給外部。參數(shù)說明triggerEvent 第二個參數(shù)是事件攜帶的 detail外部在 e.detail 里讀取第三個參數(shù)可傳對象bubbles 為 true 時事件能冒泡出組件邊界composed 為 true 時能穿透組件邊界進(jìn)入頁面節(jié)點(diǎn)樹面試時主動答出這兩個布爾值是明顯的加分項(xiàng)。頁面?zhèn)冉邮帐录?bind:changeonCounterChange回調(diào)里 event.detail.value 就是組件拋出的新計(jì)數(shù)。這里還有一個值得主動提的點(diǎn)observers 不要做重計(jì)算每次 setData 都會觸發(fā)一遍復(fù)雜邏輯應(yīng)移到 methods 里手動調(diào)用這個細(xì)節(jié)能體現(xiàn)你真的寫過組件。3.4 最小可運(yùn)行的頁面?zhèn)鲄⑹纠讶N方案跑一遍理論講了三種方案建議動手都跑一遍。我搭過一個小 DemoA 頁面有輸入框和按鈕跳轉(zhuǎn)到 BB 回傳一個結(jié)果A 更新標(biāo)題。EventChannel 版本跑通后你會注意到 A 必須在 onShow 里注冊監(jiān)聽否則頁面棧頂層還是 B事件監(jiān)聽時機(jī)不對。換成 globalData 版本再跑一遍問題立刻浮現(xiàn)B 修改 globalData 后A 雖然還在棧里但頁面沒有任何變化必須等用戶返回 A 觸發(fā) onShow 才能讀到新值。這就是非響應(yīng)式全局狀態(tài)的局限。再換 storage 版本A 寫B(tài) 讀改B 再寫回A 返回后重讀。問題變成 IO 開銷和同步時機(jī)數(shù)據(jù)更新后頁面同樣不會自動感知。三個方案跑完你對選型的判斷會從背概念變成看邊界回傳數(shù)據(jù)優(yōu)先 EventChannel共享低頻數(shù)據(jù)用 globalData跨啟動持久化才碰 storage。面試時能把這個決策過程講出來比背三個優(yōu)缺點(diǎn)要可信得多。4. 把 20 道題拆成答題框架從背題到會答題一份 20 題的清單如果逐題背答案面試官換個問法你就卡殼。我的建議是花半小時把題分類歸到幾個知識方向每個方向準(zhǔn)備一套固定答題框架?？蚣艿膬r值在于臨場遇到新題你能把它拆成已知知識點(diǎn)用熟悉的語言組織出來。這一章先講如何分類再給項(xiàng)目經(jīng)驗(yàn)題、手寫代碼題、設(shè)計(jì)題三類題型的應(yīng)對結(jié)構(gòu)。4.1 先把題目分類基礎(chǔ)、性能、工程、原理四象限我把小程序常見面試題粗分成四類?；A(chǔ)題目錄結(jié)構(gòu)、app.json 配置、WXML 語法、列表渲染與條件渲染、事件綁定、模板與組件的區(qū)別。性能題setData 優(yōu)化、分包加載、啟動耗時、首屏渲染、圖片懶加載、骨架屏。工程題請求封裝、登錄態(tài)管理、多環(huán)境配置、上傳發(fā)布、代碼規(guī)范與自動化測試。原理題雙線程模型、生命周期、自定義組件渲染機(jī)制、事件通道。一份 20 題的清單分布大概是一半點(diǎn)落在基礎(chǔ)四五道落在性能三四道落在工程剩余兩三道落在原理。這個分布說明準(zhǔn)備重點(diǎn)應(yīng)該壓在基礎(chǔ)和性能上原理題用來拉檔次。分類后還要合并同類項(xiàng)比如setData 有哪些問題怎么優(yōu)化 setData為什么頻繁 setData 會卡其實(shí)是同一道題。合并完你會發(fā)現(xiàn)20 道題真正需要認(rèn)真準(zhǔn)備的知識節(jié)點(diǎn)只有十來個工程量一下子砍半。4.2 項(xiàng)目經(jīng)驗(yàn)題四段式答法讓面試官聽懂決策過程面試?yán)镉幸活惐貑栴}你做過的小程序項(xiàng)目遇到最大的難題是什么怎么解決的這種題表面考項(xiàng)目實(shí)際考表達(dá)結(jié)構(gòu)。我常用的模板是四段式背景、方案、量化、反思。背景一句話說清項(xiàng)目是什么、你負(fù)責(zé)哪塊。方案列關(guān)鍵決策重點(diǎn)說為什么這樣選而不是上來報結(jié)果。量化給前后對比證明方案有效。反思說一個重來會做得更好的點(diǎn)。舉個例子被問首屏加載慢怎么辦背景是模擬項(xiàng)目X首頁有商品流和多 tab啟動時主包體積偏大。方案是先拆分包非首屏頁面全部移出主包再把首屏圖片改懶加載并加骨架屏。量化是啟動耗時從約 2.1 秒降到 1.2 秒。反思是當(dāng)時沒做分包預(yù)下載如果重做會把詳情子包提前預(yù)取進(jìn)一步減少點(diǎn)擊后的等待。這套結(jié)構(gòu)保證每個環(huán)節(jié)經(jīng)得起追問。面試官想深摳細(xì)節(jié)時你還有為什么用懶加載不用 CDN 優(yōu)化骨架屏怎么保證不遮擋實(shí)際內(nèi)容這類分支可以展開。4.3 手寫代碼題一個常用自定義組件的標(biāo)準(zhǔn)答案20 題中必有手寫題實(shí)現(xiàn)一個自定義組件并讓它對傳入數(shù)據(jù)變化做出響應(yīng)。我準(zhǔn)備的是低配版彈窗模板面試時可以直接默寫邊寫邊念參數(shù)作用。// components/modal/modal.js Component({ properties: { visible: { type: Boolean, value: false }, title: { type: String, value: } }, data: { internalVisible: false }, observers: { visible(val) { // 用 observers 把外部屬性同步到內(nèi)部狀態(tài) this.setData({ internalVisible: val }); } }, methods: { close() { this.triggerEvent(close, {}, { bubbles: true }); }, confirm() { this.triggerEvent(confirm, { value: true }); } } });邏輯說明彈窗是受控組件外部用 visible 控制顯示內(nèi)部用 internalVisible 做實(shí)際渲染。observers 監(jiān)聽 visible 變化保證內(nèi)外狀態(tài)一致。close 和 confirm 向外拋出事件頁面通過 bind:close 和 bind:confirm 接收。參數(shù)說明bubbles 為 true 時事件能從組件冒泡到頁面適合彈窗這類全局交互組件triggerEvent 的 detail 盡量使用對象結(jié)構(gòu)后續(xù)擴(kuò)展字段不用改事件名。手寫時三個細(xì)節(jié)容易丟分第一properties 里 type 必須寫否則運(yùn)行時會報警告第二observers 回調(diào)不要用箭頭函數(shù)this 指向會偏第三事件名在小程序模板里推薦 kebab-case 寫法但 triggerEvent 里傳的是 camelCase 風(fēng)格這個差異要能說明白。這些點(diǎn)會讓面試官確認(rèn)你寫的代碼真的上過線而不是紙面上看著對。4.4 設(shè)計(jì)題追問性能優(yōu)化方案之間的決策順序面試官問用戶量上來了你怎么優(yōu)化小程序期待的不是一個孤立方案而是一套決策思路。我習(xí)慣按定位、方案、驗(yàn)證三步走。先看線上性能數(shù)據(jù)啟動慢看主包體積和啟動腳本頁面卡看 setData 頻率與渲染耗時白屏久看接口響應(yīng)和緩存命中率。沒有數(shù)據(jù)支撐的優(yōu)化方案面試官會一路追問到你答不上來。然后才是方案啟動慢可以分包、預(yù)下載、精簡啟動邏輯頁面卡可以合并 setData、降低組件復(fù)雜度、引入虛擬列表接口慢可以加緩存、做預(yù)請求、優(yōu)化并發(fā)。最后是驗(yàn)證上線前用性能工具做前后對比上線后看線上數(shù)據(jù)和用戶反饋。這里有個容易踩的認(rèn)知誤區(qū)骨架屏不是性能方案只是體感優(yōu)化它解決白屏焦慮不解決加載速度。面試時能說清這個區(qū)別說明你不會被一兩個熱詞帶著走。5. 小程序面試避坑與常見問題排查五個翻車現(xiàn)場小程序開發(fā)的坑在面試?yán)飼兂筛[蔽的追問。有些問題只靠背書發(fā)現(xiàn)不了因?yàn)樗谡鏅C(jī)上才出現(xiàn)有些問題明明能避開卻因?yàn)椴涣私庠蚍磸?fù)踩。這一章寫五條高頻翻車現(xiàn)場每條按現(xiàn)象、原因、解決三步給清楚你對照排查即可。5.1 現(xiàn)象setData 之后立刻查詢節(jié)點(diǎn)還是舊值現(xiàn)象是執(zhí)行完 setData 后馬上用 createSelectorQuery 選節(jié)點(diǎn)尺寸拿到的是舊值。原因是視圖渲染異步節(jié)點(diǎn)尺寸必須等渲染完成后才能查詢。解決是把依賴新視圖的查詢放到 setData 回調(diào)里或等 wx.nextTick 執(zhí)行后再查。// 出錯寫法 this.setData({ height: newHeight }); this.createSelectorQuery() .select(#box) .boundingClientRect(rect { console.log(rect.height); // 舊值 }) .exec(); // 正確寫法 this.setData({ height: newHeight }, () { this.createSelectorQuery() .select(#box) .boundingClientRect(rect { console.log(rect.height); // 新值 }) .exec(); });邏輯說明setData 回調(diào)觸發(fā)說明渲染線程已完成本次更新此時查詢節(jié)點(diǎn)才是安全的。面試時被問為什么 setData 后拿不到節(jié)點(diǎn)高度直接講清雙軌更新邏輯就行。5.2 現(xiàn)象組件事件跨頁面后就丟了現(xiàn)象是頁面 A 里組件觸發(fā)事件監(jiān)聽回調(diào)還沒執(zhí)行用戶就跳到頁面 B返回后發(fā)現(xiàn)回調(diào)丟了。原因是事件監(jiān)聽是運(yùn)行時綁定在當(dāng)前組件實(shí)例上的頁面卸載時組件銷毀監(jiān)聽一并回收。解決是跨頁面數(shù)據(jù)回傳不要依賴組件事件鏈改用 EventChannel 或 globalData頁面內(nèi)有異步回調(diào)要等的話在 onUnload 里做取消和防泄漏處理。5.3 現(xiàn)象開啟獨(dú)立分包后公共方法突然不可用現(xiàn)象是某開發(fā)者把部分頁面挪進(jìn)獨(dú)立分包后這些頁面里訪問 app.globalData 或公共工具函數(shù)時直接報錯邏輯層找不到定義。原因是獨(dú)立分包運(yùn)行時邏輯層與主包不是同一個 JavaScript 上下文兩者不共享全局代碼和 globalData。解決是在設(shè)計(jì)分包時想清楚邊界獨(dú)立分包頁面要自包含它依賴的公共邏輯不能暗地里依賴主包模塊。面試時主動提到分包不是目錄移動得按依賴關(guān)系重新梳理比單純說把頁面移進(jìn) subpackages更有工程分。5.4 現(xiàn)象真機(jī)正常開發(fā)者工具里白屏或報 script error現(xiàn)象是同一份代碼真機(jī)預(yù)覽沒問題開發(fā)者工具卻編譯報錯甚至白屏。原因大概率是工具的本地基礎(chǔ)庫版本與真機(jī)不一致或者工具緩存了舊編譯產(chǎn)物。解決順序先清緩存重新編譯再檢查項(xiàng)目詳情里基礎(chǔ)庫版本最后看報錯堆棧定位文件。不要一上來就懷疑業(yè)務(wù)代碼工具緩存的玄學(xué)問題占比很大。面試?yán)锉粏柕秸鏅C(jī)調(diào)試和工具調(diào)試的差異能說出基礎(chǔ)庫版本這個關(guān)鍵詞就已經(jīng)領(lǐng)先。提示清緩存的操作路徑在開發(fā)者工具菜單欄里選清緩存 → 全部清除然后重新編譯大部分詭異報錯會自己消失。5.5 現(xiàn)象頁面銷毀后 setData 引發(fā)隱蔽告警現(xiàn)象是頁面 onUnload 后頁面里某個異步請求的回調(diào)還在執(zhí)行回調(diào)里調(diào) setData控制臺出現(xiàn)頁面不存在之類的告警或被靜默忽略。原因很直接異步請求沒有隨頁面銷毀取消回調(diào)繼續(xù)跑頁面實(shí)例卻已經(jīng)沒了。解決是在 onUnload 里置一個銷毀標(biāo)記請求回調(diào)里先判斷標(biāo)記再決定要不要 setData更徹底的做法是封裝請求層支持以頁面為單位取消未決請求。這類問題面試官喜歡放在你踩過什么坑里問按現(xiàn)象、原因、解決三步講思路最清晰。6. 把 20 道面試題變成自查表一個有效期不止一場面試的準(zhǔn)備技巧這一章分享我親測有效的準(zhǔn)備方法不按題號背題而是把 20 道題映射到知識樹再準(zhǔn)備一個三分鐘能寫完的手寫 Demo面試結(jié)束立刻復(fù)盤。這套方法不限于小程序任何前端方向都能復(fù)用。6.1 從題目到知識樹三個問題完成歸因拿到任何一道題先問自己三個問題它在考原理、考 API還是考工程權(quán)衡它落在哪棵知識樹上——架構(gòu)、生命周期、通信、性能、工程哪一支如果面試官追問一步會追到哪個節(jié)點(diǎn)三個問題都答得上這道題就不是孤立題目而是知識樹上的一個枝節(jié)。我把小程序知識樹分成五條主枝架構(gòu)與生命周期、數(shù)據(jù)通信與狀態(tài)、性能優(yōu)化與啟動、工程化與發(fā)布、組件與復(fù)用。20 道題歸位后真正需要重點(diǎn)準(zhǔn)備的只剩十道左右其余全是主枝上的變體。6.2 三分鐘手寫 Demo熟到不用想的組件模板面試現(xiàn)場手寫代碼拼的不是靈光一閃而是肌肉記憶。準(zhǔn)備一個不帶第三方依賴的組件模板把 properties、observers、triggerEvent 三個機(jī)制都覆蓋到練到閉眼能寫。這樣就算面試題和模板不完全一樣你也能基于模板快速改出可用版本。寫的時候口頭同步講每個參數(shù)的意義比寫完沉默展示代碼塊加分得多。Component({ properties: { value: Number }, data: {}, observers: { value(v) { console.log(外部 value 變化:, v); } }, methods: { onIncrease() { this.triggerEvent(change, { value: (this.properties.value || 0) 1 }); } } });邏輯說明模板只依賴官方組件能力沒有額外庫現(xiàn)場快速寫出來不會暴露短板。參數(shù)說明方法里讀傳入值用 this.properties.value 而不是 this.data.value因?yàn)橥麛?shù)據(jù)在 data 里只算內(nèi)部狀態(tài)最終以 properties 傳入值為準(zhǔn)。這個細(xì)節(jié)很多人忽略主動說出來會讓面試官確認(rèn)你理解組件數(shù)據(jù)流而不是背模板。6.3 面試后的復(fù)盤清單把遺憾變成下一題的必對項(xiàng)每次面試結(jié)束我會花二十分鐘復(fù)盤。清單只有四項(xiàng)哪些題背過但沒答全哪些題被追問后卡殼哪些知識點(diǎn)完全沒準(zhǔn)備到哪些回答暴露了經(jīng)驗(yàn)邊界。針對后兩項(xiàng)我會先查官方文檔把原理重新讀一遍再回到知識樹更新節(jié)點(diǎn)圖。這套面試-復(fù)盤-補(bǔ)樹的循環(huán)能讓同一方向上的題越面越熟而不是面完就忘。我的習(xí)慣是把每次沒答好的題變成一道新的自測題記錄問題本身和我的卡殼點(diǎn)下一次面試前快速過一遍。堅(jiān)持到第三輪時你會發(fā)現(xiàn)題庫里的題開始重復(fù)因?yàn)槟阋呀?jīng)把主枝上的知識都加固過換問法也逃不出知識樹的范圍。希望這套方法能真實(shí)幫到你祝你準(zhǔn)備路上少些翻車多些確定的收獲。本文還有配套的精品資源點(diǎn)擊獲取