我在過去六年建立了超過400個無頭Shopify店面。其中一些在幾個月內達到100萬美元年經常性收入。其他的則是花費數季才能理清的重新平台化災難。這些結果之間的差異幾乎從不歸結於你選擇的框架——而是取決於在你寫一行代碼之前是否理解了權衡。

這份指南包含了2020年我建立第一個無頭Shopify店面時希望有人交給我的一切——當時我使用了拼湊而成的Next.js設置和舊的REST API。這是基於為DTC品牌、B2B批發商和企業Shopify Plus商家構建店面所積累的知識。其中一些會確認你已經懷疑的內容。一些則會挑戰你在Twitter上讀到的常規智慧。

讓我們開始吧。

目錄

無頭Shopify開發指南2026：Hydrogen、Next.js及更多

2026年無頭Shopify的真正含義

無頭Shopify意味著將前端表現層與Shopify後端解耦。你保留Shopify擅長的部分——庫存、訂單、付款、履行——並用與店面API通訊的自訂前端替換Liquid主題。

但這裡有大多數文章不會告訴你的事：2026年的無頭Shopify與甚至兩年前的情況完全不同。三個轉變從根本上改變了這個領域：

  1. Hydrogen 2已成熟。 Shopify基於React的框架在Oxygen（他們的託管平台）上自2023年rocky發布以來已大大穩定。它現在在幕後採用Remix並附帶合理的預設值。

  2. 店面API達到2025-04版本。 這帶來了客戶帳戶API v2、預測搜索改進，以及——至關重要的——不需要客戶端JavaScript的伺服器端購物車操作。

  3. 結賬擴展完全取代了checkout.liquid。 自2025年8月起，所有Shopify Plus店面必須使用結賬可擴展性。不再有Liquid結賬自訂。僅此一項就促使數千家店面走向無頭架構。

我使用的心智模型：Shopify是你的商務引擎。你的前端是一個恰好從該引擎拉取數據的目的構建的界面。其間的一切都是API調用和緩存策略。

架構堆棧

2026年典型的無頭Shopify設置看起來像這樣：

┌─────────────────┐     ┌──────────────────┐     ┌─────────────────┐
│   前端應用      │────▶│  店面API          │────▶│  Shopify後端    │
│ (Hydrogen/Next) │     │  (GraphQL)        │     │  (Admin、訂單)  │
└─────────────────┘     └──────────────────┘     └─────────────────┘
        │                                                  │
        ▼                                                  ▼
┌─────────────────┐                              ┌─────────────────┐
│   無頭CMS       │                              │  結賬擴展       │
│ (Sanity/Contentful)                            │  (Shopify UI Ext)│
└─────────────────┘                              └─────────────────┘

前端通過GraphQL與店面API通訊。不屬於Shopify的內容（編輯頁面、著陸頁面、複雜的內容模型）存儲在無頭CMS中。結賬自訂通過Shopify的擴展點進行，而不是自訂標記。

店面API：你的新摯友

店面API是專為客戶面向體驗設計的公開GraphQL API。它不同於處理後端操作的Admin API。理解這一區別至關重要。

你可以做的事

query ProductPage($handle: String!) {
  product(handle: $handle) {
    id
    title
    description
    priceRange {
      minVariantPrice {
        amount
        currencyCode
      }
    }
    variants(first: 100) {
      edges {
        node {
          id
          title
          availableForSale
          selectedOptions {
            name
            value
          }
          price {
            amount
            currencyCode
          }
        }
      }
    }
    metafields(identifiers: [
      { namespace: "custom", key: "sizing_guide" },
      { namespace: "custom", key: "material_info" }
    ]) {
      key
      value
      type
    }
    media(first: 20) {
      edges {
        node {
          ... on MediaImage {
            image {
              url
              altText
              width
              height
            }
          }
          ... on Video {
            sources {
              url
              mimeType
            }
          }
        }
      }
    }
  }
}

速率限制和緩存

截至2026年，店面API允許公開訪問令牌每個店面每秒100個請求（高於2024年初的60個）。私密訪問令牌得到更高的限制。但你根本不應該達到這些限制——如果達到，你的緩存策略就有問題。

以下是我在每個項目上所做的：

  • 完整頁面緩存在CDN層級（Vercel、Cloudflare或Oxygen），採用stale-while-revalidate頭
  • 數據層緩存，產品數據的TTL為60秒，集合數據為300秒
  • 購物車操作永不緩存——每次都直接點擊API
  • 庫存檢查使用輕量級輪詢機制或webhook來使舊的庫存數據失效
// 示例：Next.js中的產品查詢緩存策略
export async function getProduct(handle: string) {
  const data = await shopifyFetch({
    query: PRODUCT_QUERY,
    variables: { handle },
    cache: 'force-cache',
    next: { revalidate: 60, tags: [`product-${handle}`] },
  });
  return data.product;
}

Hydrogen與Next.js Commerce：真實對比

這是我被最常問到的問題。老實的答案是：這取決於你的團隊、時間安排和託管偏好。但這是數據。

因素 Hydrogen 2 (Remix/Oxygen) Next.js Commerce (Vercel)
框架 Remix (React) Next.js 15 (React)
託管 Oxygen (Shopify)或自託管 Vercel、Netlify、自託管
Shopify整合 一方、深度 社群維護的啟動器
學習曲線 中等 (Remix模式) 較低 (若團隊了解Next.js)
CMS靈活性 好，但以Shopify為中心 優秀——生態系統龐大
中位數LCP(我們的數據) 0.8秒 0.7秒
中位數TTFB 120毫秒 (Oxygen) 90毫秒 (Vercel Edge)
大規模成本 Oxygen免費層慷慨 Vercel Pro $20/月，企業$$$
結賬整合 原生購物車→結賬流程 需要店面API購物車設置
生態系統插件 增長中，~200個包 龐大，10k+個包
社群規模 ~15k GitHub星 ~40k GitHub星

何時選擇Hydrogen

在以下情況下選擇Hydrogen：

  • 你的團隊熟悉Remix的loader/action模式
  • 你想要最接近原生Shopify體驗
  • 你是想要包含Oxygen託管的Shopify Plus商家
  • 你不需要大量非商務內容（博客、編輯等）

何時選擇Next.js

在以下情況下選擇Next.js：

  • 你的團隊已經發布Next.js應用
  • 你需要超越Shopify元字段的深度CMS整合
  • 你想要最大託管靈活性
  • 你正在構建除商務之外的內容豐富的品牌體驗
  • 你計劃可能在將來切換商務後端

我會直言：在過去一年建立的70%的店面中，Next.js是正確的選擇。不是因為它在技術上更優越——不一定——而是因為人才庫大5倍，生態系統對邊界情況有更多解決方案。當你的客戶市場營銷團隊想要特定的動畫庫或他們的SEO代理機構需要特定的元標籤結構時，你會在Next.js領域中更快地找到答案。

也就是說，Oxygen上的Hydrogen店面有一種部署簡單性很難超越。推送到主分支，它就上線了。無需構建配置，無需邊界函數冷啟動來調試。

無頭Shopify開發指南2026：Hydrogen、Next.js及更多 - 架構

實現低於1秒的LCP

這是橡膠與公路相遇的地方。無頭Shopify整個業務案例——實際的財務理由——都基於性能。你需要達到的數字是移動設備上低於1秒的最大內容繪製 (LCP)。

原因是這樣：LCP每改善100毫秒大約對應轉換率提升1%，根據Shopify自己的2025年性能研究。一家年營收500萬美元、LCP從2.5秒（典型的Liquid主題）降至0.9秒的店面可以預期約15%的提升。那是75萬美元的額外收入。

我們在400多個網站上的數據確認了這個範圍。無頭店面的速度比Liquid主題快60-75%，根據CrUX報告中的真實用戶核心網頁指標數據測量。

性能遊戲計劃

以下是我們如何持續實現低於1秒LCP的確切方式：

1. 伺服器渲染關鍵路徑

// Next.js應用路由——產品頁面的伺服器組件
export default async function ProductPage({ params }: { params: { handle: string } }) {
  const product = await getProduct(params.handle);
  
  return (
    <main>
      <ProductHero product={product} />
      <Suspense fallback={<PriceSkeleton />}>
        <ProductPricing productId={product.id} />
      </Suspense>
      <Suspense fallback={<ReviewsSkeleton />}>
        <ProductReviews productId={product.id} />
      </Suspense>
    </main>
  );
}

2. 積極優化圖像

Shopify的CDN支持width、height和crop參數。使用它們。不要向375px的移動視口提供2000px的英雄圖像。

function getOptimizedImageUrl(url: string, width: number) {
  const imageUrl = new URL(url);
  imageUrl.searchParams.set('width', String(width));
  imageUrl.searchParams.set('format', 'webp');
  return imageUrl.toString();
}

3. 預加載LCP圖像

<link rel="preload" as="image" href="/hero.webp" fetchpriority="high" />

4. 內聯關鍵CSS，延遲其他所有內容

我們將折疊上方的CSS保持在14KB以下（一個TCP往返）。其他所有內容異步加載。

5. 邊界側渲染

Vercel邊界函數和Oxygen的worker運行時都在邊界執行，給你全球低於100毫秒的TTFB。這是你可以提拉的單個最大性能槓桿。

6. 意圖上的預取

不要預取視口上的所有內容。在懸停/觸摸開始時預取。這會將不必要的帶寬減少約40%，同時仍然感覺即時。

結賬擴展和後Checkout.liquid時代

以下是強制許多商家採取行動的變化：自2025年8月起，Shopify在Plus店面上淘汰了checkout.liquid。如果你有自訂結賬修改——大多數Plus商家都有——你必須遷移到結賬擴展。

結賬擴展使用Shopify的UI擴展框架。你編寫在定義的擴展點（購買前、購買後、運輸、付款等）內在Shopify結賬中渲染的React類組件。

// 示例：購買後追加銷售擴展
import { useApi, reactExtension, BlockStack, Text, Button } from '@shopify/ui-extensions-react/checkout';

export default reactExtension('purchase.checkout.block.render', () => <UpsellBlock />);

function UpsellBlock() {
  const { cost, lines } = useApi();
  
  return (
    <BlockStack>
      <Text size="medium">添加配套配件？</Text>
      <Button onPress={() => { /* add to cart logic */ }}>
        新增 $19.99
      </Button>
    </BlockStack>
  );
}

要理解的關鍵事項：結賬擴展的工作方式相同，無論你是無頭還是使用Liquid主題。 你的無頭前端切換到Shopify結賬，擴展在那裡運行。這實際上是無頭方法的一個主要優勢——你的店面完全自訂，但結賬保持Shopify託管（PCI合規、由Shopify維護等）。

Shopify Plus遷移策略

將現有的Shopify Plus店面遷移到無頭是一個分階段的操作。不要一次性做完。以下是在我們的項目中效果最佳的方法：

第1階段：基礎 (第1-3週)

  • 設置前端框架 (Next.js或Hydrogen)
  • 實現店面API連接層與緩存
  • 構建設計系統/組件庫
  • 設置CI/CD管道

第2階段：核心商務 (第4-8週)

  • 產品列表頁面（集合）
  • 產品詳情頁面
  • 購物車功能
  • 搜索 (使用Shopify的預測搜索API或第三方如Algolia)
  • 通過客戶帳戶API的帳戶頁面

第3階段：內容和市場營銷 (第9-11週)

  • 非商務頁面的CMS整合
  • 博客/編輯部分
  • 用於市場營銷團隊的著陸頁面構建器
  • SEO遷移 (301重定向、網站地圖、結構化數據)

第4階段：啟動和優化 (第12-14週)

  • 性能審計和優化
  • A/B測試設置
  • 分析遷移 (GA4、伺服器端跟踪)
  • 通過功能標誌或分割測試的漸進流量遷移

總時間表：典型Shopify Plus店面12-14週。擁有複雜目錄（50k+ SKU）或大量自訂的企業店面可能需要16-20週。

100萬美元年經常性收入的閾值：無頭何時具有經濟意義

無頭不是免費的。自訂前端開發成本比安裝Liquid主題更高。持續維護需要開發人員時間。那麼數學何時有效？

根據我們的數據：100萬美元年經常性收入是無頭Shopify開始具有明確經濟意義的閾值。

以下是數學：

收入水平 預估轉換率提升 收入增益 無頭構建成本 年度持續成本 ROI時間表
50萬美元年經常性收入 10-15% 5-7.5萬美元 8-15萬美元 2.4-4.8萬美元 18-24個月
100萬美元年經常性收入 10-15% 10-15萬美元 8-15萬美元 2.4-4.8萬美元 8-14個月
300萬美元年經常性收入 10-15% 30-45萬美元 12-20萬美元 3.6-6萬美元 4-6個月
1000萬美元年經常性收入 10-15% 100-150萬美元 15-30萬美元 4.8-9.6萬美元 2-3個月

在100萬美元以下，你最好投資於在一個構建良好的Liquid主題上的轉換率優化。超過100萬美元，性能增益複利的速度足以證明投資的合理性。超過300萬美元，不采取無頭方法就會留下大量金錢。

有關無頭構建定價的詳情，請檢查我們的定價頁面——我們對項目範圍是透明的。

選擇代理機構：Naturaily、Aalpha及更多

如果你正在為無頭Shopify工作評估代理機構，以下是我對2026年這個領域的誠實評估。

Naturaily是一家波蘭的代理機構，在無頭商務中建立了良好的聲譽，特別是在Next.js和Vue Storefront中。他們在中端市場的優勢——營收1-1000萬美元、需要專業構建但不需要企業定價的品牌。他們在技術上是合格的，對Shopify店面API有良好的經驗。他們有時遇到的困難：高度自訂的B2B工作流程和多市場Shopify設置。

Aalpha是一家印度的開發公司，專注更廣泛——他們做移動應用、企業軟體和無頭商務。他們的費率顯著較低（通常比西方代理機構低40-60%），這對預算有限的項目很有吸引力。權衡是通常在項目管理開銷和設計波蘭上。如果你有強大的內部設計團隊且能夠密切管理項目，他們可以交付牢固的技術工作。

我們在Social Animal的比較方式： 我們專注於無頭網絡開發——不僅是Shopify，而是整個無頭CMS和框架工作的範圍，包括Next.js和Astro。我們的甜蜜點是需要深度技術專業知識而不需要大型代理機構開銷的品牌和公司。如果你對適配很好奇，與我們聯繫——我們會誠實地告訴你我們是否是你項目的合適商店。

因素 Social Animal Naturaily Aalpha
專業 無頭網絡 (深度) 無頭商務+網絡 全服務開發
主要框架 Next.js、Astro、Hydrogen Next.js、Vue Storefront Next.js、React Native
團隊位置 美國 波蘭 印度
典型項目範圍 $80-250K $60-200K $25-100K
Shopify Plus經驗 是 (400+無頭網站) 是 是
最佳用於 性能關鍵型店面 中端無頭商務 預算有限的構建

使用Astro和其他框架的自訂店面

以下是大多數Shopify無頭指南不會告訴你的內容：你不必使用React。

我們用Astro構建了幾個Shopify店面——特別是對於內容和編輯與商務同樣重要的品牌。Astro的島嶼架構意味著你默認發送零JavaScript，只補充交互位（購物車、產品選擇器、搜索）。

結果？LCP持續低於0.6秒。總頁面大小低於100KB。它快得不合理。

---
// Astro組件用於Shopify產品卡
import { getProduct } from '../lib/shopify';

const product = await getProduct(Astro.params.handle);
---

<article class="product-card">
  <img 
    src={product.featuredImage.url + '&width=600'}
    alt={product.featuredImage.altText}
    width="600"
    height="600"
    loading="lazy"
  />
  <h2>{product.title}</h2>
  <p class="price">${product.priceRange.minVariantPrice.amount}</p>
  
  <!-- 只有這個組件發送JavaScript -->
  <AddToCart client:visible productId={product.id} />
</article>

權衡：Astro的商務生態系統更小。你會為購物車管理、認證和搜索編寫更多自訂代碼。但如果性能是你的主要指標，你的團隊對額外工作感到舒適，這是一個合理的選擇。

常見問題

無頭Shopify對小型店面值得嗎？ 對於年經常性收入低於50萬美元的店面，通常不值得。開發和維護成本超過轉換率改進。你最好選擇一個快速、優化良好的Liquid主題，如Dawn。一旦你越過100萬美元年經常性收入，經濟學決定性地轉向無頭。

2026年無頭Shopify構建成本多少？ 根據複雜性、代理機構位置和功能範圍，預計初始構建80K-300K美元。持續維護運行2K-8K美元每月。南亞的預算代理機構可以以25K-80K美元交付，但你通常會需要更強的內部項目管理和品質保證。

我可以使用Shopify結賬與無頭店面嗎？ 是的，你應該這樣做。Shopify的結賬是PCI合規的、經過實戰測試的、並處理付款處理。你的無頭前端通過店面API創建購物車，然後重定向到Shopify的託管結賬。結賬擴展讓你在Shopify的擴展點內自訂體驗。

無頭和Liquid主題之間的性能差異是什麼？ 我們在400多個網站上的數據顯示無頭店面在核心網頁指標上比Liquid主題快60-75%。具體來說，中位數LCP從2.3-3.5秒（Liquid）下降至0.7-1.0秒（無頭）。這平均轉換為轉換率約10-15%的改進。

我應該為無頭Shopify店面使用Hydrogen或Next.js？ 如果你的團隊了解Next.js，使用Next.js。如果你從零開始，想要最集成的Shopify體驗且最少配置，Oxygen上的Hydrogen非常優秀。他們之間的性能差異可忽略——團隊專業知識和生態系統需求應該推動你的決定。

無頭我需要Shopify Plus嗎？ 在技術上，不需要。店面API在所有Shopify計劃上都可用。但實際上，大多數無頭構建受益於Plus功能：結賬擴展、指令碼、多店面設置的組織API，以及更高的API速率限制。在無頭有意義的收入水平（100萬美元+），你應該已經在Plus上了。

無頭Shopify遷移花多長時間？ 一個有經驗的團隊的典型Shopify Plus到無頭遷移花12-14週。企業店面有複雜目錄、大量自訂或多市場設置可能花16-20週。不要讓任何人告訴你這是一個4週的工作——那是你如何最終以破碎的啟動結束的。

當我變為無頭時我的Shopify應用會發生什麼？ 這是最大的痛點之一。許多Shopify應用將指令碼注入Liquid主題，這在無頭前端上不會運行。你需要評估每個應用：一些提供你可以直接整合的API、一些有無頭相容版本，以及一些將需要用自訂代碼或替代服務替換。計劃應用審計和遷移作為你的項目範圍的一部分。

我可以將Astro或其他非React框架與Shopify的店面API一起使用嗎？ 絕對可以。店面API是一個標準GraphQL API——任何可以進行HTTP請求的框架都可以使用它。我們用Astro、SvelteKit甚至原始JavaScript構建了Shopify店面。權衡是Shopify的官方工具（Hydrogen、購物車實用程序等）是基於React的，所以你會用其他框架編寫更多自訂整合代碼。