前端進階這條路我觀察了很多人也帶了不少新人。有個現(xiàn)象挺有意思有些前端工作兩三年API背得滾瓜爛熟組件寫得也溜可一到線上出問題就抓瞎另一類人能力未必多廣但給他一個復(fù)雜項目拆解、定位、優(yōu)化一套組合拳下來穩(wěn)穩(wěn)當(dāng)當(dāng)。差距不在誰會的框架多而在兩個核心方向上有沒有真正沉下去。這篇文章想聊的前端進階之路Top2就是我在實戰(zhàn)和帶人過程中反復(fù)驗證過的兩個關(guān)鍵支柱框架底層機制認知以及工程化與性能體系。這兩個方向才是從會寫前端到能扛起前端的分水嶺。適合誰來讀如果你正好有兩到四年經(jīng)驗感覺日常工作已經(jīng)熟練但面對性能調(diào)優(yōu)、復(fù)雜架構(gòu)、疑難Bug時心里沒底那這篇文章大概率對你有用。我會把這兩個方向具體是什么、怎么學(xué)、怎么用以及中間踩過的坑一次講透。1. 為什么進階卡住那么多人先搞明白Top2到底指哪兩個方向先給一個反直覺的結(jié)論大部分人的進階困境不是學(xué)得不夠多而是把知識增量當(dāng)成了能力躍升。我見過很多簡歷寫著掌握Vue全家桶、熟悉React、用過TypeScript的候選人真到現(xiàn)場讓講講Vue的響應(yīng)式依賴收集過程或者React為什么需要Fiber能講清楚的不多。這不是面試刁鉆而是這些內(nèi)容直接決定了你怎么排查線上問題、怎么做性能優(yōu)化、怎么設(shè)計一個不容易崩的復(fù)雜應(yīng)用。很多人在日常業(yè)務(wù)里其實已經(jīng)撞到過這些機制的邊界比如給對象新增一個屬性視圖不更新只能this.$set或Object.assign硬解一個彈窗組件里放了一堆數(shù)據(jù)頁面莫名其妙變卡清理監(jiān)聽也沒用項目一變大首屏加載跟著變慢代碼拆分、緩存策略、構(gòu)建優(yōu)化都試了一圈收效甚微。這些問題單獨看都是小坑但深層原因分別指向框架原理和工程化體系——你如果不理解機制就只能隔靴搔癢地打補丁。所以我把框架底層認知和工程化與性能定義為進階路上最重要的兩個方向。注意這不是說HTML/CSS基礎(chǔ)、TypeScript、網(wǎng)絡(luò)協(xié)議這些不重要而是說在基礎(chǔ)之上這兩個方向能把你從業(yè)務(wù)功能的堆疊者變成系統(tǒng)問題的解決者。下面這張表是我自己帶人時常用來對齊能力階段的直接看差距在哪能力維度初級/中級階段表現(xiàn)高級階段表現(xiàn)使用框架按文檔寫組件、調(diào)API遇到怪問題就重啟或繞過理解響應(yīng)式/渲染機制能優(yōu)化更新鏈路能改造框架能力排查問題靠alert/log逐行找依賴經(jīng)驗猜借助Performance、DevTools、監(jiān)控體系快速定位根因性能意識頁面卡了先壓縮圖片、刪依賴效果隨緣從加載鏈路、運行時開銷、構(gòu)建產(chǎn)物三維度系統(tǒng)性治理工程能力能在團隊倉庫里加功能構(gòu)建配置能跑就行能設(shè)計模塊邊界、優(yōu)化構(gòu)建策略、搭建監(jiān)控與發(fā)布體系知識體系碎片化這個框架配那個庫全是點結(jié)構(gòu)化底層原理串起所有上層工具形成面看清這個差距后第二個關(guān)鍵認知是這兩個方向不是獨立的兩條路而是互為正反饋。你理解了框架的渲染機制在看構(gòu)建產(chǎn)物、做運行時性能優(yōu)化時會自然知道該從哪里下手你掌握了構(gòu)建和監(jiān)控體系反推框架運行時的那些異常表現(xiàn)時也會更快定位。所以與其東學(xué)一點西學(xué)一點不如集中火力先把這兩個支柱立起來。2. 第一支柱框架源碼級認知把會用變成懂它為什么這樣2.1 為什么這個方向最值得先突破現(xiàn)代前端開發(fā)幾乎等于基于框架開發(fā)團隊里的一切業(yè)務(wù)邏輯、狀態(tài)管理、路由方案都建構(gòu)在框架之上。這意味著一個殘酷的事實絕大多數(shù)復(fù)雜問題最終都會下沉到框架的機制層。如果你不懂機制就只能停留在某個API報錯了、查文檔、換寫法這種操作層面。拿最常見的場景舉例Vue 3里為什么用reactive定義的對象解構(gòu)之后會丟失響應(yīng)性這個問題在很多團隊群里每隔幾周就出現(xiàn)一次。不懂Proxy機制的人會把鍋甩給框架Bug懂的人一眼就明白——解構(gòu)訪問的是原始值當(dāng)然繞過了Proxy的get/set陷阱。你看同一個表面現(xiàn)象兩種認知水平給出的處理路徑完全不同。再比如React為什么函數(shù)式組件里不建議把Math.random()直接寫在渲染函數(shù)里因為每次渲染都會執(zhí)行整個組件函數(shù)這跟class組件的生命周期不同。不理解這個每次渲染重新執(zhí)行的模型你寫出來的組件可能在毫無察覺的情況下反復(fù)執(zhí)行大量計算小頁面沒感覺復(fù)雜度一上去就是災(zāi)難。所以框架源碼級認知不是讓你去讀每一行源碼而是建立對框架運行機制的清晰心智模型。有了這個模型很多寫法你是推導(dǎo)出來的而不是背出來的。2.2 Vue和React底層機制里的必考點我以兩個主流框架為例把懂機制具體化。如果你是Vue方向建議至少能吃透這三條鏈路響應(yīng)式是如何建立和失效的Vue 2的Object.defineProperty和Vue 3的Proxy在收集依賴、觸發(fā)更新上有什么本質(zhì)區(qū)別為什么Vue 3要對數(shù)組下標(biāo)賦值、新增屬性這些操作做更好的支持把這兩條鏈路畫一遍你對更新的理解就完全不同了。異步更新與nextTick為什么連續(xù)修改數(shù)據(jù)頁面不會同步更新渲染隊列是如何合并的這直接關(guān)系到你寫業(yè)務(wù)邏輯時是在修改完數(shù)據(jù)后立刻拿DOM還是等渲染結(jié)束后拿DOM。虛擬DOM和diff策略Vue的diff是在什么前提下做優(yōu)化的key到底為什么不能隨便用數(shù)組下標(biāo)這決定了你寫動態(tài)列表時能不能踩到渲染性能的雷。React方向的核心鏈路對應(yīng)為render階段與commit階段的區(qū)分render階段可能被中斷、恢復(fù)commit階段必須同步完成。Fiber架構(gòu)的核心價值就是把渲染拆成可中斷的單元這解釋了為什么某些耗時任務(wù)會阻塞交互也是理解Concurrent模式的基礎(chǔ)。狀態(tài)更新與重新渲染setState之后發(fā)生了什么為什么多次setState會批量處理函數(shù)式組件的閉包陷阱stale closure是怎么產(chǎn)生的順著每次渲染都是獨立的快照來理解Hooks的很多奇怪行為都能解釋通。Hooks設(shè)計原理為什么Hooks不能在條件語句里調(diào)用本質(zhì)上是Hooks鏈表在每次渲染時必須保持穩(wěn)定順序。理解了這一點eslint規(guī)則就不再是背誦條款。坦白講把上面這些點徹底吃透已經(jīng)超過了相當(dāng)一部分工作五六年但一直是熟練工狀態(tài)的開發(fā)者。很多人以為這些是面試題但實際它們每天都在你的項目里運行。2.3 讀源碼的正確姿勢帶著問題去讀而不是從頭啃很多人的誤區(qū)是我要把Vue源碼從頭到尾讀一遍結(jié)果讀了兩周停在初始化流程里出不來最后放棄。我的建議恰恰相反不要按順序讀要按你踩過的坑去讀。舉個我自己的例子。有個項目用Vue 2頁面里有個表格數(shù)據(jù)一多操作就卡。我一開始懷疑是渲染太多DOM導(dǎo)致的于是開始做虛擬滾動。但做完發(fā)現(xiàn)還是有點卡這才回頭去查更新鏈路——發(fā)現(xiàn)是某個深層對象被頻繁賦值每次都觸發(fā)了一大片watcher的重新計算。這個卡頓不是DOM問題是響應(yīng)式依賴的更新范圍問題。帶著這個問題去讀源碼你就不是在記憶代碼而是在驗證自己的假設(shè)。我的方法是把每個疑惑寫成問題清單然后去源碼里找答案最后用最小demo驗證。比如數(shù)組的push方法到底是怎么觸發(fā)視圖更新的父組件更新時子組件的props和slot分別是如何同步的為什么v-if和v-show在性能表現(xiàn)上差異這么大每弄清楚一個問題你對框架的手感就準(zhǔn)了一分。很多人覺得源碼難其實是沒找到跟自己的經(jīng)驗掛鉤的入口。一旦從問題切入源碼就不再是一堆抽象代碼而是原來這里是這么設(shè)計的。2.4 源碼級認知如何直接落地業(yè)務(wù)優(yōu)化框架機制學(xué)懂了不是用來面試的它是能直接產(chǎn)生業(yè)務(wù)價值的。我舉個例子某個業(yè)務(wù)列表頁用戶翻頁時總是白屏一瞬間體驗很不好。不懂原理的人可能先去優(yōu)化接口速度發(fā)現(xiàn)接口只要100毫秒壓根不慢然后懷疑DOM渲染但列表只有幾十項也不至于。最后定位到的問題是列表數(shù)據(jù)更新后觸發(fā)了全頁面大量組件的重新渲染其中嵌套的某個重型組件重重計算了很久。修復(fù)方式并不是把頁面改簡單而是把這個重型組件用memo包一層同時把數(shù)據(jù)的更新鏈路做窄——只讓真正依賴變化數(shù)據(jù)的子組件更新。整個頁面的交互流暢度立馬上了一個臺階。這就是框架底層認知的威力。它不直接給你代碼但能告訴你性能瓶頸到底在哪一層避免瞎忙。技術(shù)在迭代框架在更新但事件驅(qū)動、響應(yīng)式更新、渲染鏈路、依賴追蹤這些核心概念不會過時掌握一套換框架也只是換個語法殼。3. 第二支柱工程化與性能體系從能跑就行到穩(wěn)定高效可擴展3.1 工程化不是工具鏈而是一套系統(tǒng)思維第二個支柱我定義為工程化與性能體系。很多前端把工程化等同于會用Webpack配置或者會搭Vite項目這只是最表面的一層。真正的工程化能力是圍繞一個問題展開的系統(tǒng)性決策能力一個前端項目從代碼提交到線上穩(wěn)定運行的整個生命周期里你怎么設(shè)計它的構(gòu)建、拆分、緩存、監(jiān)控、發(fā)布、回滾拿我會用到的場景來拆解一下。項目規(guī)模上來后首屏加載慢會成為第一個被吐槽的點。工程化能力在這個問題上的體現(xiàn)不是把所有圖片壓一遍而是做一套組合治理代碼分包把基礎(chǔ)庫、業(yè)務(wù)代碼、異步路由拆開讓首屏只加載關(guān)鍵部分路由懶加載按需加載頁面配合動態(tài)import實現(xiàn)緩存策略給帶hash的靜態(tài)資源設(shè)置強緩存解決二次訪問加載慢的問題靜態(tài)資源優(yōu)化小圖轉(zhuǎn)base64/雪碧圖、字體子集化、CDN分發(fā)。你看每個手段都不算黑科技但組合在一起才叫體系。沒有這個體系感的人典型表現(xiàn)是今天弄這個明天弄那個優(yōu)化一下圖片壓縮一下JS最后效果說不清改天又是同樣的問題。我還有一個經(jīng)驗真正好的工程化設(shè)計是潤物細無聲的。開發(fā)者日常提交代碼時感知不到構(gòu)建層的存在但每次發(fā)布、回滾、擴容都順暢安全。如果哪天你發(fā)現(xiàn)團隊發(fā)版要折騰一小時、回滾靠備份、加個依賴提心吊膽那工程化欠賬已經(jīng)很明顯了。3.2 構(gòu)建工具的演進從Webpack到Vite到底該怎么選工程化必然繞不開構(gòu)建工具?，F(xiàn)在這個時間點大家基本都在Webpack和Vite之間做選擇。我的建議是不要迷信Vite一定比Webpack好它們解決的問題表面上是構(gòu)建速度實際上是不同場景下的取舍。拿一個我做過的小實驗來說明。新項目用Vite開發(fā)冷啟動幾乎秒開熱更新快到讓人忘記等待這在老Webpack項目里是不可想象的。但到了生產(chǎn)構(gòu)建這一步Vite用Rollup做打包一些大型復(fù)雜項目的構(gòu)建產(chǎn)物優(yōu)化有時候還是要仔細調(diào)。Webpack雖然開發(fā)啟動慢但生態(tài)極其成熟各種loader、plugin應(yīng)有盡有在老項目中穩(wěn)定運行了多年。維度WebpackVite開發(fā)啟動速度慢全量打包快按需啟動熱更新體驗中等大項目會延遲優(yōu)秀接近即時生產(chǎn)構(gòu)建成熟插件生態(tài)豐富基于Rollup逐漸成熟適用場景大型復(fù)雜老項目新項目、中后臺、組件庫開發(fā)學(xué)習(xí)成本較高配置靈活但復(fù)雜較低約定優(yōu)于配置我的經(jīng)驗是老項目別盲目重構(gòu)到Vite收益可能沒那么大還容易踩兼容性坑新項目優(yōu)先考慮Vite開發(fā)體驗對團隊士氣有明顯提升。至于我該不該學(xué)Webpack答案是當(dāng)然要學(xué)因為大量存量項目還在用而且理解Webpack的分包、懶加載、插件機制本來就屬于工程化基礎(chǔ)能力。構(gòu)建工具背后那套核心邏輯——模塊解析、依賴圖、chunk分割、Tree Shaking、代碼壓縮——是所有工具共通的。你把Webpack的分包策略搞明白了換到Vite只是換個配置寫法思維模型是一樣的。3.3 性能體系用指標(biāo)驅(qū)動優(yōu)化而不是憑感覺工程化里另一個大項是前端性能。很多團隊的性能優(yōu)化是事件驅(qū)動型的——用戶投訴了、老板點名了才開始攻堅優(yōu)化完又沒人管過陣子又反彈。真正負責(zé)任的做法是搭一套性能指標(biāo)體系持續(xù)監(jiān)控、持續(xù)優(yōu)化。我建議從三個核心指標(biāo)開始LCPLargest Contentful Paint頁面主要內(nèi)容出現(xiàn)在視口內(nèi)的時間衡量用戶等多久能看到有用的東西INPInteraction to Next Paint頁面響應(yīng)交互的速度衡量操作之后界面多久有反饋CLSCumulative Layout Shift頁面布局穩(wěn)定性衡量內(nèi)容會不會突然跳來跳去。這三個指標(biāo)是從真實用戶體驗里提煉出來的比單純看DOMContentLoaded或者首屏?xí)r間有指導(dǎo)意義得多。工程化地做性能治理就是先給這三個指標(biāo)搭好埋點然后在每次發(fā)版前對比數(shù)據(jù)而不是等出了問題再去翻Performance面板。我之前處理過一個首屏加載問題。項目首屏LCP在6秒以上一開始大家覺得是網(wǎng)速問題后端接口慢但我把數(shù)據(jù)埋點拉出來后發(fā)現(xiàn)真正耗時的大頭在JS執(zhí)行——一個上百KB的組件庫被打進了首屏主包雖然代碼里只用了其中兩三個組件。分包優(yōu)化后LCP直接降到1.6秒。你看沒有指標(biāo)就只能靠感覺猜有了指標(biāo)瓶頸就無所遁形。3.4 前端監(jiān)控讓線上問題主動找你工程化體系的最后一塊拼圖是監(jiān)控。說個扎心的事實很多中大型前端項目的線上錯誤是用戶先發(fā)現(xiàn)的前端團隊自己并不知道。等到有用戶反饋或者客服轉(zhuǎn)達問題已經(jīng)發(fā)酵了一段時間了。一套基本的前端監(jiān)控體系至少包含四塊JS錯誤捕獲監(jiān)聽window.onerror和unhandledrejection把報錯信息、堆棧、用戶操作路徑一起上報性能數(shù)據(jù)采集上面說的LCP/INP/CLS以及資源加載時長、請求耗時接口狀態(tài)監(jiān)控前端發(fā)起的關(guān)鍵請求成功率、耗時分布方便區(qū)分前端問題還是后端問題SourceMap上傳線上的壓縮混淆代碼能映射回源碼報錯堆棧直接定位到源碼行號。有了這套東西線上出問題時你不是在沒頭蒼蠅一樣翻日志而是直接打開監(jiān)控后臺看趨勢曲線、報錯堆棧、影響范圍。這個能力在團隊里非常加分——它讓你從被動接需求變成主動管質(zhì)量。我見過不少開發(fā)者明明技術(shù)不錯但因為在團隊里從不主動建設(shè)這類基礎(chǔ)設(shè)施晉升答辯時拿不出我為系統(tǒng)穩(wěn)定性做過什么的例證非?？上?。性能體系、監(jiān)控體系這些是前端進階最好的顯性成果。4. 兩大支柱協(xié)同作戰(zhàn)一次線上卡頓問題的完整排查復(fù)盤前面兩章分別講了原理和工程化但實際工作中它們是協(xié)同發(fā)力的。這一節(jié)我講一個具體案例完整復(fù)盤一次排查過程你會發(fā)現(xiàn)兩大支柱缺一不可。4.1 起點業(yè)務(wù)方反饋頁面越用越卡某公司內(nèi)部運營平臺主要給運營同學(xué)維護商品信息用頁面功能不復(fù)雜一個商品列表點擊能打開詳情面板里面有幾個表單和一組聯(lián)動選項。上線兩周后運營反饋剛打開還好但進入詳情再返回、再進另一個商品操作幾次后頁面明顯變卡最后基本沒法用。團隊最初的懷疑對象是接口——是不是后端返回的數(shù)據(jù)越來越大結(jié)果看網(wǎng)絡(luò)面板接口耗時穩(wěn)定在80到150毫秒數(shù)據(jù)量也就幾十KB完全不是瓶頸。然后又懷疑是不是DOM太多詳情面板也就十幾個表單控件不至于。問題陷入僵局。4.2 框架機制視角的介入到這一步如果只懂工程化、不懂框架機制很容易在網(wǎng)絡(luò)/資源層面繼續(xù)打轉(zhuǎn)。而如果懂框架運行原理就會主動問一個問題每一次進入詳情、修改表單、返回列表框架層面到底發(fā)生了什么我們打開Performance面板錄制了一段操作進入詳情、修改一個下拉、關(guān)閉詳情、再打開另一個商品。時間線顯示每次修改表單里的聯(lián)動項都會觸發(fā)一個耗時很長的Scripting過程超過600毫秒。這就奇怪了——表面只改了一個下拉框為什么有這么大的計算量接下來用React DevTools的Profiler去記錄渲染過程真相浮出水面詳情面板內(nèi)部的聯(lián)動邏輯在修改值時會把一整棵對象樹全部setState到全局狀態(tài)管理里而全局狀態(tài)的某個selector又訂閱了整個對象樹。于是每次改動所有依賴該狀態(tài)的組件全部重新渲染包括列表頁的每一行。關(guān)閉詳情面板時數(shù)據(jù)還在全局狀態(tài)里列表重新渲染時又要重新遍歷計算。操作次數(shù)一多整個頁面就像背著一個包袱在跑。4.3 工程化視角的補充驗證找到渲染范圍過寬這個根因后修復(fù)方向已經(jīng)很明確縮小狀態(tài)更新的影響面把聯(lián)動邏輯從全局狀態(tài)移到組件局部。但這里還藏著第二層問題——為什么Profiler里那些組件重渲染的耗時這么高這一步就要工程化視角出場了。我們把構(gòu)建產(chǎn)物拿來做分析發(fā)現(xiàn)詳情面板依賴的一個重型工具庫因為代碼里有一條import語句把整個庫引了進來而實際只用到其中很小一部分函數(shù)。Tree Shaking沒有生效導(dǎo)致這個庫的完整代碼被打進主包。結(jié)果就是不僅首屏加載變慢每次組件重渲染時相關(guān)模塊的初始化計算也在反復(fù)執(zhí)行。4.4 修復(fù)鏈路與結(jié)果最終修復(fù)做了三件事把聯(lián)動值的狀態(tài)管理下沉到詳情組件內(nèi)部全局狀態(tài)只保留商品列表的核心數(shù)據(jù)重寫那個重型工具庫的引入方式改成按需導(dǎo)入確保Tree Shaking生效給列表行組件套一層記憶化讓非相關(guān)數(shù)據(jù)變化時列表不再無腦重渲染。優(yōu)化后同樣的操作流程Scripting耗時從600毫秒降到40毫秒左右連續(xù)操作幾十分鐘不再卡頓。這個案例里如果只懂框架原理你能找到渲染鏈路過寬但未必能解釋為什么單次渲染這么重如果只懂工程化你能定位到包太大但未必能追溯到修改表單觸發(fā)全局重渲染這個根因。兩個方向同時發(fā)力才能在半小時內(nèi)閉環(huán)。復(fù)盤下來排查鏈路其實有固定路徑先看監(jiān)控/Performance確認現(xiàn)象再從框架運行機制分析數(shù)據(jù)流和渲染鏈路最后看構(gòu)建產(chǎn)物排除打包層面的放大效應(yīng)。你把這套路徑走熟了大部分性能問題都能快速鎖定方向而不是靠運氣碰。5. 進階階段的避坑清單與學(xué)習(xí)策略建議最后這部分我想把帶人過程中反復(fù)出現(xiàn)的坑和學(xué)習(xí)策略一次說清楚。這些經(jīng)驗來自大量真實案例比單純的技術(shù)點更有參考價值。5.1 五個最容易走偏的坑坑一上來就啃源碼從第一行讀到最后一行的完整閱讀法。源碼閱讀最忌諱沒有目標(biāo)。你按順序讀Vue源碼大概率在初始化流程里就耗光耐心。正確的做法是問題驅(qū)動從你實際遇到的Bug或性能問題切入找到對應(yīng)模塊去看。讀源碼是為了驗證假設(shè)、理解因果關(guān)系不是為了完成一個讀過源碼的KPI?？佣粚W(xué)框架不學(xué)工程導(dǎo)致腦子里全是運行原理但一出手就是老式開發(fā)流程。有些人講響應(yīng)式頭頭是道但你讓他設(shè)計一個前端項目的構(gòu)建流程他連chunk分包和緩存策略都說不清?？蚣軝C制解決的是運行時怎么跑工程化解決的是項目怎么管兩個都得硬?？尤趁嬖囶}代替真理解。網(wǎng)上有很多高頻原理題有人背得滾瓜爛熟但一追問你遇到的實際場景是什么就露餡。知識只有在解決過真問題后才會變成能力。我建議每學(xué)一個原理就強行問自己這個原理在我最近的項目里對應(yīng)哪個場景如果找不到就造一個場景的小Demo?？铀淖分鹦驴蚣?新工具忽視了問題本質(zhì)。今天學(xué)這個、明天追那個看起來學(xué)習(xí)曲線很陡實際知識體系是散的?？蚣軙^時但事件循環(huán)渲染調(diào)度依賴追蹤模塊化性能指標(biāo)這些底層概念不會過時。以不變應(yīng)萬變才是進階的定力?？游鍚烆^學(xué)不沉淀不復(fù)盤。很多人做了項目、踩了坑但從不記錄。等半年后再遇到同樣問題還得重新查一遍。知識如果不整理成自己的體系就一直是別人的知識。5.2 一套我在用的日常學(xué)習(xí)策略我的學(xué)習(xí)節(jié)奏是442每周4小時讀框架源碼/原理4小時做工程化相關(guān)的小實驗2小時做輸出——寫技術(shù)筆記或做一個Demo。原理和工程交替進行不會膩而且經(jīng)常有交叉收獲。具體執(zhí)行上三個習(xí)慣幫了我很多習(xí)慣一建立個人Debug日志庫。每遇到一個難排查的問題就把完整過程寫下來現(xiàn)象是什么、懷疑過什么方向、如何一步步排除、最終根因在哪。這個日志庫就是你自己的經(jīng)驗數(shù)據(jù)庫也是階段復(fù)盤的第一手素材。習(xí)慣二用最小Demo驗證框架行為。很多框架機制與其看文章不如親手試。比如想驗證key對diff的影響就寫一個循環(huán)列表分別用index和穩(wěn)定id當(dāng)key中間插入一行打開渲染計數(shù)觀察差異。親手得出的結(jié)論遠比看十篇文章牢靠。習(xí)慣三做模擬項目X式的完整練習(xí)。不要只寫功能代碼找一個小項目從零開始設(shè)計構(gòu)建方案、基礎(chǔ)架構(gòu)、錯誤監(jiān)控、性能埋點完整走一遍。目的不是功能而是把前面學(xué)的工程化技術(shù)串起來。做完后你會明顯感覺到看大型項目的視角變了。5.3 關(guān)于時間投入和階段目標(biāo)的一點建議如果你正處在進階的中期我建議你把階段目標(biāo)定成能用性能指標(biāo)描述問題能從機制層解釋問題。如果你在工作里開始被同事請教一些奇怪問題說明你的框架認知已經(jīng)開始發(fā)揮作用了。最后的最后分享一條我很贊同的經(jīng)驗把自己當(dāng)成一個問題的解決者而不是框架的使用者。同一個Bug解決者會從多個層面找根因使用者只會換個寫法碰運氣。每解決一個難題就把整個思考過程記錄下來——不僅是為了寫博客或者做分享更是逼自己把碎片經(jīng)驗變成結(jié)構(gòu)化的認知。進階這條路本質(zhì)上就是把零散的應(yīng)用經(jīng)驗提升到系統(tǒng)原理層再把系統(tǒng)原理落回更復(fù)雜的實踐場景多輪循環(huán)能力就上去了。前端這個行業(yè)變化快但核心的思考方式不會變?？蚣軙Q構(gòu)建工具會升級可懂機制、管工程這兩個基本功放到什么時候都是稀缺能力。你現(xiàn)在投入的每一分鐘都不會白費。