Jamstack在2026年已死？誠實的發展變化評估
我從 2018 年開始構建 Jamstack 網站。那時候，這個主張是無法抗拒的：將所有內容預先渲染為靜態 HTML，從 CDN 提供服務，並為動態內容添加 API。它快速、安全，而且託管成本便宜。Netlify 創造了這個術語，Gatsby 騎著炒作的浪潮，有段時間，它感覺像是網頁開發的未來。
現在是 2026 年，對話已經發生了戲劇性的轉變。Jamstack Discord 伺服器變得安靜了。Gatsby 實際上已經死了。Netlify 裁減了大量員工。然而——這是人們所忽視的部分——Jamstack 背後的想法無處不在。它們只是不再帶著標籤而已。
那麼 Jamstack 死了嗎？誠實的答案很複雜，我認為細微差別比起聳人聽聞的說法更為重要。
目錄
- Jamstack 實際上意味著什麼
- 衰退的時間表
- Jamstack 永久獲勝的地方
- Jamstack 失敗的地方
- 伺服器組件和混合渲染的興起
- Next.js App Router：Jamstack 的殺手還是它的演進？
- Astro 和靜態生成的文藝復興
- 無頭 CMS 層：比以往任何時候都更強大
- 2026 年現代架構實際上看起來是什麼樣的
- 常見問題
Jamstack 實際上意味著什麼
讓我們對定義進行精確說明，因為大量關於「Jamstack 已死」的論述都是因為人們在爭論不同的事情。
原始 Jamstack（JavaScript、API、Markup）有幾個核心原則：
- 預渲染：在構建時而非請求時生成 HTML
- 解耦：將前端與後端/CMS 分開
- CDN 優先：從邊緣提供所有內容
- API 驅動：通過 API 和無伺服器函數處理動態功能
關鍵的哲學承諾是構建時間優於請求時間。你在部署期間進行一次繁重的工作，每個訪問者都獲得緩存的結果。
這對於部落格、行銷網站、文檔和電商產品頁面效果非常好。但對於任何需要個性化、實時數據或每幾分鐘就更改一次內容的東西來說，效果很糟。
衰退的時間表
以下是 Jamstack 敘事大致如何展開的：
| 年份 | 事件 | 影響 |
|---|---|---|
| 2020 | Gatsby 籌集 2800 萬美元 C 輪融資 | Jamstack 炒作達到頂峰 |
| 2021 | Next.js 引入 ISR（增量靜態重新生成） | 模糊了靜態和動態之間的界限 |
| 2022 | React 伺服器組件被宣佈 | 範式轉向伺服器端渲染 |
| 2023 | Next.js App Router 穩定，Gatsby 使用率急劇下降 | 混合渲染成為默認值 |
| 2023 | Netlify 收購 Gatsby，然後基本上擱置它 | 「純粹」Jamstack 的象徵性終結 |
| 2024 | Astro 4.x 獲得主要關注，Vercel 推動 PPR | 靜態生成以新形式繼續存在 |
| 2025 | Next.js 15 發佈成熟的 RSC 模式 | 伺服器優先成為主流默認值 |
| 2026 | 術語「Jamstack」很少出現在工作列表或 RFP 中 | 品牌已死，原則仍然存在 |
Gatsby 的故事特別具有啟發性。在其巔峰時期，Gatsby 擁有數千個插件、龐大的社區和真實的企業採用。到 2024 年，其 npm 下載量從峰值下降了超過 80%。Netlify 的收購並沒有拯救它——這更多是一次收購加合併，悄悄地逐漸廢止。
但將 Gatsby 的衰落歸咎於「Jamstack 正在死亡」是誤解問題的實質。Gatsby 衰落是因為它有真實的技術問題：荒謬的長構建時間、複雜的數據層（無論你是否想要，GraphQL 用於一切）以及一個成為負債的插件生態系統。Next.js 搶走了 Gatsby 的午餐，不是因為靜態生成是錯誤的，而是因為 Next.js 做得更好並提供了更多的靈活性。
Jamstack 永久獲勝的地方
以下是我認為人們對「Jamstack 已死」敘事理解錯誤的地方：核心想法的勝利如此徹底，以至於我們停止注意它們了。
解耦架構是默認值
最大的 Jamstack 勝利是解耦的前端現在成為任何認真的網頁專案的常規做法。在 2018 年，你必須為將前端與 WordPress 或你的 CMS 分開而辯護。在 2026 年，問題不是「我們應該解耦嗎？」——而是「哪個無頭 CMS 和哪個前端框架？」
這是一個永久的架構轉變。沒有人會為新專案回到單體 PHP 模板（舊版本維護是另一回事）。無頭模式——無論你是否稱之為 Jamstack——都成功了。
我們在無頭 CMS 開發工作中不斷看到這一點。客戶不再問「我們應該改為無頭嗎？」。他們問哪個無頭 CMS 適合他們的內容模型。
CDN 優先交付
每個主要框架和託管平台現在都優先考慮邊緣交付。Vercel、Cloudflare、Netlify、AWS——他們都假設你的內容應該盡可能接近用戶。這在成為行業默認值之前是一個 Jamstack 原則。
基於 Git 的工作流程
你的網站從 git push 部署、經過 CI/CD，在進入生產環境前登陸預覽 URL 的想法？那在 2017 年是激進的。現在是基本要求。每個前端平台都提供這個。Jamstack 將其規範化了。
靜態生成作為一個工具（不是宗教）
SSG 沒有死。它成為了許多工具中的一個。每個主要框架——Next.js、Astro、Nuxt、SvelteKit——都支持靜態生成。區別在於它現在是一個每頁的選擇，而不是一個全有或全無的架構。
Jamstack 失敗的地方
誠實意味著也要承認真實的失敗。
構建時間是真實的問題
大型 Jamstack 網站的骯髒秘密是構建時間。我在 2021 年從事一個擁有 40,000 個產品頁面的專案。完整重建？45 分鐘。即使進行增量構建，任何架構更改都意味著重新開始。當內容編輯者必須等待 20 分鐘才能在實時網站上看到更改時，你已經失去了關於開發者體驗的論證。
Next.js 中的 ISR 和按需重新驗證是對這個問題的直接回應。他們承認預渲染所有內容在構建時不會在某一點之後擴展。
個性化總是一個黑客
Jamstack 網站在每個人都看到相同內容時效果很好。一旦你需要用戶特定的內容——登錄狀態、個性化推薦、A/B 測試、地理位置定價——你就在與架構相悖。客戶端獲取會造成佈局移位。邊緣中間件增加了複雜性。你最終會通過額外的步驟構建一個伺服器渲染應用程式。
Jamstack 中的「J」變得臃腫
Jamstack 網站上的 JavaScript 包大小失去了控制。Gatsby 網站經常為本質上是一個部落格傳輸 300-500KB 的 JavaScript。靜態 HTML 很快，但之後水合步驟會在移動設備上將主線程鎖定數秒。這是自己挖的坑。
Astro 的島嶼架構和伺服器組件都是對這個 JavaScript 臃腫問題的直接反應。
預覽和編輯體驗受到影響
習慣於 WordPress 實時預覽的內容編輯者使用 Jamstack 時會經歷一段困難的時期。你會在 CMS 中更改一個標題，觸發一個 webhook，等待構建，然後也許看到你的更改。像視覺編輯器和草稿模式這樣的工具改進了事情，但體驗永遠無法匹配傳統 CMS 開箱即用提供的體驗。
伺服器組件和混合渲染的興起
React 伺服器組件（RSC）代表了自 SPA 時代以來前端架構中最大的哲學轉變。它們在基本上與純粹的 Jamstack 思維相悖。
原因是：RSC 假設在請求時在伺服器上渲染實際上是好的。與其預先構建所有東西，你在伺服器上渲染組件，將 HTML 流式傳輸到客戶端，並為不需要交互性的組件發送零 JavaScript。
這翻轉了 Jamstack 的文本。與其「提前構建所有東西並提供靜態文件」，現在是「按需渲染，但對需要 JavaScript 的內容要聰明」。
結果不言自明。一個構建良好的 RSC 應用程式可以在匹配或超過靜態網站的首字節時間的同時處理個性化、實時數據和動態內容，無需任何 Jamstack 的解決方法。
// Next.js App Router 中的伺服器組件——不發送客戶端 JS
async function ProductPage({ params }: { params: { slug: string } }) {
const product = await getProduct(params.slug);
const reviews = await getReviews(product.id);
return (
<main>
<h1>{product.name}</h1>
<p>{product.description}</p>
{/* 此組件在伺服器上運行。零 KB 發送到瀏覽器。 */}
<ReviewsList reviews={reviews} />
{/* 只有此交互式組件發送 JavaScript */}
<AddToCartButton productId={product.id} />
</main>
);
}
心智模型比 Jamstack 等效物更簡潔，其中你會靜態生成產品頁面，然後客戶端獲取評論，然後水合購物車按鈕，為每個處理加載狀態。
Next.js App Router：Jamstack 的殺手還是它的演進？
我認為兩者都是。Next.js 沒有殺死 Jamstack——它吸收了它。
Next.js 15 在 2025 年支持你想要的每一種渲染策略：
- 靜態生成 (SSG)：在構建時渲染的頁面
- 伺服器端渲染 (SSR)：按請求渲染的頁面
- 增量靜態重新生成 (ISR)：在時間表上重新驗證的靜態頁面
- 部分預渲染 (PPR)：帶有伺服器渲染動態孔的靜態殼
- 客戶端渲染：用於純交互式組件
PPR 特別有趣。它預渲染你的頁面的靜態殼（佈局、導航、靜態內容）並為在每個請求上伺服器渲染和流式傳輸的動態內容留下孔。這就像 Jamstack 和 SSR 生了一個孩子。
// 使用 PPR，靜態部分被預渲染，動態部分流式傳輸
import { Suspense } from 'react';
export default function DashboardPage() {
return (
<main>
{/* 這是在構建時預渲染的 */}
<h1>Your Dashboard</h1>
<Navigation />
{/* 這在每個請求中動態流式傳輸 */}
<Suspense fallback={<DashboardSkeleton />}>
<PersonalizedContent />
</Suspense>
</main>
);
}
我們的 Next.js 開發實踐已經重烈轉向這些混合模式。大多數專案現在在每個頁面甚至每個組件的基礎上使用靜態和動態渲染的混合，這在純粹的 Jamstack 時代會是異端邪說。
框架級決定已經從「靜態或動態」轉移到「每一段內容需要什麼渲染策略？」這是一個更成熟的對話。
Astro 和靜態生成的文藝復興
如果你想爭論 Jamstack 還活著，Astro 是你最好的證據。
Astro 採用了 Jamstack 的最佳部分——靜態生成、最小 JavaScript、默認快速——並構建了一個修復最差部分的框架。它的島嶼架構意味著你默認發送零 JavaScript，並且只在需要的地方選擇加入交互性。
對於內容豐富的網站，Astro 的方法很難被擊敗：
- 一個典型的 Astro 部落格頁面運送 0KB 的 JavaScript，除非你明確添加交互式組件
- 構建時間很快，因為 Astro 不捆綁完整的 React 運行時
- 內容集合提供無類型安全的內容層，不需要 GraphQL 複雜性
- 你可以使用 React、Vue、Svelte 或純 HTML 組件——選擇你的偏好
---
// 這是一個 Astro 組件。它僅在構建時運行。
const posts = await getCollection('blog');
---
<html>
<body>
<h1>Blog</h1>
{posts.map(post => (
<article>
<h2><a href={`/blog/${post.slug}`}>{post.data.title}</a></h2>
<p>{post.data.excerpt}</p>
</article>
))}
<!-- 只有此島嶼運送 JavaScript -->
<SearchWidget client:load />
</body>
</html>
Astro 的伺服器島嶼（在 2024 年底引入）增加了在否則靜態頁面內具有動態伺服器渲染組件的能力——本質上從靜態優先方向到達與 Next.js PPR 類似的目的地。
我們在我們的 Astro 開發工作中越來越多地為行銷網站、文檔和內容驅動的專案尋求 Astro，其中性能是優先級，交互性需求很少。
| 功能 | Next.js (App Router) | Astro 5.x | 舊 Jamstack (Gatsby) |
|---|---|---|---|
| 默認渲染 | 伺服器 (RSC) | 靜態 (SSG) | 靜態 (SSG) |
| 發送的 JavaScript | 按組件 | 默認零 | 完整 React 運行時 |
| 構建時間 (10k 頁面) | ~3-5 分鐘 | ~1-2 分鐘 | ~15-30 分鐘 |
| 動態內容 | 原生 (RSC/SSR) | 伺服器島嶼 | 客戶端獲取 |
| 個性化 | 內置 | 中間件 + 島嶼 | 頂多是黑客 |
| CMS 集成 | 優秀 | 優秀 | 取決於插件 |
| 學習曲線 | 陡峭 (RSC 模型) | 中等 | 中等-高 |
| 最適合 | 應用程式 + 內容混合 | 內容優先網站 | 部落格（歷史上） |
無頭 CMS 層：比以往任何時候都更強大
這是讓我最難以對「Jamstack 已死」敘事進行反擊的事情：無頭 CMS 市場正在蓬勃發展。如果架構真的已死，其內容基礎設施不會蓬勃發展。
無頭 CMS 市場在 2024 年的價值約為 21 億美元，預計到 2030 年將達到 55 億美元（各種分析師估計將 CAGR 定為 20-25%）。主要參與者都在發布強勁增長：
- Contentful 繼續主導企業無頭 CMS，在 2025 年改進了可組合性功能
- Sanity 以其實時協作編輯和 GROQ 查詢語言快速增長
- Storyblok 以其視覺編輯器在利基市場中開闢了一片天地，解決了早期 Jamstack 困擾的預覽問題
- Payload CMS（開源、自託管）已經與想要完全控制的開發者獲得了認真的關注
- Hygraph（前身為 GraphCMS）繼續為 GraphQL 優先的團隊提供服務
無頭 CMS 不在乎你的前端是使用靜態生成、伺服器組件還是信鴿。它通過 API 提供結構化內容。就這麼簡單。渲染策略是你前端的問題。
這種解耦是最持久的 Jamstack 遺產。內容層和表現層分離不是一個趨勢——這是一個存活了品牌死亡的架構原則。
2026 年現代架構實際上看起來是什麼樣的
那麼，如果我們不稱之為 Jamstack，我們怎樣稱呼大多數現代網站構建的方式？我在對話中使用過「無頭混合」，雖然我不太喜歡。這個行業還沒有定居一個術語，這可能沒問題。我們不需要為好架構設置一個行銷標籤。
以下是一個典型的 2026 年專案的樣子：
內容層：一個無頭 CMS（Sanity、Contentful、Payload、Storyblok——取決於需求和預算）
前端框架：Next.js 用於任何具有應用程式類功能或複雜交互性的東西。Astro 用於內容優先的網站。SvelteKit 或 Nuxt，如果團隊有這些偏好。
渲染策略：混合。行銷頁面是靜態生成的。產品頁面使用 ISR 或 PPR。用戶儀表板使用伺服器端渲染。交互式小部件使用客戶端渲染。框架處理所有這些。
託管：邊緣優先平台。Vercel、Cloudflare Pages、Netlify 或 AWS（CloudFront + Lambda@Edge），具體取決於規模和預算。
構建流程：基於 Git 的 CI/CD，帶有預覽部署。來自 CMS 的 webhook 觸發的重新驗證。
如果你眯起眼睛，這看起來很像具有更多靈活性的 Jamstack。這正是關鍵。
在我們的無頭 CMS 開發參與中，我們幫助客戶做出的架構決定反映了這種混合現實。沒有一種適合所有的渲染策略。正確的答案取決於內容量、個性化需求、編輯工作流程要求和預算。如果你在為自己的專案權衡這些權衡，我們很樂意討論。
常見問題
Jamstack 在 2026 年死了嗎？ 品牌實際上已死——你在許多工作列表或 RFP 中不會看到「Jamstack」。但核心架構原則（解耦的前端、CDN 交付、API 驅動的內容、基於 git 的工作流程）比以往任何時候都更廣泛。它們已經被主流網頁開發吸收得非常透徹，以至於它們不需要單獨的標籤。Gatsby 特別是死了。哲學仍然存在。
什麼取代了 Jamstack？ 混合渲染框架，如 Next.js（使用 App Router 和 RSC）、Astro、Nuxt 3 和 SvelteKit，已經取代了純靜態生成方法。這些框架讓你為每個頁面甚至每個組件選擇正確的渲染策略——靜態、伺服器渲染或客戶端。無頭架構模式（解耦 CMS + 前端框架 + 邊緣託管）仍然是標準；它只是不再帶著 Jamstack 標籤。
2026 年靜態網站生成仍然相關嗎？ 絕對是。SSG 仍然是不經常更改且不需要個性化的內容的最佳選擇——部落格、文檔、行銷頁面、著陸頁面。Astro 已成為靜態優先網站的首選框架。Next.js 和 Nuxt 仍然支持 SSG 作為眾多渲染選項之一。改變的是 SSG 現在是一個在適當時選擇的工具，而不是整個架構哲學。
Gatsby 發生了什麼？ Gatsby 在 2023 年初被 Netlify 收購，並已有效停用。其最後一次有意義的更新是在 2023 年。隨著插件維護者繼續前進，社區遷移到 Next.js、Astro 和其他框架，生態系統崩潰了。Gatsby 的核心問題——過度的構建時間、強制的 GraphQL 數據層、大量的 JavaScript 包和複雜的插件系統——從未得到充分解決。
我應該在 2026 年仍然使用無頭 CMS 嗎？ 是的，無頭 CMS 平台的市場比以往任何時候都更強大。Contentful、Sanity、Storyblok、Payload CMS 等都已經成熟了很多。無頭 CMS 解耦是最持久的 Jamstack 原則。它允許你獨立選擇前端，在多個頻道中重複使用內容，並避免對單體平台的供應商鎖定。除非你構建個人部落格（markdown 文件很好），否則無頭 CMS 值得投資。
React 伺服器組件如何改變 Jamstack 等式？ RSC 根本上改變了從「在構建時預渲染」到「在請求時在伺服器上渲染」的默認值。伺服器組件在伺服器上運行，將零 JavaScript 發送到瀏覽器，並且可以直接訪問數據庫和 API。這消除了許多 Jamstack 為動態內容所需的解決方法——不再有客戶端獲取、加載動畫或佈局移位用於伺服器可以包含在初始響應中的數據。RSC 使伺服器渲染感覺與靜態生成一樣符合人體工程學。
從 Jamstack 設置遷移到 Next.js App Router 值得嗎？ 這取決於你在解決什麼問題。如果你當前的靜態設置滿足你的需求——你的內容主要是靜態的，構建速度足夠快，你不需要個性化——沒有緊迫的理由遷移。如果你在與構建時間相爭，添加日益複雜的客戶端數據獲取，或為預覽工作流程而苦惱，App Router 的混合渲染模型可能值得遷移成本。RSC 和 App Router 的學習曲線是真實的，所以在你的決定中考慮這一點。
2026 年新內容網站的最佳框架是什麼？ 對於純內容網站（部落格、文檔、行銷），Astro 很難被擊敗——默認零 JavaScript、快速構建、優秀的開發者體驗以及出色的無頭 CMS 集成。對於混合內容和應用程式功能的網站（電子商務、用戶帳戶、儀表板），Next.js 以其混合渲染選項提供了最大的靈活性。如果你的團隊更喜歡 Vue，Nuxt 3 提供了與 Next.js 類似的功能。在這三者中沒有錯誤的答案；選擇取決於你的團隊的專業知識和你的專案的具體需求。