「舊的不如新的」是最常見的誤解
每隔幾年就會有人宣告某個框架死了。Express 在 Fastify / Hono 出來後「死了」，Django 在 FastAPI 出來後「死了」，Spring 在 Micronaut / Quarkus 出來後「死了」。
這些宣告都沒發生。
不是因為工程師不願意嘗試新東西，而是技術選型不是「功能比較表」——它是在特定約束條件下的最佳選擇。換框架的決定要算上遷移成本、招募市場、生態依賴、既有系統規模，這些都不會因為有個更快的新框架就歸零。
生態慣性：npm 上 90% 的 middleware 都是 Express 寫的
Express 的 middleware 生態是它最難被取代的護城河。
你需要的幾乎任何功能——OAuth、file upload、websocket、rate limit、caching、i18n——npm 上都有一個 express-xxx 的套件，而且通常有多個選擇可以比較。這些套件的 API 設計都假設你在用 Express（(req, res, next) 的 middleware signature）。
換成 Fastify 或 Hono，你要評估每個套件是否有對應版本、自己包裝 compatibility layer、或是重寫。這個評估本身就要時間，更別說真正動手遷移。
Django 也一樣。Django REST Framework、Celery、Channels、django-allauth——這個生態的深度和廣度是 10 年以上累積的，新框架沒辦法在幾年內複製。
生態不只是套件數量——是整個生態上的知識庫：Stack Overflow 的問答、Medium 的文章、GitHub 的範例、公司內部的技術文件，全部都在假設你用 Express 或 Django。
AI 發達了，為什麼沒有降低這個慣性？
一個很自然的問題：AI coding assistant 這麼強，工程師應該可以快速學新框架，生態慣性應該被打破才對。
理論上對，實際上有幾個 AI 解不了的問題：
- Mental model 的切換：AI 能幫你翻譯語法（Express route 換成 NestJS Controller），但 debug 時需要的是「這個行為是 Spring AOP proxy 造成的」這種理解——AI 給你 code，不給你理解
- 生態品質不平等：AI 能幫你生成 Elysia 的 middleware，但那段 code 不是 battle-tested 的，而成熟的 Express middleware 背後有多年的 bug report 和 fix
- 招募問題 AI 解不了：即使 AI 讓你一個人能用 Hono 開發，你還是要面試和訓練新進工程師
生態慣性是集體認知的慣性，不是個人學習效率的問題。
招募市場：熟 Express 的工程師比熟 Fastify 的多 10 倍
技術選型不只影響你今天寫的 code，也影響你六個月後怎麼招人。
「Express + TypeScript」是 Node.js 後端工程師的基本技能，幾乎每個有工作經驗的 Node.js 工程師都用過。「Elysia」或「Hono」2026 年還是相對少數人的選擇。
這不是貶低新框架的能力——而是招募的現實。如果你的核心系統用了 Elysia，你在招募後端工程師時要篩掉的比例就更高，或是必須花更多 onboarding 時間。
對新創公司這個代價可能值得（效能、開發體驗的優勢），對需要快速擴張工程團隊的中大型公司，這個代價要很認真評估。
Spring 在 JVM 生態的狀況更明顯——全球大量 Java / Kotlin 後端工程師的預設工具就是 Spring Boot。Micronaut 和 Quarkus 解了 Spring 的冷啟動問題，但它們的人才市場規模仍然比 Spring 小得多。
既有系統成本：動一個穩定系統需要很強的理由
大部分公司的後端系統不是新的——它們已經跑了 3 年、5 年、10 年。
一個跑在 Express 4 上的電商 API，每天處理幾萬筆訂單，系統是穩定的，業務是跑的，工程師熟悉這個 codebase。這時候「改成 Fastify，效能提升 30%」這件事需要非常認真的 cost-benefit 分析：
- 遷移要多少工人週？
- 遷移期間有多少不可預期的 regression？
- 業務要暫停接什麼嗎？
- 30% 效能提升對你的業務有多少具體收益？
大部分情況下，這個帳算下來不划算——不是因為 30% 不好，而是穩定的系統有比效能更高的優先事項。
Django 的 ORM 是同步的，有效能上限。FastAPI 的 async ORM 在高並發下確實贏。但如果你的 Django 系統撐住了你的業務，遷移的工是確定要花的，而「高並發問題」還沒真的發生——大部分 CTO 不會批這筆遷移預算。
「無聊但可靠」有它的商業價值
工程師社群容易低估「無聊」的價值。
Express 很無聊——API 設計老、沒有型別安全、middleware 寫法手工。但它：
- 文件完整
- 除錯 Stack Overflow 直接搜得到
- 所有工程師都看得懂
- 出問題時 root cause 不難找
這些特性在大型系統的長期維護中非常值錢。一個用了很多 magic 的框架，出問題時要先理解框架本身的魔法才能開始 debug，這個隱性成本在長期累積是很可觀的。
Spring Boot 的 annotation magic（@Autowired、@Transactional、@EnableCaching）讓你寫很少程式碼就有複雜的功能，但當 transaction 的行為不如預期，你必須知道 Spring 的 proxy 機制才能理解為什麼——這個學習成本是一次性的，但它很高。
「無聊但可靠」的框架，長期維護成本是可預期的。這對跑在 production 上要支撐業務的系統，是真實的競爭優勢。
什麼情況才值得換
這不是說永遠不換。有幾個情況換框架的 ROI 是正的：
新專案：新專案沒有遷移成本，直接用最適合場景的框架。新 Python API 專案選 FastAPI 而不是 Django 幾乎是 no-brainer，除非你需要 admin panel。
效能真的成為瓶頸：不是「測了比較快」，而是現在的系統有明確的效能問題影響業務。這時候換的代價才值得。
既有系統已經是負債：如果現有系統的可維護性問題已經明顯拖慢開發速度，這時候重寫的商業理由才夠強。
Team 組成改變：新組成的團隊對某個框架有更強的集體熟悉度，換框架的 onboarding 成本反而低。
技術選型是情境題，不是選擇題。Express 在 2026 還活著是正確的——只是在特定的場景下，它仍然是最合理的答案。