01 · 原生佈景主題
把 Shopify 原生能力做深
以成熟佈景主題、區段、中繼欄位與精選 App 完成多數購物旅程，讓營運團隊保有最大的自主性。
更適合在
- 差異主要來自品牌、內容與商品企劃，而非自建互動模型
- 商品、價格與交易邏輯大多留在 Shopify 及既有 App
- 行銷團隊需要低依賴地更新頁面與活動
維運責任：平台承擔主要前台與結帳基礎；團隊負責佈景主題、App、內容、品質驗證與量測治理。
先驗證：先用真實內容和商品製作原型，檢查佈景主題是否真的限制核心旅程。
Theme · Hybrid · Headless
Headless 會重新分配前台責任
比較 Shopify Theme、局部 Hybrid 與完整 Headless 的體驗空間、系統邊界、營運自主、持續成本與故障責任，再決定哪一條路值得驗證。
先做六題適配判斷架構路徑
三條路都合理，前提是責任接得住
佈景主題與 Headless 各有適用邊界。差別在於哪些能力必須自訂，以及誰會長期維護。
02 · 混合式
只解耦值得獨立的旅程
保留 Shopify 原生商店，讓內容中心、活動體驗、選品工具或特定市場旅程以獨立前端運作。
更適合在
- 只有少數高價值旅程需要跨越佈景主題邊界
- 團隊想先取得架構證據，再決定是否擴大 Headless
- 需要不同發布節奏，但不想同時重建整個商店前台
維運責任：必須明確切分佈景主題、獨立前端、CMS、API、分析與跨站旅程的責任。
先驗證：選一條可量測旅程驗證資料、身份、追蹤、發布與故障邊界。
03 · Headless
把商店前台當成持續營運的產品
以 Hydrogen 或其他前端承接整體購物體驗，Shopify 維持商務核心；彈性增加，責任也同步增加。
更適合在
- 核心體驗需要跨 CMS、搜尋、會員、PIM、ERP 或自建服務
- 多市場在內容、目錄或旅程上需要長期分化
- 團隊能持續負責發布、觀測、效能、安全與事故應變
維運責任：品牌與合作團隊共同承擔前端執行環境、部署、快取、觀測、API 降級、品質驗證與營運工具。
先驗證：先驗證最高風險的資料與購物旅程，再以三年 TCO 和治理能力作決策。
決策矩陣
不只比功能，也比發布與故障責任
這是探索用比較框架，不是技術選型結論。每一格都應以真實流程、合約與系統資料驗證。
| 決策面向 | Theme | Hybrid | Headless |
|---|---|---|---|
| 體驗差異 | 在設計系統、區段與 App 區塊內完成 | 少數高價值旅程獨立 | 整體商店前台需要自訂互動與編排 |
| 內容模型 | 以 Shopify 內容與 Metaobject 為主 | 由 CMS 服務內容中心或活動頁面 | CMS、商品與市場內容共同驅動前台 |
| 系統整合 | App、Functions 與後台整合即可 | 獨立旅程聚合少數服務 | 前台持續協調多個即時資料來源 |
| 發布治理 | 佈景主題發布與 Shopify 後台 | 兩條發布線與清楚的跨站驗收 | 前端、CMS、API 與商務資料結構的版本治理 |
| 故障邊界 | 主要由平台與 App 可用性決定 | 需設計跨表面導流與局部降級 | 需自行定義快取、降級方案、可觀測性與事故責任 |
| 成本模型 | 佈景主題建置、App、維護與優化 | 原生商店加局部執行環境、CMS 與整合 | 產品團隊、執行環境、CMS、觀測、品質驗證與持續工程 |
Headless 適配判斷
先判斷要不要 Headless，再選技術
六個問題，用來比較主題、混合式與 Headless 的適配度。這是方向性判斷，不取代架構探索與總持有成本驗證。
已回答 0／6
回答全部六題後，這裡會顯示適合先做主題、混合式或 Headless 探索的方向。
總營運成本
TCO 不能只算第一次開發
價格要用真實團隊、合約與流量試算；這裡先列出不可漏掉的四組成本責任。
- 01
建置
前端、設計系統、CMS、API 層、搜尋與身分旅程的初始建置。
- 02
維運
主機、邊緣運算與快取、觀測、日誌、告警、依賴更新與安全維護。
- 03
營運
內容預覽、商品企劃、活動發布、跨市場協作與營運培訓。
- 04
變更
功能藍圖、回歸檢查、資料契約變更、實驗與事故應變。
停止條件
看到這些訊號，先不要做 Headless
- 01所有關鍵需求都能由成熟佈景主題與既有 App 穩定完成
- 02沒有明確負責人負責前端執行環境、部署、觀測與故障處理
- 03CMS 或多系統整合只是偏好，尚未形成持續的營運需求
- 04預期上線後只需偶爾改版，沒有持續產品與工程節奏
- 05尚未定義要改善的旅程、營運限制或可驗證的決策指標
決策邊界
常見問題，先回答到能做下一個決定
Headless 一定比 Shopify 佈景主題快嗎？
不一定。Headless 讓團隊控制前端渲染、資料取得與快取，但也新增執行環境、API、第三方腳本和觀測責任。實際效能取決於架構與持續治理，不能從技術名稱直接推論。
Hydrogen、Next.js 和佈景主題應該先比較哪一個？
先比較業務旅程、內容、系統、團隊與營運限制，再選實作。Hydrogen 與 Next.js 是技術路徑；原生佈景主題、混合式與 Headless 才是較接近投資與治理的第一層決策。
可以先採混合式架構，以後再改成 Headless 嗎？
可以，但必須刻意設計邊界。先選一條高價值旅程，定義身分、資料、追蹤、SEO、發布與復原方式；只有證據支持時才擴大，不把暫時方案預設成永久雙重維護。
這個比較包含正式 TCO 或架構建議嗎？
不包含。頁面與六題評估只整理方向。正式決策還要使用真實流量、工具合約、團隊成本、系統依賴、內容流程與市場需求，並記錄假設和未確認項目。
先找證據，再選架構