做了幾年 tech lead，最讓我糾結的不是寫程式碼，而是技術選型。記錄一下我的決策框架。
為什麼技術選型很難
表面原因：選項太多，各有優缺點
深層原因：評估維度不統一，隱性約束沒有被挑明
比如：
PM 說：快點，下週要上線
老闆說：用成熟技術，別出問題
團隊：能不能用我最近在學的那個新框架？
你：...
決策矩陣
我習慣用一個 5 維度矩陣來評估：
1. 團隊熟悉度（Team Familiarity）
已有經驗？學習曲線多長？
2. 成熟度（Maturity）
社群規模？Issue 響應速度？公司是否在維護？
3. 適配度（Fit）
解決的問題和我們的問題有多匹配？
4. 遷移成本（Migration Cost）
如果未來要換，代價多大？（鎖定風險）
5. 運維成本（Operational Cost）
上線後維護有多複雜？
實際打分例子（為新專案選狀態管理）：
| | Zustand | Jotai | Redux Toolkit | Valtio | | ---------- | ------- | ------ | ------------- | ------ | | 團隊熟悉度 | 3 | 1 | 4 | 1 | | 成熟度 | 4 | 3 | 5 | 3 | | 適配度 | 5 | 4 | 3 | 4 | | 遷移成本 | 5 | 4 | 3 | 4 | | 運維成本 | 5 | 4 | 3 | 4 | | 總分 | 22 | 16 | 18 | 16 |
最終選 Zustand：適配度最高，團隊有基礎，遷移容易。
幾個常見的反模式
"這個庫 GitHub Star 最多"
Star 數量不代表適合你的場景。moment.js 有 4 萬 star，但它太重了，現在大家用 dayjs 或原生 Temporal。
"這是大公司在用的"
大公司的場景不等於你的場景。他們有 1000 個工程師維護這個方案，你們有 5 個。
"新技術更先進"
最新 ≠ 最好。問題是：它解決了你現在面臨的哪個具體問題？
"先試一下再說"
"試一下"往往變成了"就這樣了"。POC 需要明確評估標準，否則很容易沉沒成本陷阱。
RFC 文件
我們團隊現在重要的技術決策都要寫 RFC（Request for Comments）：
markdown
# RFC：狀態管理方案選型
## 背景
當前專案...存在以下問題...
## 目標
- 統一狀態管理方式
- 降低樣板程式碼
- 提升 TypeScript 體驗
## 候選方案
### 方案 A：Zustand
優點：...
缺點：...
風險：...
### 方案 B：Redux Toolkit
...
## 建議方案
方案 A（Zustand），原因：...
## 決策標準
如果 [條件]，我們會重新評估。
## 影響範圍
- 需要遷移的檔案：...
- 預計工時：...
## 反對意見
@張工 認為...，回應是...
RFC 的價值不只是文件，而是：
- 強迫你想清楚
- 讓團隊有發聲機會
- 幾個月後可以查為什麼做了這個決定
不可逆決策 vs 可逆決策
貝佐斯的"單向門 vs 雙向門"理論適用於技術決策：
高可逆性（雙向門）→ 快速決策，試了不行就換
- 狀態管理庫
- UI 元件庫
- 測試框架
低可逆性（單向門）→ 慎重決策，多花時間論證
- 資料庫選型
- 前後端架構（SPA vs SSR vs MPA）
- 主程式語言/框架
- 雲服務商選擇
對"雙向門"決策不要過度分析，做決定，跑起來再說。
小結
- 技術選型用多維度矩陣，而不是"感覺最好"
- 重要決策寫 RFC，讓團隊參與，留下決策記錄
- 區分可逆和不可逆決策，不可逆的要更慎重
- 避免：以 Star 數、大公司背書、新技術光環作為主要決策依據
- 最重要的問題：這個技術解決了我們現在面臨的哪個具體問題？