我第一次“遇見” TypeScript 時的心聲是：這玩意兒到底是 JavaScript，還是另起爐灶的一門新語言？

查明之后，答案更像是：帶增值服務的 JavaScript。

“靜態類型！編譯期報錯！智能提示！” 當場心動：何不試試？體內的完美主義者按捺不住，于是挑了個小項目開刀，只為體驗那層“類型安全的光暈”。

三年快進。熱情被現實磨平——TypeScript，或許被過度吹捧了。對嗎？

承諾 vs. 現實

TypeScript 許下了不少好處：

• 靜態類型，在問題上線前將其攔截；
• 類型即文檔，接口自解釋更清晰；
• IDE 友好，自動補全、重構與跳轉更絲滑。

聽上去近乎理想國。然而，它修補的并非最常把應用搞崩的那類問題。

• 業務邏輯錯誤、第三方 API 的運行期“幺蛾子”、以及 異步流程纏繞——TypeScript 觸及有限，甚至無能為力。 換言之，它不是魔杖；它更像護欄：能防一些事故，但并不能代你開車。

當調研把話挑明

微軟（TypeScript 背后的東家）一再強調：最大紅利主要出現在超大型企業級工程，也就是數百名開發者共同維護同一代碼庫的場景。

更小團隊呢？收益往往有限，甚至邊際效應遞減。

再看 2023 年 State of JS 的調查：大約只有三成多（約 36%）的 JS 開發者真切地感到 TypeScript 提升了安全性。

更糟的是，不少人體驗到的“安全感”只是錯覺。

我親眼見過同事把幾小時“耗”在 any 與類型聲明上：不是補第三方缺失的類型包，就是在復雜泛型上打結。半天時間，葬在“類型體操”里——字面意義上的。

現代 JS：其實已經“夠用”

一個常被忽略的事實是：現代 JavaScript（ES6+）已經把“八成剛需”擺在你案頭：

• 箭頭函數、模塊化、解構、展開與剩余參數；
• 可選鏈與空值合并；
• Promise 與 async/await 駕馭異步流程。

再搭配 ESLint、單元測試，以及 運行期校驗（如 zod），你已經覆蓋了 90% TypeScript 吹噓的“安全面”。看個例子：

import { z } from "zod";

const userSchema = z.object({
  name: z.string(),
  age: z.number().int().positive(),
});

function greet(user) {
  const parsedUser = userSchema.parse(user);
  console.log(`Hello ${parsedUser.name}`);
}

沒有靜態類型、沒有編譯負擔，卻能在運行期把真正會讓程序跌倒的問題（例如“字符串冒充數字”）牢牢攔下。

你不需要 TypeScript，才能發現“用戶把 age 傳成了字符串”。

何時 TypeScript 得不償失

我的親歷：團隊里新同學要上手一套 TS 泛型爆炸的工程，入門曲線陡得離譜。

• 微妙的類型不匹配讓他卡了半天——運行期其實毫無影響；
• 構建時長變長、CI/CD 變慢，開發節奏被拖累；
• 工程漸漸長成了“馴服編譯器的大怪獸”。

后來，我們把項目改回 Vanilla JS，流程反而順暢。 對中小型項目而言，TypeScript 常常像是一副“黃金手銬”：

• 大家為了過編譯器，在代碼里**滿天飛地撒 any**；
• 一旦如此，初衷被自我否定——你要的“類型安全”，最后只剩一層“紙糊防護”。

TypeScript 的真正舞臺

話也不能說死。TypeScript 依然有自己的“主場”：

• 超大型企業級代碼庫（多人長期協作、模塊互鎖復雜）；
• 公共庫或框架（需要嚴謹的公開 API 合同與演進穩定性）；
• 生命周期很長的產品（重構頻繁，類型能降低“牽一發而動全身”的風險）。

但對多數團隊在做的 SaaS 應用、營銷站點、或中等體量的 SPA？它常常是“負擔多于護益”：學習成本、迭代成本與構建成本都必須算清楚。

總結

我愿意直說：“純 JS 已經足夠，甚至綽綽有余。”在大多數真實世界的工程里，現代 JS + Lint + 運行期校驗 + 單測，可以解決 90%–95% 的痛點。

• 你的代碼不會因此坍塌；
• 你的 Bug 不會因此暴增；
• 開發者每天早上也不必先與編譯器“互毆”一小時再開工。

所以，與其追逐 TypeScript 夢，不如擁抱 JavaScript 的簡潔。