我本來想把 Angular 20、21、22 各寫一篇，列到一半自己都覺得無聊：穩定一個 API、再把另一個移出 preview，讀完根本記不住。乾脆把三版攤在一起後，方向反而突然清楚了。Angular 沒有一夜變輕，而是在很有耐心地把 Zone.js 那套隱性魔法一塊一塊換掉。
這三版的共同方向很清楚：減少依賴 Zone.js 這種隱性機制，用 Signals 表達狀態，再把表單、非同步資料、無障礙與測試工具慢慢接到同一套現代化基礎上。
Angular 20：核心反應性和 SSR 先站穩
-
Signals 的核心 API 正式穩定，signal-based input 和 query 等寫法更適合放進正式專案。
-
Incremental Hydration 與 route-level rendering 穩定，SSR、prerender、CSR 能依路由需求混用。
-
Zoneless 在 20.2 成為 stable，讓新舊專案可以開始有計畫地移除 Zone.js。
這一版像是在打地基。畫面語法沒有突然面目全非，但 Angular 如何知道狀態變了、伺服器送出的 HTML 如何接回互動，底層邏輯已經開始換軌。
Angular 21：新預設和開發工具跟上
-
Zoneless 成為新專案預設： 不必另外開啟，Angular 會透過 Signals、事件和明確 API 安排 change detection。
-
Signal Forms 實驗登場： 用 signal 保存資料、schema 描述驗證，再從資料結構產生 field tree，試著簡化過去兩套表單 API 的負擔。
-
Angular Aria 與 Vitest： 前者提供無障礙互動 primitive，後者讓測試工具更貼近現代前端生態。
-
Angular MCP： 讓 coding agent 能取得 Angular 專案與官方知識，不必只靠通用模型猜新版寫法。
Angular 22：把實驗功能推向正式使用
-
Signal Forms、Resource API、Angular Aria 穩定： 表單、非同步資料和無障礙互動不再只是預覽功能，開始成為新專案可以認真評估的選項。
-
HttpClient 預設使用 Fetch： 更貼近瀏覽器和其他 runtime 的標準網路 API，也減少對舊式 XHR 實作的依賴。
-
新服務與錯誤邊界方向：
@Service()簡化 service 宣告；@boundary、@error等模板能力則讓局部錯誤處理更接近畫面結構。
我的看法
我覺得 Angular 這三版最重要的改變，是「框架很重」這句評價需要重新拆開看。Angular 還是完整、規範多，但 Signals 和 zoneless 正在拿掉一部分過去難以觀察的魔法；完整不一定等於老舊。
對企業專案來說，漸進更新比突然再來一次 Angular 2 式斷層友善得多。代價是新舊 API 會共存一段時間，團隊要寫清楚新 component 採用哪套方式，也不要因為 Signal Forms 穩定就立刻重寫所有可正常運作的表單。新預設先用在新功能，舊程式按維護需求搬，會比較符合 Angular 原本的穩健路線。
我會在團隊文件裡畫一條很清楚的線：新元件預設 Signals 與 zoneless，舊元件沒有需求就不動；跨越兩邊時，用 adapter 把 Observable 和 Signal 的轉換集中處理。最怕的是每位工程師各自混搭，半年後同一份狀態有三種來源，反而比 Zone.js 時代更難追。
Fetch 成為預設也值得看測試環境。mock、取消請求和 interceptor 的行為要重新確認，尤其公司若有自己包 HttpClient。標準 API 是好方向，但「底層更標準」不等於既有抽象完全不用驗證。