前端資質越高，越不敢隨便升級框架？
上個星期五下午，臨近下班，組裡一個剛入職不久、技術熱情極高的小夥子，給我提了個極具分量的 PR。他跑到我工位旁，眼裡閃著光：老大，我把咱們那個核心中台項目的 React 從 17 直接升到 19 了，順便把 Webpack 換成了 Rsbuild。發行說明說性能提升了將近 40%，我本地跑了一下，秒開！
看著他求表揚的神情，我的心卻瞬間沉到了谷底。
我點開 package.json 的 diff，好家伙，紅綠相間的變動多達七十多處。除了 React 自身的跨代大版本，連帶著狀態管理、路由、甚至底下好幾個用來處理複雜 Excel 匯出的老舊外掛，全被強行 npm update 到了最新版。
我深吸了一口氣，默默把他的 PR 關了，並告訴他：本地跑通不算通。這個合併如果今天發到線上，明晚咱們整個組大概率都要在 P0 故障復盤會上做檢討。😖
很多年輕前端可能覺得我太保守，甚至有點老頑固。技術社群裡天天都在吹 Vue 3.x 又出了什麼革命性宏，React 19 的 Server Components 有多顛覆，Vite 又把構建速度壓縮了多少毫秒等等。
在他們眼裡，升級框架就像給手機系統點一下更新那麼簡單，不僅能提效，寫進履歷裡還能多一句──主導專案底層技術棧升級。
但在前端領域摸爬滾打了很多年、背過無數次線上事故的鍋之後，我慢慢明白了一個極其骨感的現實告訴你：前端資質越高，越不敢隨便升級框架。
升級其實沒那麼簡單
年輕時總有一種錯覺，以為升級框架就是改一下 package.json 裡的版本號，然後順著終端裡的 warning 把廢棄的 API 替換掉就完事了。
但真實的業務工程，是一個由無數個第三方套件、內部包、魔改元件和歷史妥協交織而成的巨大複雜度。
就拿上面那個小夥子強升 React 19 來說。他只看到了 React 19 把 forwardRef 廢棄了，直接把 ref 當 prop 傳就行，程式碼看起來確實優雅了。
但他沒看到的是，咱們專案裡深埋著一個 4 年前離職前輩寫的、極其複雜的虛擬滾動表格元件。當年為了在舊版本裡拿到底層 DOM，前輩用了極其 Hack 的方式去代理 ref：
// 離職前輩留下的祖傳程式碼
// 強行攔截並劫持了內部的 ref 實例，用來做複雜的聚焦與按鍵接管
const ComplexTable = React.forwardRef((props, ref) => {
const internalRef = useRef();
useImperativeHandle(ref, () => ({
forceScroll: (y) => {
// 依賴了早期版本某 UI 庫極其脆弱的內部結構
internalRef.current.querySelector('.ant-table-body').scrollTop = y;
},
// ... 其他 20 個不知道哪裡會呼叫的方法
}));
return <Table ref={internalRef} {...props} />;
});當你興沖沖地把大版本一升，底層的渲染時機變了，或者舊版 UI 庫的 DOM 結構因為不相容而錯位了。本地跑的時候，頁面確實渲染出來了。
但等到下週一，財務部門的同事在處理每個月一萬條資料的薪資表，習慣性地按下 Enter 想要讓表格自動滾到下一列時──整個頁面直接白屏崩潰😢。
這種深水區的依賴斷裂，TypeScript 無法檢查出來，E2E 測試如果沒有覆蓋到這一步也抓不到。最後買單的，就是簽字同意合入程式碼的技術負責人。
牽一髮而動全身。在沒有 100% 自動化測試覆蓋率的團隊裡，升級底層框架不叫重構，那叫排雷 🤷♂️。
技術自嗨？
很多工程師在談論框架升級時，往往會陷入一種技術自嗨的盲區。
你看，新的打包工具讓首屏渲染快了 0.5 秒！
確實很棒。但然後呢？
站在業務視角的邏輯是極其冰冷的：如果一個系統目前運行穩定，沒有遇到致命的效能瓶頸，也沒有阻礙新需求的迭代，那麼動它的底層，就是典型的 ROI（投資回報率）倒掛。
你花了兩週時間解決各種相依衝突，把 Vue 2 強行拔高到 Vue 3，把 Options API 費盡心力地重構成 Composition API。
如果升級成功了呢，業務側毫無感知，產品經理不會多給你發一毛錢獎金，老闆甚至覺得你這兩週業務產出為零 😖。
升級失敗了（或者帶入了暗病）：阻斷了核心業務流程，造成客戶流失，你就是那個沒事找事、搞出 P0 事故的千古罪人。
這不是叫你放棄進步，而是工程學裡一條極其重要的鐵律：If it ain't broke, don't fix it.（只要沒壞，就別瞎修。）
我們寫程式是為了解決業務問題，而不是為了滿足自己對時髦技術的熱愛。把屎山程式碼翻新成現代化技術棧，它依舊可能是一座邏輯混亂的屎山，只不過現在是一座編譯速度更快的屎山罷了 😒。
什麼時候才該升？
那難道我們就永遠守著老舊的版本，在歷史包袱裡等死嗎？當然不是。
高級前端和初級前端的區別就在於：初級前端為了「新」而升級，高級前端為了解決痛點而升級。
遇到以下三種情況，哪怕風險再大，我也一定帶著團隊往上升：
- 如果觸及了不可逾越的效能天花板。 比如舊版框架的 Virtual DOM 演算法在十萬級資料渲染時已經徹底鎖死主執行緒，而新版的並發特性或細粒度更新能從底層解決這個問題。
- 安全漏洞與 LTS（長期支援）結束。 底層相依被掃出高危漏洞，且官方不再為舊版本提供補丁，如果不升，就過不了公司的內部安全紅線。
- 生態徹底斷裂。 現有的技術棧已經古老到找不到能相容的周邊套件了，新來的工程師看這碼像看甲骨文，維護成本已經遠超升級成本。
而且，真正老道的升級，絕不是開個新分支一把梭。那是細緻入微的相依盤點、是灰度發佈、是雙軌運行、是哪怕天塌下來也能在 5 分鐘內切回舊代碼的降級預案。
前幾天我在社群看到一句話，深以為然：每一個看似極其保守的技術決策背後，都站著一個曾經被線上 Bug 毒打得死去活來的靈魂 😁。
所以，當你的組長拒絕你那份華麗的底層升級改造方案時，別急著在心裡罵他老土。他不是不懂新技術，他只是比你更懂那條在深夜裡突然響起的線上警報簡訊，有多麼讓人絕望 😒。
對於一線開發者來說，關注前沿技術、保持對框架底層演進的好奇心，絕對是好事。它能保持你的敏銳度，讓你在做新專案時擁有更好的技術選型視野。
但在一個沉澱了無數業務邏輯的歷史工程面前，請保持謹慎。
真正的技術大佬，不是那個天天在專案裡倒騰最新框架的極客。而是那個哪怕手握一大把老舊框架，也能穩穩當當把複雜的業務需求切得明明白白，讓系統穩如老狗的架構師。
对此大家怎麼看？
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
