電商該選 Next.js 還是 Hydrogen？
若是單一 Shopify 商店，且希望緊密沿用平台工具，可優先評估 Hydrogen。若有多站點、多資料來源（CMS、ERP、自建服務），或大量非商務頁面，Next.js 可能較適合。最終仍要比較功能邊界、團隊能力與長期維運成本。
多站點、多來源、多市場，一個前端收斂。
系統各自為政
商店、官網、部落格、會員中心用四套系統，品牌體驗四分五裂。
框架綁定的顧慮
想保留未來更換商務後端的自由，不想被單一平台鎖死。
複雜整合需求
ERP、PIM、搜尋與推薦引擎各有資料來源，需要先定義清楚的整合架構。
01 · 架構彈性
靜態的快動態的準
Next.js 官方文件說明，App Router 以 React Server Components 為基礎，部分預渲染可在同一頁面組合靜態外殼與動態內容。是否採用仍要依版本支援、快取策略與頁面需求決定。
Server Components
資料可在伺服器端取得與渲染，降低部分瀏覽器端 JavaScript 負擔（Next.js 官方文件）；實際效能仍取決於資料取得、快取與第三方整合方式。
Partial Prerendering
頁面外殼可預先渲染，動態區塊再以串流補上（Next.js 官方文件），讓團隊分別設計內容載入與購物車互動。
多來源聚合
Shopify、Sanity、ERP、搜尋服務，各種資料來源在一個 API 層收斂，前台只面對一種介面。
Next.js 適合預期商務版圖會擴大的品牌。若一開始就把資料與服務邊界設計清楚，日後替換後端或增加市場時，可以減少前台重工。
我們怎麼做
App Router 架構
伺服器元件與部分預渲染，靜態的快、動態的準。
多來源資料整合
由同一個前端聚合 Shopify、Sanity、ERP 與搜尋服務的資料。
Vercel 邊緣網路
全球部署、預覽環境與 A/B 實驗基礎設施原生支援。
可攜的商務層
商務邏輯透過 API 與介面層隔離，可降低未來更換後端時的前台改動範圍。
Hydrogen 與 Next.js 的選型對照
| Shopify Hydrogen | Next.js Commerce | |
|---|---|---|
| 商務整合 | 內建官方商務元件 | 自組 API 聚合層 |
| 適合場景 | 單一商店旗艦體驗 | 多站點、多品牌矩陣 |
| 資料來源 | 以 Shopify 為中心 | 多來源同權重聚合 |
| 部署 | Oxygen（含在方案內） | Vercel 邊緣網路 |
| 更換商務後端 | 綁定 Shopify | API 抽象、可攜 |
合作流程
架構設計
資料來源盤點、渲染策略與快取設計
設計系統
跨站點共用的元件庫與品牌語言
開發實作
前端開發、API 聚合層與整合測試
上線優化
Vercel 部署、監測、實驗與迭代
架構的價值，在第三個站點上線那天最清楚。
常見問題
規模不是唯一條件，更重要的是是否有明確的客製需求、內容營運責任與工程維護安排。品牌可自建團隊，也可由外部夥伴承接，但都要先定義服務範圍與交接方式。
可以，這正是 Next.js 的強項。商品與結帳走 Shopify，會員或訂閱走自建服務，前端統一聚合。
不一定。靜態預渲染與邊緣快取提供更多控制空間，但實際速度仍受頁面資料、圖片、第三方腳本與實作品質影響；我們會在 CI 中用效能預算持續檢查。
成本要看站點數量、整合深度、既有技術棧與維運方式。評估時我們會把兩種方案的建置範圍、依賴與長期成本並列比較。
