EC-CUBE 到 Shopify + Next.js 迁移：日本电商指南 2026

如果你在日本运营 EC-CUBE 商店，并且一直在为维护自托管的 PHP 单体应用感到困扰，你并不孤单。在过去两年里，我们帮助了几家日本电商企业从 EC-CUBE（2.x、3.x 和 4.x 版本）迁移到使用 Next.js 构建的无头 Shopify 店面。每一家企业事后都说同样的话："我们应该早点这样做。"

但问题是——这种迁移确实很复杂。EC-CUBE 在日本商业文化中根深蒂固。它处理地址上的假名字段、日本支付方法（便利店支付、运营商结算、通过 Pay-easy 进行的银行转账）以及基于日本邮政区域的运费计算。你不能只是按一个开关就转向 Shopify。你需要一个策略。

本指南是我在 2024 年进行第一次 EC-CUBE 迁移时希望能有的策略文件。

EC-CUBE to Shopify + Next.js Migration: Japanese Ecommerce Guide 2026

为什么在 2026 年迁离 EC-CUBE
理解 EC-CUBE 架构
为什么选择 Shopify Plus + Next.js 做日本电商
迁移前审计和规划
数据迁移策略
处理日本支付方法
运输和履行映射
构建 Next.js 店面
SEO 迁移和 URL 保留
日本特定的用户体验考虑
性能基准：EC-CUBE vs 无头 Shopify
时间表和成本预期
常见问题

为什么在 2026 年迁离 EC-CUBE

EC-CUBE 已经是日本电商的支柱近二十年了。由 Lockon Co., Ltd.（现在是 EC-CUBE Co., Ltd.）开发的它，在选择有限的时代主导了日本市场。但形势已经发生了巨大变化。

以下是促使企业迁离的原因：

安全维护是个噩梦。 EC-CUBE 2.x 多年前就已停止支持，但令人惊讶的是仍有大量商店运行它。即使是 EC-CUBE 4.x 也需要不断打补丁。仅在 2024 年，EC-CUBE 4 就有三个关键安全公告，包括影响数千家商店的 SQL 注入漏洞（CVE-2024-22345）。如果你是自托管，这是你的问题。

PHP 托管成本持续上升。 在日本运行 EC-CUBE（通常在 Sakura Internet、XSERVER 或 AWS Tokyo 上）意味着你要为基础设施、SSL 证书、数据库维护和服务器监控付费。一个典型的中型 EC-CUBE 商店每月仅在托管和维护上就花费 ¥50,000–¥200,000。

插件生态系统正在萎缩。 EC-CUBE 插件市场一直在失去开发者。许多流行的支付和运输插件还没有为 EC-CUBE 4.2+ 更新。如果你的商店依赖第三方插件，你可能会发现自己被困在一个没有升级路径的旧版本上。

移动性能很差。 大多数 EC-CUBE 主题都是在响应式但沉重的时代设计的。我们审计的 EC-CUBE 商店的平均 Lighthouse 移动得分徘徊在 25-40 之间。当 Core Web Vitals 直接影响你在日本的 Google 排名时，这是不够的。

理解 EC-CUBE 架构

在迁移之前，你需要理解你要迁移的东西。EC-CUBE 的架构根据版本差异很大：

功能	EC-CUBE 2.x	EC-CUBE 3.x	EC-CUBE 4.x
框架	自定义 PHP	Silex（Symfony 微框架）	Symfony 4/5
数据库	PostgreSQL/MySQL	PostgreSQL/MySQL	PostgreSQL/MySQL
模板引擎	Smarty	Twig	Twig
插件架构	钩子/覆盖	事件驱动	Symfony 包
ORM	自定义	Doctrine	Doctrine
API	无（自定义构建）	有限 REST	REST + 有限 GraphQL

数据库架构是有趣的地方（也是痛苦的地方）。EC-CUBE 将产品数据、客户数据和订单历史存储在标准化但特定于 EC-CUBE 的架构中。dtb_product、dtb_product_class、dtb_customer 和 dtb_order 表是你需要提取的核心表。

EC-CUBE 4.x 使用 Doctrine 实体，这使得数据提取相对清洁。但如果你在 2.x 上，要准备好处理原始 SQL 导出，包括编码问题（Shift-JIS 或 EUC-JP 遗留数据仍然很常见）。

EC-CUBE to Shopify + Next.js Migration: Japanese Ecommerce Guide 2026 - architecture

为什么选择 Shopify Plus + Next.js 做日本电商

我想坦白说：Shopify 不是唯一的选择。你可以迁移到其他平台，如 commercetools、Medusa，甚至是较新的日本平台，如 BASE 或 STORES.jp。但对于中等到大型日本电商运营，Shopify Plus 结合无头 Next.js 前端击中了一个甜蜜点。

Shopify 在日本的存在已经成熟。 自从在东京开设办公室并推出完整的日语支持以来，Shopify 已经解决了大部分日本特定的差距。Shopify Payments 现在原生支持 JCB 卡。管理界面已完全本地化。至关重要的是，Shopify Plus 支持日本税收计算，包括食品和饮料的轻減税率（减税率）系统。

Next.js 给你性能优势。 使用 Next.js 构建的无头店面（使用 Shopify Storefront API 或 Hydrogen 的底层数据层）让你从边缘服务静态和服务器渲染的页面。我们在 Next.js Shopify 构建中经常看到移动版 Lighthouse 性能得分为 90+。这与 EC-CUBE 典型的 30 多分的差距是巨大的。

Storefront API 处理复杂性。 Shopify 的 Storefront API（截至目前的 2025-04 版本）支持元字段、本地化内容、多货币和自定义产品选项——复制 EC-CUBE 灵活性所需的一切。

如果你在评估基于 Next.js 的无头架构是否适合你的特定商店，答案几乎总是取决于你的目录大小和定制需求。少于 100 个产品，有简单变体？标准 Shopify 主题可能没问题。复杂的产品配置、大量定制或多个店面？选择无头。

迁移前审计和规划

在触及一行代码之前，不要完成这个审计：

1. 目录复杂性映射

记录 EC-CUBE 商店中的每个产品类型、变体结构和自定义字段。EC-CUBE 的 dtb_product_class 表可以保存不一定 1:1 映射到 Shopify 变体模型的复杂变体组合（Shopify 每个产品有 100 个变体限制和 3 个选项限制）。

如果你有超过 3 种选项类型的产品（例如，尺寸、颜色、材料、刻字），你需要使用 Shopify 的 Combined Listings 功能（2024 年推出）或使用元字段和行项属性重构产品架构。

2. 客户数据清单

EC-CUBE 存储丰富的客户数据，包括：

姓名（姓氏/名字，单独字段）
フリガナ（名字的假名）
郵便番号（邮政编码和自动地址填充）
每个客户的多个送货地址
积分余额（ポイント）
包含详细订单状态跟踪的购买历史

Shopify 的客户模型原生处理名称字段和多个地址。但积分/忠诚度计划需要第三方解决方案，如 Smile.io 或基于自定义元字段的系统。

3. 集成清单

列出 EC-CUBE 商店连接到的每个外部系统：

支付网关（GMO Payment Gateway、SB Payment Service、PAY.JP）
运输 API（Yamato Transport、Sagawa Express、Japan Post）
会计软件（弥生会計、freee、MoneyForward）
库存/ERP 系统
电子邮件营销（Mailchimp、SendGrid 或日本服务，如 Benchmark Email）

4. URL 结构文档

从你的 EC-CUBE 商店导出每个 URL。这对 SEO 迁移至关重要。EC-CUBE 的默认 URL 模式看起来像：

/products/detail/{product_id}
/products/list?category_id={id}
/mypage/
/cart/

你需要所有这些的重定向映射。

数据迁移策略

这是我们使用的迁移管道：

产品数据导出

对于 EC-CUBE 4.x，你可以使用 Doctrine 的 CLI 工具或编写一个 Symfony 命令将产品导出为 JSON：

// EC-CUBE 4.x 产品导出命令
$products = $this->productRepository->findAll();
$exportData = [];

foreach ($products as $product) {
    $variants = [];
    foreach ($product->getProductClasses() as $class) {
        $variants[] = [
            'sku' => $class->getCode(),
            'price' => $class->getPrice02IncTax(),
            'stock' => $class->getStock(),
            'class_category1' => $class->getClassCategory1()?->getName(),
            'class_category2' => $class->getClassCategory2()?->getName(),
        ];
    }
    
    $exportData[] = [
        'id' => $product->getId(),
        'name' => $product->getName(),
        'description' => $product->getDescriptionDetail(),
        'variants' => $variants,
        'images' => array_map(fn($img) => $img->getFileName(), $product->getProductImages()->toArray()),
    ];
}

对于 EC-CUBE 2.x，你看的是原始 SQL：

SELECT 
    p.product_id,
    p.name,
    p.main_comment,
    pc.product_code,
    pc.price02,
    pc.stock
FROM dtb_product p
JOIN dtb_product_class pc ON p.product_id = pc.product_id
WHERE p.del_flg = 0 AND pc.del_flg = 0;

注意字符编码。如果你的 EC-CUBE 2.x 数据库使用 EUC-JP，在导入任何地方之前转换为 UTF-8：

mysqldump --default-character-set=eucjpms your_db | iconv -f EUC-JP -t UTF-8 > export_utf8.sql

导入到 Shopify

使用 Shopify Admin API（REST 或 GraphQL）以编程方式创建产品。GraphQL 中的 productCreate 变体是你最好的朋友：

mutation productCreate($input: ProductInput!) {
  productCreate(input: $input) {
    product {
      id
      title
      variants(first: 100) {
        edges {
          node {
            id
            sku
          }
        }
      }
    }
    userErrors {
      field
      message
    }
  }
}

构建一个 Node.js 或 Python 的迁移脚本，读取导出的 EC-CUBE 数据并创建 Shopify 产品。包括速率限制——Shopify API 对 REST 有 2 个请求/秒的限制，对 GraphQL 有基于成本的限制。

客户迁移

Shopify 的通过 API 的客户导入工作良好，但请注意 你不能迁移密码。所有客户在迁移后需要重置密码。发送精心编写的电子邮件（用日语，当然）解释迁移并提供密码重置链接。

对于客户数据本身，将 EC-CUBE 字段映射到 Shopify：

EC-CUBE 字段	Shopify 字段	备注
name01（姓）	last_name	为日语反转
name02（名）	first_name	为日语反转
kana01（セイ）	metafield	没有本地假名字段
kana02（メイ）	metafield	没有本地假名字段
email	email	直接映射
point	metafield 或忠诚度应用	需要自定义处理
addr01（都道府県）	province	映射到 Shopify 省份代码
addr02（市区町村）	city + address1	可能需要连接

订单历史

迁移历史订单是可选的，但建议用于客户服务连续性。使用 Shopify 的 Order API 创建已完成订单的订单，设置 "financial_status": "paid" 和 "fulfillment_status": "fulfilled"。

处理日本支付方法

这是变得棘手的地方。日本消费者期望特定的支付选项，这在西方电商中并不标准。

Shopify Payments 现在在日本支持信用卡，包括 JCB、Visa、Mastercard 和 American Express。对于 Shopify Plus，处理费用为 3.25%–3.4% + ¥0 每笔交易。

对于其他支付方法：

支付方式	Shopify 上的解决方案	备注
コンビニ決済（便利店支付）	KOMOJU、GMO Payment Gateway 应用	对日本在线订单的约 15% 至关重要
代引き（货到付款）	Shopify 本地 COD	内置，工作良好
銀行振込（银行转账）	手动支付方式	Shopify 原生支持
キャリア決済（运营商结算）	KOMOJU	docomo、au、SoftBank
PayPay	适用于 Shopify 的 PayPay 应用	日本最受欢迎的二维码支付
Amazon Pay	Amazon Pay 应用	在日本采用率高
後払い（先买后付）	Paidy、atone	在日本非常受欢迎

KOMOJU 值得特别提及。它已成为 Shopify 日本商店事实上的支付网关，通过单一集成支持便利店支付、银行转账、运营商结算等。他们的 Shopify Plus 集成很健全，我们没有遇到过重大问题。

运输和履行映射

EC-CUBE 通常使用黑猫宅急便（ヤマト運輸）、佐川急便（佐川急便）和日本邮政（日本郵便）的插件。这些插件处理运输标签生成、跟踪号集成和配送时间段选择（配達時間指定）。

在 Shopify 上，你有几个选择：

Ship&co ——日本构建的运输应用，与所有主要日本承运人集成。处理正确格式的标签打印。
Shopify Shipping ——截至 2025 年日本承运人支持有限，但正在改进。
自定义 Carrier Service API ——如果你有复杂的区域定价，构建自己的运费计算器。

配送时间段选择（午前中、12-14時、14-16時等）对日本客户至关重要。这需要 Shopify Plus 上的自定义结账扩展或第三方应用，如配送日時指定。

构建 Next.js 店面

对于前端，我们使用带 App Router 和 Server Components 的 Next.js 15。这是我们的典型堆栈：

Next.js 15（App Router）
├── Shopify Storefront API（GraphQL）
├── next-intl（用于日语 i18n）
├── Tailwind CSS 4
├── Framer Motion（动画）
└── Vercel（部署，东京地区边缘）

我们在使用 Next.js 构建日本店面时学到了几件事：

字体优化

日本网络字体很重。仅 Noto Sans JP 常规字体就有 ~1.8MB。使用带 subsets 的 next/font，并考虑可变字体：

import { Noto_Sans_JP } from 'next/font/google';

const notoSansJP = Noto_Sans_JP({
  subsets: ['latin'],
  weight: ['400', '500', '700'],
  display: 'swap',
  preload: true,
});

更好的是，对非关键文本使用 font-display: optional 并提供系统字体堆栈作为后备："Hiragino Kaku Gothic ProN", "Hiragino Sans", Meiryo, sans-serif。

产品页面的 Server Components

在 Server Components 中获取产品数据以消除客户端加载状态：

// app/products/[handle]/page.tsx
export default async function ProductPage({ params }: { params: { handle: string } }) {
  const product = await shopifyFetch({
    query: PRODUCT_QUERY,
    variables: { handle: params.handle },
  });

  return (
    <div>
      <ProductGallery images={product.images} />
      <ProductDetails product={product} />
      <AddToCartButton variantId={product.variants[0].id} />
    </div>
  );
}

我们用这种模式构建所有无头 Shopify 店面，与传统 Liquid 主题甚至 Hydrogen 相比的性能差异是明显的。

SEO 迁移和 URL 保留

这是在迁移项目中让我夜不能寐的部分。日本电商商店通常有多年积累的 SEO 权益，迁移失误可能导致有机流量数月内大幅下降。

重定向策略

创建完整的重定向映射。每一个。单一的。URL。使用 Next.js 的 next.config.js 重定向用于静态模式：

// next.config.js
module.exports = {
  async redirects() {
    return [
      {
        source: '/products/detail/:id',
        destination: '/products/:handle',
        permanent: true,
      },
      {
        source: '/products/list',
        destination: '/collections/:collection',
        permanent: true,
      },
    ];
  },
};

对于动态重定向（将 EC-CUBE 产品 ID 映射到 Shopify 句柄），使用中间件或存储在数据库或 KV 存储中的重定向查找表。

结构化数据

EC-CUBE 商店很少有适当的结构化数据。利用这个机会实现 Product、BreadcrumbList、Organization 和 FAQPage 架构。日本 Google SERP 大量提供富结果。

日本 SEO 细节

在日文中将标题标签保持在 30 个字符以内（不像英文的 60）
元描述：80-120 个日文字符
如果你有多语言页面，确保正确的 hreflang 标签
向 Google Search Console 和 Bing Webmaster Tools 提交站点地图（Bing 在日本有相当的市场份额）

日本特定的用户体验考虑

日本电商用户体验有西方开发者经常忽视的文化差异：

信息密度 ——日本消费者期望在页面上看到更多产品信息。不要过度最小化。
信任信号 ——突出显示运输政策、退货政策和公司信息。日本购物者会进行彻底研究。
邮政编码自动填充 ——使用日本郵便 API 或像 zipaddress.js 这样的库实现郵便番号 → 地址自动完成。
敬语 ——在 UI 副本中使用适当的敬语（敬語）。非正式语言可能会显得不尊重。
Line 消息集成 ——LINE 在日本有 9600 万月活跃用户。集成 LINE 登录和 LINE 通知。

性能基准：EC-CUBE vs 无头 Shopify

以下是我们在 2025 年 Q1 为一家日本时装零售商（~3,000 SKU）完成的迁移的真实数据：

指标	EC-CUBE 4.2（之前）	Next.js + Shopify（之后）	改进
Lighthouse 性能（移动）	34	92	+170%
LCP	4.8s	1.2s	-75%
FID/INP	380ms	45ms	-88%
CLS	0.24	0.02	-92%
首字节时间	1.8s	0.18s	-90%
页面权重（产品页面）	3.2MB	680KB	-79%
转换率	1.8%	2.9%	+61%
每月托管成本	¥180,000	¥45,000	-75%

仅转换率改进就在三个月内支付了整个迁移成本。并非每个项目都能看到这样的数字，但这种量级的性能改进始终会产生影响。

时间表和成本预期

让我们现实地看待这个迁移需要什么：

商店规模	产品	时间表	预算范围（¥）
小型	<500	8-12 周	¥3,000,000-5,000,000
中型	500-5,000	12-20 周	¥5,000,000-12,000,000
大型	5,000+	20-32 周	¥12,000,000-25,000,000+

这些范围包括设计、开发、数据迁移、质量保证和启动支持。他们假设你在与有经验的团队合作。如果你的团队以前没有做过日本电商迁移，为学习曲线增加 30-50% 的时间和预算。

我们通过我们的无头 CMS 和商务开发实践处理这个范围内的项目。如果你想谈论具体情况，联系我们，我们会给你一个诚实的评估。

迁移后的每月持续成本通常如下：

Shopify Plus：$2,300/月（~¥345,000）
Vercel Pro：$20/月每位团队成员
KOMOJU：仅交易费用
Ship&co：¥2,000/月基础费用
总计：~¥380,000-450,000/月 vs. ¥400,000-800,000/月用于具有等效功能的自托管 EC-CUBE

如需了解我们如何构造项目定价，请查看我们的定价页面。

常见问题

我可以直接从 EC-CUBE 2.x 迁移到 Shopify + Next.js 吗？ 是的，但 EC-CUBE 2.x 迁移由于较旧的数据库架构、潜在的 Shift-JIS/EUC-JP 编码问题以及缺少现代 ORM 而更复杂。为数据清理和转换预留额外时间。我们建议首先导出到中立格式（UTF-8 格式的 CSV 或 JSON），然后为 Shopify 构建导入脚本。

迁移 EC-CUBE 时我会失去 Google 排名吗？ 如果你正确处理重定向，就不会。为每个 URL 实现 301 重定向，维护你的 XML 站点地图，并保持你的标题标签和元描述一致。期望临时波动（2-4 周）当 Google 重新抓取，但排名应该恢复，通常由于更好的 Core Web Vitals 得分而改进。

Shopify 支持包括减税率的日本税收计算吗？ 是的。Shopify 支持日本的消费税系统，包括軽減税率（食品和饮料的 8% 减税率 vs. 标准 10% 税率）。你可以为每个产品集合配置税率，Shopify 处理计算，包括符合发票资格的收据要求（インボイス制度）。

迁移到 Shopify 后如何处理 EC-CUBE 的积分系统？ Shopify 没有与 EC-CUBE 内置ポイント功能等效的本地积分系统。你最好的选择是 Smile.io（支持日语）、LoyaltyLion 或使用 Shopify 元字段和无服务器函数的自定义解决方案。对于现有的点余额，将它们作为元字段迁移到客户记录，并在 Next.js 结账中构建兑换流程。

Hydrogen 对于无头 Shopify 店面比 Next.js 更好吗？ 这取决于。Hydrogen（Shopify 基于 Remix 构建的 React 框架）与 Shopify 紧密集成，并为你提供一些很好的内置商务原始类型。但 Next.js 有一个更大的生态系统、更多社区资源、Vercel 上更好的 Edge Runtime 支持，以及如果你曾经想交换商务后端的更多灵活性。对于日本电商特别是，Next.js 的中间件功能和 i18n 路由给了它一个优势。我们用两者都构建过，对大多数项目更倾向 Next.js——参见我们的 Next.js 开发能力。

我可以在迁移期间并行运行 EC-CUBE 和新的 Shopify 商店吗？ 绝对可以，我们建议这样做。同时运行两个系统 2-4 周。使用你的 DNS 或反向代理逐渐转移流量。这让你能够验证订单正确流动、支付正确处理、库存保持同步，然后完全切断。

EC-CUBE 的邮件杂志（メールマガジン）功能怎么样？ EC-CUBE 有许多商店依赖的内置电子邮件通讯系统。将你的订阅者列表迁移到专用电子邮件营销平台，如 Klaviyo（具有优秀的 Shopify 集成），或者如果你需要日语支持和模板，考虑 Benchmark Email 或 SendGrid。迁移很直接——从 EC-CUBE 的 dtb_customer 表导出电子邮件地址和同意日期，并导入你的新平台。

实际数据迁移需要多长时间？ 迁移脚本执行本身通常很快——大多数商店需要几小时。耗时的部分是构建和测试迁移脚本、验证数据完整性和处理边界情况（产品缺少图像、客户电子邮件格式无效、带有自定义状态的订单）。对于有 3,000 个产品和 50,000 个客户的商店，期望 2-3 周的迁移开发和测试时间。