🔧 阿川の電商水電行
我為什麼說全棧正在殺死前端？
大家好，我又來了🤣。
打開2025年的招聘軟體，十個資深前端崗位，有八個在JD（職位描述）裡寫著：“有Node.js/Serverless/全棧經驗者優先”。
全棧 👉 成了我們前端工程師內卷的一種方式。仿佛你一個幹前端的，要是不懂點BFF、不會配Nginx、不聊聊K8s，你都不好意思跟人說你是資深。
我們都在拼命地去學Nest.js、學資料庫、學運維。我們看起來，變得越來越全能了。
但今天，我想潑一盆冷水🤔：
全棧正在殺死前端。
全棧到底是什麼
我們先要搞清楚，現在公司老闆們想要的全棧，到底是什麼？
他們想要的，不是一個T型人才（在一個領域是專家，同時懂其他領域）。
他們想要的是：一個能幹兩個人的（前端+後端）的活，但只需要付1.5個人的工資。
但一個人的精力，畢竟是有限的。
- 當我花了3個月，去死磕K8s的部署和Nest.js的依賴注入時，我必然沒有時間去研究新出爐的
INP性能指標該如何優化。 - 當我花了半周時間，去設計資料庫表結構和BFF接口時，我必然沒有精力去打磨那個React元件的可存取性、無障礙（a11y）和動畫細節。
我們引以為傲的前端精神，正在被全棧的廣度要求，稀釋得一乾二淨。
全棧的趨勢，正在逼迫我們，從一個能拿90分的前端專家，變成一個前後端都是及格的功能實現者。
關於前端體驗
做全棧的後果，最終由誰來買單？
是用戶。
我們來看看全棧前端主導下，最容易出現的受災現場：
1.能用就行的交互
全棧思維，是功能驅動的。
資料能從資料庫裡查出來，通過API發到前端，再用v-for渲染出來，好了，這個功能完成了😁。
至於：
- 列表的虛擬滾動做了嗎？
- 圖片的懶加載做了嗎？
- 按鈕的
loading和disabled狀態，在API請求時加了嗎？ - 頁面切換的骨架屏做了嗎？
- 弱網環境下的超時和重試邏輯寫了嗎？
- UI測試呢？
抱歉，沒時間。我還要去寫BFF層的單元測試。
2.無障礙，可存取性（a11y）
你猜一個全棧，在用 <div> 還是 <button> 來實現一個按鈕時，會思考 aria-* 屬性嗎？他會關心Tab鍵的焦點順序嗎？
根本不會。
因為可存取性這個東西，是純粹的純前端範圍，它不屬於全棧能力範圍。
3. 性能優化
當一個全棧工程師的注意力，被資料庫索引、Nginx快取、Docker鏡像大小給佔滿時，他還有多少腦容量去關心LCP、CLS、Tree Shaking、Code Splitting？
useMemo？PureComponent？能跑就行了，別搞那麼複雜。
前端，正在從用戶體驗的第一負責人，被降維成了全棧流程的最後一個環節——那個把資料顯示出來的UI就行。
一個前端的專業性
最讓我發慌的，是一種風氣的轉變。
五年前，我們團隊，會為一個如何把白屏時間再減少100ms的議題，在白板前吵一個下午。我們會為該用padding還是margin來實現間距這種像素級的細節，在CR（Code Review）裡吵架。
現在呢？
CR時，大家都在聊：你這個BFF的Controller層，不該寫業務邏輯、你這個資料庫類型定義不規範。
沒人再關心那個前端按鈕邏輯了。
全棧，正在殺死前端的專業性。它讓前端這個職業，變得不再純粹，不再專注一個領域。
我不想做全棧開發😠
聊了這麼多，我不是在販賣焦慮，也不是在抵制學習後端知識。
作為8年老前端，我現在給自己的定位是：一個T型前端工程師。
我必須是團隊裡，對瀏覽器渲染原理、JS性能優化、CSS佈局、元件化架構、可存取性理解最深的那個人。這是我的前端身份，是我的技能。
我懂Node.js，是為了能和後端吵架時，提出更合理的BFF接口設計。
我懂Docker，是為了能理解我的程式碼，是如何在CI/CD上閃退的。
我懂SQL，是為了能理解為什麼我的一個查詢，會導致查詢慢。
請大家別再神話全棧了😒。
全棧的盡頭，很可能是全廢了，這個也不精，那個也不精。
我寧願要做一個95分的前端專家，和一個95分的後端專家，讓他們強強聯手；
也不想要兩個及格的全棧工程師，最終交付一個50分的、能跑就行的垃圾程式碼💩。
歡呼大家，尊重前端這個職業的專業性。
謝謝🙌
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
