Angular 是由 Google 專職團隊維護的開源 Web 應用框架，以 MIT 授權發布，透過 npm 安裝而不是購買。angular.dev 是它的官方文件站台。
Angular 框架有明確主張，而不是一個函式庫。路由、表單、依賴注入、HTTP、國際化、測試與建置工具鏈都作為第一方元件提供，並統一版本推進。這就是框架要求你做的交換：在「每個位置用哪個函式庫」上少一些選擇自由，換來這些位置被一致地填滿並同步升級。
開發過程是公開的。每一個 PR 與提交都能在 GitHub 上查到，團隊在那裡分診 issue，較大的變更在落地前會走公開的 RFC。當前主線是 2026 年 6 月發布的 v22。
Angular Signals 是框架的響應式原語，是一種配合編譯期最佳化的細粒度模型，而不是對整棵元件樹做變更偵測掃描。這是框架幾個版本以來一直推進的主軸，v22 把 Signal Forms、Angular Aria 與非同步反應式 API 推進到生產可用狀態，完成了這次轉向。
伺服器端渲染與靜態站台生成都受支援，並配有完整的 DOM 水合，因此應用可以先以預渲染標記交付，再在客戶端接管，而不必丟棄並重建 DOM。
Angular CLI 以 @angular/cli 套件發布在 npm 上，提供名為 ng 的執行檔，鷹架、開發、測試、部署與維護都在同一處完成。底層的建置管線建立在 Vite 與 esbuild 之上。
在專案的整個生命週期裡，有兩項 CLI 能力比其餘更重要：
Angular DevTools 與瀏覽器自帶的開發者工具並列，補上元件樹檢視器、依賴注入樹檢視與自訂效能剖析火焰圖。測試一側，Vitest 在穩定發布後成為主要測試執行器，從 Karma 遷移的工具正在推向穩定。
HTML 淨化與 trusted type 支援是內建的，針對跨站腳本與跨站請求偽造。國際化涵蓋訊息翻譯與格式化，包含 Unicode ICU 語法。這兩項都屬於框架吸收掉的關注點——否則它們會變成每個專案各自的選庫決定。
官方給出的入口不是從本機工具鏈開始的：互動式 StackBlitz 環境意味著在你想要之前不需要任何本機設定。對於評估框架的約定是否適合團隊，這把 Node 版本問題從決策的第一個小時裡挪走了。
Angular 版本支援是有時限而非無限的，因此升級是一項排期工作而不是選配項。實際順序是：對 CLI 與核心套件一起跑 ng update，讓處理常規破壞性變更的自動化程式碼轉換做掉機械部分，再把審查時間留給那些沒有遷移腳本的變更。v22 這條線的遷移指令是 ng update @angular/cli@^22 @angular/core@^22。
一次升級有多痛由兩件事決定。其一，你的專案是否還落在受支援的版本上——跨越好幾個已停止支援的大版本，意味著要按順序逐個跑遷移而不是一步到位。其二，你是否依賴了已進入棄用視窗的 API，因為它們會在某個大版本邊界上被移除。
官方給出三條路徑，按模型呼叫應該發生在哪裡來選而不是按偏好來選：伺服器端邏輯用 Genkit，客戶端呼叫用 Firebase AI Logic，或直接呼叫 Gemini API。Genkit 需要受支援的伺服器端環境，例如基於 Node 的伺服器，實務上這意味著一個帶 SSR 的全端 Angular 應用，而不是純客戶端建置。
三條路徑共有的安全規則毫不含糊：絕不要把 API 金鑰放進會隨客戶端下發的檔案，例如 environments.ts。純客戶端應用應把模型呼叫經 Firebase AI Logic 或你自己控制的代理轉發；伺服器端連線應從金鑰管理器或環境變數讀取憑證。
Angular 適合寧願繼承決定、也不願自己做決定的團隊。框架給出路由模型、表單模型、DI 容器與建置管線，並期望你使用它們。對規模大或人員流動的團隊來說，這種一致性正是價值所在；對兩個人的專案來說，它可能讀起來像一套繁文縟節。
以下情況適配良好：
以下情況適配不佳：
Angular 面向的是 Web 平台，其涵蓋範圍由兩張公開的矩陣界定，而不是靠一句籠統的相容性聲明。
瀏覽器支援依照 Baseline 的 widely available 集合來定義，而不是靠一份手工維護的版本清單。每個大版本，團隊會挑一個接近發布日的 Baseline 日期，支援 Chrome、Edge、Firefox 與 Safari 上在選定日期前 30 個月內發布的瀏覽器，目標涵蓋約 95% 的網頁使用者。v22 的 Baseline 日期是 2026-05-07。
工具鏈矩陣更嚴格，值得在升級之前而不是升級過程中核對。v22 把 TypeScript 釘在 6.0 線上，接受 Node 22.22.3、24.15.0 或 26.0.0，而 v21 落在 TypeScript 5.9 線。在同一個專案內，@angular/core 與 CLI 的版本必須一致，因為自 v7 起兩者共用大版本號。
預發布線的文件單獨發布在 next.angular.dev 上，因此評估一個尚未發布的特性不必讀著穩定版文件去猜哪裡變了。
這裡沒有價目表、沒有席次數、也沒有付費級距：框架以 MIT 授權發布，所有套件都從公開的 npm registry 安裝。倉庫授權檔案上的版權聲明寫作 2010-2026 Google LLC，@angular/core 的 npm 中繼資料同樣標註 MIT，當前發布版本為 22.1.5。
這份授權允許的範圍很寬。MIT 允許商業使用、修改、散布與私有使用，條件僅限於保留版權與授權聲明；軟體不附帶任何擔保。落到實處就是：沒有按開發者計的費用、沒有用量計量，交付一個基於它建置的產品之前也沒有商業授權需要談判。
真正留下的成本不是授權而是維護。由於大版本按公開時間表離開支援期，真實的預算科目是年度升級的工程時間，加上建置與測試套件消耗的 CI 資源。評估總成本的團隊應該給這個節奏定價，而不是假設零成本的授權等於零成本的相依。
每個大版本的支援期通常為 24 個月，拆成 12 個月的常規更新與 12 個月的長期支援，後者只承載關鍵修復與安全修補。這是一條硬邊界而非指導意見：在撰寫時，從 v2 到 v19 全部已經完全脫離支援，只剩 v22 處於常規支援，v21 與 v20 處於 LTS。
LTS 階段比「仍受支援」這個說法所暗示的要窄。只有兩類問題會被受理：新發現的安全漏洞，或自 LTS 開始之後由第三方變更（例如新瀏覽器版本）引發的回歸。在 LTS 期間發現的普通缺陷不在範圍內。
棄用走的是自己的時鐘。一個被棄用的 API 至少會活過再一個大版本，也就是不少於 12 個月，之後才成為在大版本邊界上被移除的候選——而在這個視窗內，它按 LTS 規則維護，因此即使整個發行版仍處於常規支援，它也只收到關鍵與安全修復。
v22 展示了這類工作的形狀。關於這次發布的獨立報導指出，Webpack 支援——包括較舊的 build-angular 與 ngtools 套件——已被棄用，該發行版要求 TypeScript 6 並放棄 Node 20，另有兩項需要人工處理，因為沒有提供遷移腳本。影響面最廣的變更是行為層面而非結構層面：OnPush 成為元件的預設變更偵測策略，原先的預設策略更名為 Eager，schematics 會透過顯式標註既有元件來兜底。
向後相容性是被驗證的，但不是絕對的。變更會經過單元與整合測試、公開 API 型別定義的差異比對，以及 Google 自家相依應用的測試套件——然而政策仍然保留：在關鍵安全修補等例外情形下，修復可能引入向後不相容的變更。
還有兩條較小的邊界值得直說。Polyfill 有一條寫明的天花板：它無法把老舊緩慢的瀏覽器變成現代快速的瀏覽器，而且建議的集合只涵蓋執行完整 Angular 應用所需，超出這個集合的特性可能還要再補。官方政策頁把完整節奏寫成：大約每 12 個月一個大版本，每個大版本配 4 到 6 個小版本，修補與預發布建置幾乎每週一次。目前公開來源在大版本間隔本身上並不一致——一方描述的是 12 個月的週期，另一方仍在描述 6 個月的週期——官方政策頁同時註明較長的週期是從 v22 才開始的。任何要做多年升級預算的人，都應該以政策頁而不是二手報導來確認當前節奏。
可以。框架以 MIT 授權發布，所有套件都從公開的 npm registry 安裝，該授權允許商業使用、修改與散布，條件是保留版權與授權聲明。軟體不附帶任何擔保。
一個典型大版本總共 24 個月：12 個月的常規更新加 12 個月的長期支援，後者只承載關鍵修復與安全修補。此後該版本完全離開支援範圍。
v22 處於常規支援，v21 與 v20 處於 LTS。從 v2 到 v19 全部已經完全脫離支援。
v22 把 TypeScript 釘在 6.0 線上，接受 Node 22.22.3、24.15.0 或 26.0.0。版本矩陣按發行版逐一公布，值得在開始升級之前而不是升級途中核對。
CLI 承擔了其中大部分：ng update 會執行自動化程式碼轉換來處理常規的破壞性變更。它涵蓋不了的是沒有遷移腳本的行為變更——在 v22 裡，這包括一項沒有提供遷移的路由預設值，以及 Webpack 支援的棄用。
支援依照 Baseline 的 widely available 定義：Chrome、Edge、Firefox 與 Safari 上在選定日期前 30 個月內發布的瀏覽器，目標涵蓋約 95% 的網頁使用者。每個大版本各自挑選接近發布日的 Baseline 日期。
評估階段可以。互動式 StackBlitz 環境意味著在你想要之前不需要任何本機設定，這也是官方瀏覽器內教學的入口。
按呼叫應該發生在哪裡來選路徑——伺服器端邏輯用 Genkit，客戶端呼叫用 Firebase AI Logic，或直接呼叫 Gemini API——並遵守憑證規則：絕不要把 API 金鑰放進會隨客戶端下發的檔案，例如 environments.ts。
