Vercel 終於正面回應 Next.js 鎖定問題 — 這次的承諾可以信嗎
Vercel 的「開放」聲明:善意還是被逼出來的求生招
> Meta Shift
Next.js 16.2 在 2026 年 3 月正式發布穩定的 Adapter API,同時宣布與 OpenNext、Netlify、Cloudflare、AWS Amplify 和 Google Cloud 的合作框架。這聽起來是一個技術更新公告,但背後其實是 Vercel 面對多年以來「平台鎖定」批評的第一次正式回應。
先說為什麼這件事重要。
Next.js 目前是全球最主流的 React framework,估計有超過 600 萬個網站在使用(來源:W3Techs),幾乎定義了現代 web 開發的 DX(developer experience)。但問題在於,Next.js 的很多進階功能 — 從 Image Optimization、ISR 到最新的 Partial Prerendering — 在 Vercel 平台上跑起來就是比其他地方順,有時甚至只有 Vercel 才能完整支援。
這不是陰謀論,是商業設計。Vercel 靠著「Next.js 的最佳運行環境」這個定位,建立了相當深的護城河。問題是,這條護城河的代價是讓整個生態系的其他玩家長期卡在一個資訊不對等的位置上。
Netlify 的工程師 Philippe Serhal 說的很直白:「我們開始整理遇到的問題,很快就發現 90% 的問題根源都是同一個 — 沒有一個有文件、穩定的機制讓我們可以讀取和配置 build output。」(來源:Next.js 官方部落格)
這句話翻譯一下就是:Vercel 從來沒有正式告訴其他平台怎麼完整跑 Next.js。
Vercel 的商業模式,和這個「開放」聲明的利益關係
要理解這次的 Adapter API 公告,要先搞清楚 Vercel 怎麼賺錢。
Vercel 的收入結構是典型的 cloud PaaS 模型:免費方案吸引開發者,企業方案收大客戶的錢。據報導 Vercel 在 2024 年的 ARR 估計已超過 1 億美金,並在 2023 年完成了 1.5 億美金的 D 輪融資,估值 32 億美金(來源:TechCrunch)。客戶組成方面,個人開發者和小團隊貢獻流量,但真正的收入來源是企業客戶 — 這些客戶每年付的錢從數萬到數十萬美金不等。
但這個商業模式有個長期隱患:當你靠著「我是這個 framework 最好的部署環境」吸引企業客戶,你的競爭優勢就跟框架本身綁在一起。如果框架的社群開始反彈、或者其他平台提供了同等甚至更好的支援,這個護城河就會開始鬆動。
過去兩年就是這樣發展的。
Cloudflare Pages、Netlify、AWS Amplify 都在搶 Next.js 的部署市場。更關鍵的是,OpenNext 這個社群專案在沒有 Vercel 官方支持的情況下,硬是把 Next.js 的 build output 逆向工程拆開,讓它可以跑在其他平台上。這件事本身就是一個訊號:市場需求存在,而 Vercel 沒有主動滿足它。
所以現在的問題是:Vercel 宣布 Adapter API 是真的想「開放生態系」,還是一個更聰明的競爭策略?
我傾向後者,但這並不代表它對開發者不好。
Vercel 的算盤應該是這樣的:與其讓 OpenNext 這種社群方案持續填補空白(而且 Vercel 完全無法控制品質和方向),不如主導一個官方的 Adapter API。這樣做有幾個好處:一,把標準的定義權留在自己手上;二,讓其他平台正式納入生態系的協作框架,等於把潛在的競爭對手變成「認可的合作夥伴」;三,面對企業客戶時可以說「我們支持跨平台部署」,解除採購時的顧慮。
競爭格局:誰在贏,誰在被逼著讓步
現在的 Next.js 部署市場大概長這樣:
Vercel — 仍然是最完整的支援,feature parity 最高,但價格也最貴。企業客戶的首選,但中小團隊越來越傾向找替代方案。
Cloudflare Pages / Workers — 靠著 edge network 的優勢搶市場,加上免費方案非常大方。Cloudflare 是這次 Adapter API 合作的積極參與者,顯然想要在這個生態系裡佔一個正式的位置。
Netlify — 老牌玩家,體驗成熟,也是 OpenNext 的重要貢獻者。Philippe Serhal 的那段話說明他們長期在用不完整的資訊硬撐,現在終於有了官方支援。
AWS Amplify / Google Cloud — 大廠背書,適合已經 all-in 在各自 cloud ecosystem 的企業。能進入 Adapter API 的合作名單,對他們來說是降低 Next.js 遷移成本的重要籌碼。
OpenNext(社群) — 這次的最大贏家之一。從一個非正式的逆向工程專案,變成 Next.js 官方組織下的 verified adapter,legitimacy 直接拉滿。這對社群維護者來說是一個很大的認可。
比較特別的是這次的架構設計:Vercel 自己的 adapter 也要跑同一套 test suite,跟其他平台用一樣的標準驗證。這個設計如果真的執行,代表 Vercel 沒有辦法偷偷給自家 adapter 開後門 — 至少在公開的 test 範圍內是如此。這是這次公告裡技術誠意最高的部分。
Meta 判讀:這是 Valve 開放 Steam API 的時刻
用電競的框架來看,這是一個明顯的 Meta Shift,但不是因為技術本身有多革命,而是因為遊戲規則改了。
歷史上最接近的案例是早期 Stripe 的 API 策略。Stripe 在支付市場後進,靠著「完整的文件、清楚的 API 合約」這件事打贏了同樣技術能力的競爭對手。開發者知道他們在建立什麼、知道行為是可預期的,這個信任感本身就是商業優勢。
Vercel 現在做的事有點反過來:他們過去靠著「只有我們完整支援」建立護城河,現在要轉向「我們是這個標準的制定者和最佳實踐者」。這個轉變如果成功,護城河不是消失,而是從「資訊不對等」變成「技術領先」。後者其實更健康,也更難被複製。
但這個承諾能不能實現,取決於幾件事:Ecosystem Working Group 的運作是否真的透明;Adapter API 的 spec 是否跟上 Next.js 的 feature 發布速度(這是歷史上最大的痛點);還有 Vercel 在商業壓力下,是否仍然願意讓其他平台跑出跟自己一樣好的效果。
目前沒有公開數據能確認這些承諾的執行力,所以保守的判斷是:現在看到的是一個架構上正確的方向,但信任需要時間建立。
工程師怎麼看這件事
如果你現在在選 Next.js 的部署平台,這個消息實際上有一些短期意義。
Adapter API 穩定之後,理論上你換平台的成本會降低。這對做技術選型的人來說是一個利多 — 你不再需要因為「之後很難遷移」而在一開始就選 Vercel。Cloudflare 或 Netlify 如果在成本上有優勢,現在有更正式的理由去評估。
對於做 infra 或 platform engineering 的人,這個 Adapter API 的設計值得花時間讀一遍。它定義了一個 framework 的 build output 應該長什麼樣子:routes、prerenders、static assets、runtime targets、caching rules。這個設計思路在未來你自己搭內部 deployment pipeline 時會用得到。
至於 side project,現在選 Cloudflare Pages + Next.js 的組合風險比以前低了,如果你在意成本的話可以認真考慮。
最後一點:如果你在追 OpenNext 這個專案,它從 workaround 變成 verified adapter 的過程,是一個很經典的「社群壓力迫使商業公司讓步」的案例。這種事不常發生,但當它發生的時候,通常代表整個生態系會往更健康的方向走。
延伸閱讀
Waiting7777
WoW Arena 冠軍轉前端,用電競 meta 思維拆解技術趨勢。
相關文章
GitHub CopilotAI+5GitHub Copilot 支援 stacked sessions 了 — AI coding 正式進入 agentic 時代
從「AI coding assistant 進化成 agentic」這個方向切入,分析 stacked sessions 這個功能設計背後的意圖,以及 GitHub 在 Cursor、Windsurf 競爭壓力下的策略選擇。
2026年8月2日 · Waiting7777 · 8 分鐘閱讀
繼續閱讀 →
AIGPT+8OpenAI 想做 super app — ChatGPT 的野心到底有多大?
OpenAI 把 ChatGPT 做成 super app 這條路,跟微信、支付寶的邏輯有多像?對開發者和競爭對手的影響怎麼看。
2026年7月30日 · Waiting7777 · 6 分鐘閱讀
繼續閱讀 →
AnthropicAI+4Anthropic 第一位 Technical PM 說的「AI 鋸齒邊緣」是什麼?產品人必看
從 Dianne Penn 的視角切入「在 AI 實驗室當第一個 Technical PM 是什麼體驗」,重點放在 jagged edge 這個概念——AI 在某些地方超強、某些地方爛透了,產品人要怎麼跟這個現實共處。
2026年7月27日 · Waiting7777 · 8 分鐘閱讀
繼續閱讀 →這篇文章對你有幫助嗎?
每週一篇 — 技術趨勢背後的商業邏輯
AI 產業在變什麼、工程師該注意什麼——拆清楚寄到你的信箱。