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% 或更多。