Drupal Commerce 何時勝過 Shopify

對大多數網路商店來說，Drupal Commerce 都是錯的答案。這並不是在批評這個專案，它十五年來的工程品質一向紮實。這只是在陳述大多數商店的樣貌：幾百個 SKU、一種貨幣、面向消費者的客戶，最後刷一次卡。對這種形態的生意而言，代管型平台在每一個重要的面向上都會勝出，爭論還沒開始就已經結束。

但確實有一小群商家，他們的帳算下來完全相反，而且這是一群利潤可觀的商家。無法用變體表格表達的可組態產品。帶有議定價目表的貿易帳戶。目錄本身就是編輯內容。由 ERP 掌握庫存與價格，網站只是一個展示面的公司。在這些生意裡，代管型平台並不便宜，它是一筆長期繳納的稅，以應用程式、變通做法以及「這裡不准動」的形式支付。

本文要說清楚那條界線究竟落在哪裡，並給出兩邊的數字。如果你讀到 Shopify 那一節時認出了自己的生意，就到此為止吧。你會省下一大筆錢，而這篇文章也就完成了它的任務。

Drupal Commerce 什麼時候會勝過 Shopify？ 當你的產品無法建模成單純的變體表格時，當不同客戶對同一個 SKU 看到不同價格時，當目錄和編輯內容本來就是同一件東西時，或者當 ERP 才是權威資料來源、商店只是它的一個檢視時。對於只用一兩種貨幣的普通消費品目錄，Shopify 三年下來更便宜，轉換率也更好。分界線是產品與定價的複雜度，而不是流量或營業額。

Drupal Commerce 究竟是什麼

Drupal Commerce 不是一套開箱即用的商店產品。它是一組疊在 Drupal 實體與欄位系統之上的實體型別，本文後面所有的結論都由這句話推導而來。

Drupal Commerce 裡的產品是一個帶 bundle 的實體，和節點完全一樣。產品變體、訂單、訂單項目、付款、促銷與商店也都是實體。它們每一個都接受任意欄位，所以一個變體可以帶上批號、證書編號、以工作日計的交期，以及一個用來計算價格的尺寸。這些都不是掛在固定結構旁邊的自訂欄位，它們本身就是結構。

可購買的東西是變體，不是產品。產品是呈現層的外殼，變體才是帶 SKU 與價格的品項，屬性負責產生可選的組合。產品型別決定產品擁有哪些欄位，變體型別決定它的變體帶哪些屬性。這套安排裡沒有任何一處假定你賣的是服飾、是實體商品，或者選項數量是固定的。

結果就是，Drupal Commerce 對你賣什麼幾乎不持任何意見。這種自由的代價是，它也幾乎不替你做任何決定，而所有這些決定總得有人來做。

Drupal Commerce 現在的位置

目前推薦的版本是 Drupal Commerce 3.3.8，於 2026 年 7 月 17 日發布，支援 Drupal 10.3 以上以及 Drupal 11。穩定版受 Drupal 安全公告政策涵蓋，這一點比聽起來重要：它代表一個被揭露的漏洞會走協調發布流程，而不是變成一則 GitHub issue。

Drupal Commerce 專案頁面回報有 35,870 個網站正在使用這個模組。Commerce 3.0.0 是 3.x 系列的第一個穩定版，2025 年 1 月發布，同時放棄了對 Drupal 9 的支援。圍繞它的是一個不算大的貢獻模組生態：Commerce Shipping 目前是 3.0.3，安裝量約 15,200，而下文提到的那些專門模組都只在數千的量級。

把它和 WooCommerce 比一比。後者回報的有效安裝數超過 700 萬次，並要求 WordPress 6.9 與 PHP 7.4 或更新版本。以安裝規模來看，Drupal Commerce 大約小 200 倍。

這個比例是本文最重要的一個數字，而它是警告，不是誇耀。它代表「這件事是不是已經有現成模組了」這個問題，答案經常是沒有。

為 Shopify 說句公道話

Shopify 解決了四個足以拖垮大多數自架商店的問題，而且在你寫下第一行程式碼之前就已經解決了。

它是代管的，於是可用性、擴充與修補不再是你的預算科目。它替你處理卡片資料，於是你要承擔的法遵範圍只有原本的一小部分。它的結帳流程經過任何一家服務商都無法重現的真實交易量檢驗，而在那種規模上，微小的轉換差異比任何架構偏好都更值錢。它的應用程式生態又代表大部分需求以訂閱的形式到來，而不是以專案的形式到來。

對於只有幾千個 SKU、一兩種貨幣、沒有議價的消費品目錄，本文後面描述的所有優勢都用不上。你只是在付錢請人重做一遍你現在每月花 65 英鎊就能得到的東西，而且做得更差。

把話說明白，因為本文其餘部分都在論證相反的方向：大多數商店應該止步於 Shopify。如果你的店就是其中之一，我們那篇Shopify 與客製化電商開發的比較比本頁更詳細地討論了這個決定。

Shopify 在英國要花多少錢

Shopify 以英鎊公布英國價格，所以不需要換算。依照 2026 年 9 月的 Shopify 價格頁，Basic 按月付費每月 25 英鎊、按年付費 19 英鎊，Grow 是 65 英鎊或 49 英鎊，Advanced 是 344 英鎊或 259 英鎊，Plus 從每月 1,800 英鎊起跳。POS Pro 每個門市每月再加 69 英鎊。

比訂閱費更要緊的是刷卡費率。透過 Shopify Payments 的線上刷卡費率在 Basic 是 2% 加 25 便士，在 Grow 是 1.7% 加 25 便士，在 Advanced 是 1.5% 加 25 便士。大多數人漏掉的那一項是第三方金流商費用，只要你用 Shopify Payments 以外的金流閘道就會被收取：Basic 收 2%、Grow 收 1%、Advanced 收 0.6%、Plus 收 0.2%。

這筆費用是疊加在金流閘道本身費率之上的。一家年營業額 100 萬英鎊、使用 Advanced 並接了外部收單機構的商店，光是這筆第三方費用每年就是 6,000 英鎊，三年 18,000 英鎊，只為了不使用 Shopify Payments。

Shopify 在哪裡不夠用了

這些上限是公開的，而且很具體。Shopify 關於新增變體的文件寫明，每個產品最多三個選項、最多 2,048 個變體，超過任何一項都需要第三方應用程式，或者需要用佈景主題程式碼去擷取行項目屬性。

最先卡住你的是三個選項這條線。一扇窗、一塊印刷面板、一組訂製百葉窗或一台組態好的機器，通常有六到八個彼此獨立的選擇項，而一旦超過三個，平台就不再為你的產品建模，而是開始近似它。

第二道牆是結帳。Shopify 針對資訊、運送與付款步驟的結帳 UI 擴充功能只在 Plus 方案上可用。在 Plus 以下你可以替結帳頁做品牌化，但沒辦法往裡面插入邏輯，這就排除了配送時段選擇、貿易授信檢查，以及必須在那個時間點發生的法遵攔截。

第三道牆是累積。每一處缺口都用應用程式去補，每一個應用程式都是一筆月費和一條升級相依關係，裝了二十個應用程式的商店所面對的維護問題，看起來和它當初想逃離的那個驚人地相似。

WooCommerce 的長處，以及它吃力的地方

WooCommerce 值得比它平常得到的更公平的評價。它免費，跑在每月數十英鎊的主機上，資料是你自己的，而它的擴充套件目錄在電商領域遙遙領先地最大。對於團隊已經熟悉 WordPress 的中小型消費品商店，它常常是正確答案，也是最便宜的答案。

它在三個可以預見的地方吃力。第一是資料模型：產品是一種 WordPress 文章型別，屬性以序列化的 meta 存放，所以要在一個屬性繁多的大目錄上做篩選，就得去查一張鍵值表，而不是真正的欄位。1,000 件產品時還撐得住，5 萬件時就很痛苦了。

第二是變體數量之下的效能，這是 WooCommerce 商店讓人覺得慢的最常見原因。我們在WooCommerce 商店為什麼慢一文裡詳細講過它的機制，簡短的說法是：可變商品增加的是查詢數，而不是資料列數。

第三是外掛蔓延。WooCommerce 靠安裝東西來解決問題，四年之後，這家商店是由三十家供應商的發布節奏定義的，而不是由你自己定義的。

複雜產品建模：第一條真正的分界線

Drupal Commerce 最清楚的適用場景，是那種需要組態而不是挑選的產品。按公尺出售並收取裁切費的布料。按寬乘高定價並設有最低收費的玻璃。帶八個選項群組、其中一些會讓另一些失效的機器。帶數量級距折扣曲線與單次開機費的印刷品。

這些都不是變體表格。在代管型平台上，它們要靠一個應用程式加一組行項目屬性來近似，這代表顯示給客戶的價格是在平台自身的定價邏輯之外算出來的，之後總要在某個環節對帳。

在 Drupal Commerce 裡，價格由你自己寫的程式碼來解析。一個價格解析器接收變體、數量與目前的情境，然後回傳一個價格。這裡沒有任何玄妙之處，但它代表組態出來的價格在任何地方都是真正的價格：在購物車裡、在訂單裡、在稅額計算裡，以及在匯出給 ERP 的資料裡。

要套用的檢驗很簡單。如果你能把目錄寫成一張試算表，每個可購買的東西佔一列，那你不需要這套東西。如果寫不出來，本文其餘的一切就都相關了。

B2B 定價、價目表與議定條件

第二條分界線是：會不會有兩個客戶對同一個 SKU 看到不同的價格。消費品商店的答案是不會。貿易型生意的答案是會，而且這個答案通常就是整門生意本身。

Shopify 確實有 B2B，它的 B2B 方案功能文件確認 Basic、Grow、Advanced 與 Plus 都能使用。細節藏在限制裡：在 Plus 以下，所有 B2B 市場加起來最多三個啟用中的目錄，直接綁定到公司的目錄僅限 Plus，訂金、分期付款與按出貨批次請款也僅限 Plus。三個目錄拿來做三個價格層級沒問題，拿來管四十個議價客戶就沒用了。

在 Drupal 這一邊，對應的是 Commerce Price List 模組，目前版本 8.x-2.16，回報的安裝量約 1,662，並受安全團隊涵蓋。它可以按使用者或按角色設定價格，支援數量級距與生效日期區間，並且可以從 CSV 匯入。

最後這一點在實務上最管用。一家批發商有四十個客戶，每個客戶都有自己談好的價目表，每季從 ERP 更新一次，這就是一次 CSV 匯入作業，而不是一次平台遷移。

一套程式碼庫支撐多商店、多幣別與多語言

在 Drupal Commerce 裡，商店是一級實體，產品會被指派給可以販售它的那些商店。這是一個很小的設計決定，卻帶來很大的後果：多個店面可以共用同一份目錄、同一條訂單流程與同一個後台，同時各自使用不同的貨幣、稅務設定、金流閘道與運費規則。

常見的形態是一個英國站、一個歐盟站與一個貿易入口網站，全部由同一次部署運行。產品資料只輸入一次。價目表只作用在貿易商店上。稅額按商店解析，因為每個商店帶著自己的開立發票國別與稅籍登記。

Drupal 核心還提供了一層真正強的多語言能力，包含按語言的 URL 別名、可翻譯的實體與替代語言連結，這也是 Drupal 在高等教育與公部門存在感如此之重的原因。

Shopify Markets 如今涵蓋了其中相當一部分，但透過 Markets 做情境相關的結帳與店面客製僅限 Advanced 與 Plus 方案，所以比較的對象至少是每月 259 英鎊，而不是每月 25 英鎊。

當目錄本身就是編輯內容

有些目錄就是內容。一家專業零售商，如果它的產品頁帶著選購指南、比較表格、技術說明與評測者的筆記，那它經營的其實是一份順便收款的出版品。

在代管型平台上，那是兩套系統。CMS 存文章，商店存 SKU，兩者靠一條連結與一次夜間匯出接起來。編輯要在兩個地方工作，搜尋要索引兩遍，URL 結構中間會裂開一道縫。

在 Drupal Commerce 裡，產品和每一篇文章是同一個系統裡的實體，因此它共用編輯工作流程、修訂歷史、分類詞彙、媒體庫、搜尋索引與存取權限模型。一個產品頁可以參照三篇文章，一篇文章可以參照九個產品，而且兩者都是真正的實體參照，不是貼上去的連結。

對於一家本來完全可以安心待在 Shopify 上的生意來說，這是最常見、也最能真正說服人選 Drupal 的理由；同時它也是最常被當成「有了更好」而被打發掉的理由，直到編輯團隊在兩個後台之間來回工作了整整一年為止。

受法規管制與屬性極多的產品

帶有法遵資料的產品是第四種情形。附安全資料表的化學品。帶證書編號與有效期限的醫療器材。帶過敏原對照表的食品。附符合性聲明的電器。任何需要批次追溯或限售標記的東西。

要求不只是把這些值存下來。而是要驗證它們、為它們保留版本、對某位客戶實際收到的批次顯示正確的那一份，並且事後能證明某一天公開的是哪一版。Drupal 的欄位 API 與修訂系統做得到這些，因為它們本來就是為內容治理而不是為商品陳列而建的。

執行的那一側同樣重要。訂單處理器可以拒絕一筆會把限齡商品寄往禁售國家的結帳，或者拒絕一筆把兩件不得同運的商品放在一起的結帳，而且它是在訂單流程裡做這件事，不是在佈景主題樣板裡做。

在代管型平台上，這些檢查每一項都是一個應用程式，而應用程式之間並不會互相組合。兩個都會修改購物車的應用程式，遲早會互相打架。

當 ERP 才是權威資料來源

第五種情形是結構性的。在通路或製造業裡，ERP 掌握庫存、價格、客戶授信與訂單狀態，網站只是一個掛著購物車的展示面。問題不是這家店能做什麼，而是要多便宜才能讓它和真正說了算的那套系統保持一致。

Drupal Commerce 在這裡很自在，因為整合跑在你自己的程序裡。佇列 API 負責非同步工作，遷移 API 負責可重複且冪等的匯入，中間也沒有一個按筆收費或掐著你同步時窗的中介商。每晚匯入 20 萬列價格與庫存，就是一個 cron 工作。

在代管型平台上，同樣的整合不是一筆應用程式訂閱，就是一筆中介軟體訂閱，而平台的 API 速率限制會從一個細節變成你必須繞著設計的架構限制。那是可行的，對很多生意來說也是正確的取捨。它不再正確的時刻，是同步同時具備量大、頻繁與攸關業務命脈這三點的時候。

如果整合工作而不是商店本身構成了專案的主體，那它就是一個附帶店面的軟體開發專案，從一開始就該用這個口徑來界定範圍。

稅務是代管型平台不再便宜的地方

稅務是跨境電商裡安靜的成本中心，也是月訂閱費的比較開始誤導人的地方。兩條門檻決定了其中的大部分。

英國加值稅登記線

GOV.UK 關於何時需要登記加值稅的指引把門檻訂在應稅營業額合計 90,000 英鎊。有兩項各自獨立的測試會觸發登記義務：一項是滾動十二個月的測試，你必須在營業額超過 90,000 英鎊的那個月月底起 30 天內完成登記；另一項是前瞻性測試，一旦你意識到未來 30 天內營業額將超過 90,000 英鎊，就必須立刻登記。

前瞻性測試才是抓住成長期商店的那一條，因為登記日期是你意識到的那一天，不是錢入帳的那一天。

歐盟加值稅與一站式服務

歐盟執委會關於課稅地的指引訂出一條合計年度門檻，為 10,000 歐元，同時涵蓋歐盟內部的貨品遠距銷售，以及電信、廣播與電子服務。低於這條線時，課稅地是發貨或運送開始的地方。高於這條線時，課稅移到運送結束的地方，也就是客戶所在國的稅率。

一站式服務讓你在一個會員國用一份申報表把這一切報完，按季提交，截止日分別落在 4 月、7 月、10 月與 1 月的月底。進口一站式服務涵蓋自歐盟以外進口、單批價值不超過 150 歐元的貨物。

Drupal Commerce 原生做了什麼

Commerce 把歐盟加值稅稅別外掛放在核心裡，而不是當成附加元件販售。它帶有全部 27 個會員國加上摩納哥的稅率，區分標準稅率、減徵稅率、中間稅率、超低稅率與零稅率，並且處理那些會絆倒單一稅率表的特殊轄區，包括科西嘉、亞速爾、馬德拉、希臘各島嶼以及奧地利的飛地永霍茲。

它套用的不只是稅率，還有規則：數位商品按目的地課稅，以及在提供了有效稅籍編號的情況下，對歐盟內部企業間供貨適用零稅率。在代管型平台上，這種行為通常是一個按筆計費的應用程式。

付款、PCI DSS，以及你如何收下這張卡

你怎麼收集卡號，決定了你的法遵負擔，而這套規則最近以一種被廣泛誤解的方式改變了。

PCI 安全標準委員會對 SAQ A 適用條件的釐清說明了一項自 2025 年 4 月 1 日起生效的條件。商家必須確認自己的網站「不易受到可能影響商家電商系統的指令碼攻擊」，滿足方式有兩種：實作 PCI DSS 要求 6.4.3 與 11.6.1 中的技術措施，或者從金流商取得確認，證明其嵌入式方案已包含這些防護。

被誤解的正是它的適用範圍。這項條件只適用於在自己頁面上嵌入金流商付款表單的商家，通常是用 iframe 嵌入。委員會明確表示，它不適用於把客戶導向金流商那一邊的商家，無論用的是 HTTP 重新導向、meta refresh 還是 JavaScript；也不適用於把付款功能完全委外的商家。

所以代管式導向能把攻擊面維持得很小。而嵌入式欄位轉換率更好，也幾乎是所有人真正想要的形式，它會把結帳頁上每一段指令碼的完整性都拉進你的法遵討論裡。

Shopify 真正的優勢正在這裡，因為結帳頁是它的，頁面上的指令碼也是它的。在 Drupal Commerce 上結帳頁是你的，所以答案必須被工程化出來：一份嚴格的內容安全政策、子資源完整性、一份付款頁上所有執行中指令碼的清冊，以及其中任何一個變動時的偵測機制。這份工作既不難也不是可選項，它需要出現在預算裡，而不是在稽核過程中才被發現。

無障礙既是法律風險也是商業風險

電商的無障礙缺陷集中在結帳環節，而那也正是每一處缺陷都直接造成金錢損失的地方。

相關的參考標準是 WCAG 2.2，一份發布於 2024 年 12 月 12 日的 W3C 建議標準。真正會在商店裡咬人的成功準則很具體。AA 等級的 1.3.5 識別輸入目的，涉及地址欄與卡號欄的自動填入。A 等級的 3.3.7 重複輸入，是每當結帳流程要求客戶在付款步驟重新輸入送貨地址時都會被違反的那一條。AA 等級的 3.3.8 無障礙驗證，管的是註冊與登入。AA 等級的 2.5.8 目標大小會抓到數量加減控制項與從購物車移除的按鈕，而 AA 等級的 1.4.3 對比度會抓到那種看起來灰灰像停用、實際上卻可以按的按鈕。

圍繞訂單本身還有兩條：A 等級的 3.3.1 錯誤識別，以及 AA 等級的 3.3.4 針對法律、財務與資料交易的錯誤預防，後者講的正是下單這件事。

英國的法律處境常被誇大。一家民營零售商並不受某部點名 WCAG 符合等級的成文法約束。真正適用的是2010 年平等法第 20 條規定的義務：採取合理措施避免身心障礙者處於實質不利地位，其中包括提供輔助工具。真正點名了符合等級的那部法規，也就是 2018 年公部門機構（網站與行動應用程式）無障礙規則（第 2 號），適用的是公部門機構，而不是商店。

商業上的論點比法律上的更銳利。在代管的佈景主題裡，你未必總能修好某個應用程式注入結帳頁的東西。在你自己掌控的平台上，你可以。

三年到底要花多少錢

大家常做的比較是月訂閱費對月主機費，而那恰恰是表裡最不重要的一列。真正起決定作用的是建置成本與維護成本，而在有一定交易量之後，起決定作用的是交易費率。

下面這些區間是 Mecanik 針對英國中型市場商店的內部估算，只有 Shopify 的訂閱與費率數字例外，它們完全按 Shopify 公布的英鎊數照引。其餘都是我們預期會報出的價格，而每一列內部的跨度都比低端時平台之間的差距更大。

表裡每一列到底買到了什麼

用文字說一遍。Shopify Advanced 三年的訂閱費在 9,324 到 12,384 英鎊之間，取決於你是否按年承諾，其中含主機，但要再加上同期現實中大約 5,400 到 14,400 英鎊的應用程式訂閱。WooCommerce 在平台上一毛不花，主機花 3,600 到 14,400 英鎊，三年的擴充費用是 3,000 到 9,000 英鎊。Drupal Commerce 授權為零，主機上花得最多，5,400 到 21,600 英鎊，因為它是三者中最重的應用；附加元件上花得最少，從零到大約 3,000 英鎊，因為對等功能來自貢獻模組而不是商業外掛。

真正拉開平台差距的是建置成本。Shopify 上 8,000 到 25,000 英鎊的建置，買到的是一個套好佈景主題、接好標準整合的商店，WooCommerce 上同樣的東西是 10,000 到 35,000 英鎊。同一份需求書放到 Drupal Commerce 上是 35,000 到 120,000 英鎊，因為結帳、定價邏輯與各項整合都是寫出來的，不是設定出來的。維護也是同樣的形狀：Shopify 每年 3,000 到 9,000 英鎊，WooCommerce 每年 4,000 到 12,000 英鎊，Drupal Commerce 每年 12,000 到 30,000 英鎊，這反映的是我們在Drupal 開發者費率指南裡談過的、大約 600 到 900 英鎊的英國服務商日費率。

三年合計最後落在哪裡

三年合計大致落在：Shopify 約 32,000 到 79,000 英鎊，WooCommerce 約 29,000 到 94,000 英鎊，Drupal Commerce 約 76,000 到 235,000 英鎊。刷卡費與金流閘道費疊加在這三者之上，並隨營業額成長，這也正是為什麼 Advanced 上 0.6% 的 Shopify 第三方閘道費用，對一家年營業額 100 萬英鎊的商店來說三年值 18,000 英鎊。

誠實地讀這張表，Drupal Commerce 是兩到三倍的成本。它只有在替代方案實際上根本不可用時才站得住腳，而這正是前面五節的全部要點。

無頭與解耦的 Drupal Commerce

把 Drupal Commerce 解耦，在一小類場景裡是真需求，在其餘大多數場景裡是流行。誠實的判準是：有沒有網站以外的東西需要同一份目錄。

它是真需求的情形包括：一個原生行動應用程式與一個網站必須共用同一套產品與定價模型；一個由別的團隊做的既有前端不會被替換；POS 終端或自助機要使用同一個購物車；或者設計系統由專案之外的人掌握，無法用 Twig 表達。在這些情形裡，API 才是產品，CMS 是被刻意隱藏起來的。

它是流行的情形，是當給出的理由是效能的時候。一個快取做得好的傳統 Drupal 前端會從邊緣節點直接送出匿名使用者的產品頁，而渲染方式很少是讓一家商店變慢的原因。

成本集中在一個地方。Drupal 核心不用設定就透過 JSON:API 公開內容，Commerce Cart API 模組把購物車放在 REST 介面之後，所以讀取目錄與組出購物車幾乎不花什麼力氣。結帳不是這樣。地址處理、稅額顯示、運送方式選擇、促銷、付款元件整合與訂單確認全都得在前端重建，而這通常佔整體建置量的 40% 或更多。

五分鐘決策規則

針對你自己的目錄回答六個問題。每答一個「是」記一分。

你的產品裡有沒有需要超過三個選項，或者超過 2,048 種可購買組合的？會不會有兩個不同客戶為同一個 SKU 付不同的價格？你是否賣到加值稅處理方式不同的多個國家，或者預期要申報 OSS？目錄是不是同時也是由同一個團隊撰寫與維護的編輯內容？價格與庫存的權威是不是 ERP 或 PIM，而商店位在它的下游？你是否需要往結帳流程裡插入自己的邏輯，而不只是替它做品牌化？

拿零分或一分就選 Shopify。本文描述的那些優勢對你並不適用，你只會付錢去重做你現在租來的東西。

拿兩分時決定是真的開放的，WooCommerce 往往是更好的中間路線，尤其當團隊已經在跑 WordPress 的時候。

拿三分或更多，就值得認真替 Drupal Commerce 做一次報價，因為在別處所需的那些變通做法，三年下來會比這個平台更貴。拿五分或六分，代管型平台就不是更便宜的選項了，它是一件做不了這份活的、不同的產品。

Drupal Commerce 專案通常錯在哪裡

最常見的失敗是因為錯的理由選了它。「我們本來就在跑 Drupal」不是一個電商需求。內容網站與交易網站在可用性要求、測試方式以及部署出錯時的後果上都不一樣，而把商店當成既有網站的又一個區塊，正是一個小電商專案最後養出一支計畫外平台團隊的路徑。

第二是維護投入不足。35,870 的安裝量代表這個生態小到你一定會用上只有寥寥幾位維護者的模組，而你這一側必須有人盯著安全公告並安排更新。一個沒人負責這件事的 Drupal Commerce 網站，是一次延遲發生的資安事故，這一點我們在Drupal 實際需要的主機條件裡談得更細。

第三是假定模組已經存在。界定範圍之前先去查。如果沒有，那份工作就是一次客製的網站開發任務，需要一個真正的估算，而不是清單上的一列。

第四是大版本紀律。Commerce 3 要求 Drupal 10.3 或更新版本，而一個落後於核心的網站，最終會發現它的電商模組已經先走一步了。我們的2026 年 Drupal 開發指南和那篇談遷移成本與期限的文章都深入談了這個週期。

把這個決定做對

決定這件事的是產品與定價的複雜度，不是流量、營業額或個人偏好。先在紙上把你的目錄建模一遍，把每一個選項、每一個議定價格、以及每一處必須和別的系統保持一致的整合都寫進去。如果那個模型裝得進一張變體表格，就買代管型平台，把省下來的預算花在商品企劃上。

Mecanik 兩種商店都做也都維護，在報價之前我們會先告訴你你在這條線的哪一邊。如果答案是 Drupal Commerce，那這份工作是一個帶著大量整合內容的網站開發專案；如果 ERP 那邊的工作量壓過了店面本身，它就該歸到軟體開發之下。如果答案是 Shopify，我們會照直說，而且我們寧願現在就說，也不願等到重做進行了十八個月之後再說。

常見問題

Drupal Commerce 比 Shopify 更好嗎？ 對大多數商店來說並不是。Shopify 三年下來更便宜，替你處理 PCI 法遵與主機，並且擁有一個經過任何服務商都無法匹敵的規模檢驗的結帳流程。Drupal Commerce 只在一小類場景裡勝出：選項超過三個或變體超過 2,048 個的產品、按客戶議定的價格、同時也是編輯內容的目錄，以及由 ERP 掌握價格與庫存的商店。

在英國做一個 Drupal Commerce 專案要花多少錢？ 初始建置預計 35,000 到 120,000 英鎊，維護每年 12,000 到 30,000 英鎊，對應英國服務商大約 600 到 900 英鎊的日費率。三年下來，一家 Drupal Commerce 商店連同主機通常落在 76,000 到 235,000 英鎊之間，而 Shopify Advanced 約為 32,000 到 79,000 英鎊。這些是內部估算，不是報價。

我應該使用哪一個版本的 Drupal Commerce？ 使用 Drupal Commerce 3，目前版本是 3.3.8，於 2026 年 7 月 17 日發布。它支援 Drupal 10.3 以上以及 Drupal 11，穩定版受 Drupal 安全公告政策涵蓋。Commerce 2 支援 Drupal 9 與 10，屬於上一個發布週期，所以新專案應該從 3.x 開始。

Drupal Commerce 能處理歐盟加值稅與 OSS 嗎？ 稅務規則內建在 Commerce 核心裡，而不是當成附加元件販售。歐盟加值稅外掛帶有全部 27 個會員國加上摩納哥的稅率，區分標準、減徵、中間、超低與零稅率，處理特殊轄區，對數位商品適用目的地課稅，並在提供有效稅籍編號時對歐盟內部 B2B 供貨適用零稅率。提交 OSS 申報表仍然是一項會計工作。

無頭 Drupal Commerce 什麼時候值得做？ 當網站以外的東西要使用同一份目錄時，例如原生應用程式、POS 終端，或者由另一個團隊掌握的前端。單單為了速度並不值得，因為快取做得好的傳統前端本來就已經很快。要為重建結帳流程留出預算，它在解耦專案裡通常佔 40% 或更多。