昨天有位同學問我項目開發時進行技術選型的問題，比如：

• 我應該使用 Vue 還是 React？
• 圖表庫應該使用 ECharts 還是 Antv？
• UI 庫應該使用 Element 還是 AntD？

這個問題其實蠻重要，但是在很多同學的實際工作中，大家往往陷入了“工具崇拜”的怪圈。

我們總是試圖尋找一個“完美”的框架來解決所有問題，卻忽略了選型背后的本質：資源匹配、團隊基因與業務場景。

所以，今天咱們就針對前端技術選型方案的問題，把視角拉高，不談 API，只談技術場景化，聊聊那些 90% 的同學都可能會犯選型誤區～～

1.沉迷“簡歷驅動開發”

現在有一種現象非常有意思。

很多開發者會極力推薦某個冷門或極新的框架。常用的理由通常是“性能吊打 XXXX ” 或 “理念先進～”。

但真實情況可能是：他們想在簡歷上多寫一個亮點，或者僅僅是想要吸引一些眼球。

因此，我們在開發時，就需要盡量分辨這種情況。

我們要知道：技術選型必須服務于業務。當團隊引入一個新技術時，必須滿足兩個前提：

• 它能解決當前無法解決的痛點嗎？
• 團隊其他人能低成本接手嗎？

如果答案是否定的，那么就需要特別慎重了。

2.迷信 GitHub Star 數

很多同學在選擇一個庫的時候，只會去看 Github 上的 Star，覺得只要 Star 很高，那么就穩了。

但是，我們需要知道的是：Star 數只能代表“關注度”或“營銷能力”，并不代表生產環境的穩定性。很多高 Star 項目可能文檔缺失、Bug 堆積，甚至是一個為了 KPI 而生的爛尾項目！

比如 weex 背景、團隊、錢 都不缺，但就是爛尾了～～

圖片

因此，我們在選型時就不能只看  Star 數，還需要關注：

• Issue 關閉率與響應速度：維護者是否活躍？
• NPM 周下載量：真實用戶到底有多少？
• 更新周期： 項目上次版本更新時間是什么時候？

3.關注項目生態

很多大型框架（Vue 或者 React），我們除了要關注核心庫（Core）的輕量和高性能之外，還需要關注項目的周邊生態。

因為，咱們寫項目，不是只寫 Hello World。路由管理、狀態管理、UI 組件庫、SSR 方案、測試工具、IDE 插件……這些配套設施才是決定開發效率的關鍵。

如果你選擇了一個小眾的框架，那么就意味著你可能需要：自己手寫日期選擇器、自己造富文本編輯器的輪子。

因此，永遠不要為了所謂的 5% 的核心性能提升，去犧牲 50% 的開發生態便利。

4.關注后續可維護性

特別是團隊的大型項目開發，核心的功能往往是有部分核心團隊成員維護的。

那么當核心人員離職后，HR 發現市面上根本招不到懂這個技術棧的人，或者即使招到了，新人上手周期也非常長，那么就麻煩了。

因此，技術選型 越大眾，人才流動性越好，則越有利于后續的維護。

5.不要把 demo 當成業務性能

很多文章或者新的框架在進行宣傳時，都會宣傳：比 XXX 快 30% 以上。

但是，其實在 99% 的業務場景中（CRUD、后臺管理、簡單 H5），框架層面的性能差異是可以被忽略不計的。

因為，導致頁面卡頓的元兇，通常是爛代碼、大圖片和不合理的請求串行，而不是框架本身。

所以，除非你在做即時通訊、即時渲染或超大數據可視化的項目，否則開發體驗（DX）的重要性遠大于運行時性能。 如果一個框架能讓你少寫 30% 的代碼，那它帶來的價值通常高于它快了 30 毫秒。

6.不要高估團隊的“抽象能力”

很多同學會覺得項目開發靈活度非常重要，因此會選擇一個極度靈活、甚至沒有約束的框架。

但是，咱們需要知道，項目開發千人千面。同一個項目里，張三寫的是函數式，李四寫的是類組件，王五搞了一套自己的 DSL。半年后，代碼就變成了不可維護的“屎山”了。

注意：這并不意味著不需要靈活，不要從一個極端走到另一個極端。

因此，特別是中大型的團隊，我們更需要注意 約束 + 自由 的平衡。不要過度自由，也不要過度約束

7.將“框架”與“架構”混為一談

框架 和 架構 是兩個完全不同的概念。

如果你認為換個框架，代碼就清晰了，Bug 就沒了，那么就離了大譜了。

比如：如果你在 Vue2 里寫出了高耦合的代碼，換到 Vue3 或 React 里，你依然會寫出一樣爛的代碼。并沒有什么區別。

我們需要知道，框架解決的是視圖層（View）的問題，而架構解決的是邏輯層與數據流的問題。

因此，不要指望通過切換框架來償還技術債務。如果業務邏輯沒有解耦，換框架只會帶來漫長的重構期和新的 Bug。

8.忽視后端架構的“兼容性”

這個不太好理解，咱們舉個例子：

比如：前端自顧自嗨選了最新的 CSR（客戶端渲染）框架，結果后端是老舊的 Java/PHP 直出架構，或者業務強依賴 SEO。

那么，后期為了湊 SEO，不得不引入復雜的 SSR 中間層，甚至要把整個架構推倒重來。這就會非常麻煩了。

反之，針對后端也是一樣的。

我們需要知道，現在無論是前端還是后端，都早不是技術孤島了。在進行任何的技術選型時都必須要考慮前后端的互相配合的問題。

9.盲目追求“最新版”

這個問題很多同學會特別的嚴重，最典型的就是 vite 了。

我記得 vite 6 剛發布的時候，很多同學都去使用最新版了。結果出現各種各樣奇奇怪怪的 bug。

如果是學習那么還好，但是如果是企業項目，那么就會非常麻煩了。

在企業級應用中，LTS（長期支持版） 永遠是首選。做一個“早期采用者”是需要付出血的代價的。除非新特性解決了你無法繞過的致命問題，否則請讓子彈先飛一會兒～

10.只看上限，不看下限

比如：

React 的 hooks 雖然強大，但心智負擔重，很容易寫出閉包陷阱及性能損耗；相比之下，Vue 的模版語法限制了開的發揮，但也兜住了代碼質量的下限。選擇一個即便初級工程師也不容易把代碼寫崩的框架，往往更安全。

我們需要知道，一個團隊的技術有好有壞，有強的有普通的，這是非常正常的。很多所謂的 最佳時間方案在大神手里如魚得水，但是在很多普通開發者手中寫起來就特別容易屎山了。

因此，咱們在做技術選型時，就不能只看這個框架在最佳實踐下有多強，更要看在最差的開發者手里，它能有多爛。