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