EC-CUBE 到 Shopify + Next.js 遷移：日本電商指南 2026
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 遷移時希望擁有的策略文件。
目錄
- 為什麼在 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 之間。當核心網絡生命體徵直接影響您在日本的谷歌排名時，這還不夠好。
了解 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 遺留數據仍然很常見）。
為什麼選擇 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 變體模型（每個產品限制 100 個變體，3 個選項限制）的複雜變體組合。
如果您的產品超過 3 種選項類型（例如，尺寸、顏色、材料、刻字），您需要使用 Shopify 的組合清單功能（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 有基於成本的限制。
客戶遷移
通過 API 進行 Shopify 客戶導入效果很好，但要注意您無法遷移密碼。所有客戶在遷移後都需要重置密碼。發送一份精心編寫的電子郵件（當然要用日語）解釋遷移並提供密碼重置鏈接。
對於客戶數據本身，將 EC-CUBE 欄位映射到 Shopify：
| EC-CUBE 欄位 | Shopify 欄位 | 備註 |
|---|---|---|
| name01（姓） | last_name | 對於日語反轉 |
| name02（名） | first_name | 對於日語反轉 |
| kana01（セイ） | 元字段 | 無原生假名欄位 |
| kana02（メイ） | 元字段 | 無原生假名欄位 |
| 直接映射 | ||
| point | 元字段或忠誠度應用 | 需要自定義處理 |
| 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 | PayPay for Shopify 應用 | 日本最受歡迎的二維碼支付 |
| Amazon Pay | Amazon Pay 應用 | 日本採用率高 |
| 後払い（先買後付） | Paidy、atone | 在日本非常受歡迎 |
KOMOJU 值得特別提及。它已成為 Shopify 日本商店的事實上的支付閘道，通過單一集成支持便利店支付、銀行轉帳、運營商計費等。他們的 Shopify Plus 集成是可靠的，我們沒有遇到重大問題。
運費和履行映射
EC-CUBE 通常使用 Yamato Transport（ヤマト運輸）、Sagawa Express（佐川急便）和 Japan Post（日本郵便）的插件。這些插件處理運費標籤生成、追蹤號碼集成以及交貨時間段選擇（配達時間指定）。
在 Shopify 上，您有幾個選擇：
- Ship&co ——日本開發的運費應用，與所有主要日本運營商集成。以正確的格式處理標籤打印。
- Shopify Shipping ——截至 2025 年，日本運營商支持有限，但正在改進。
- 自定義 Carrier Service API ——如果您有複雜的基於區域的定價，請構建您自己的運費計算器。
交貨時間段選擇（午前中、12-14時、14-16時 等）對日本客戶至關重要。這需要 Shopify Plus 上的自定義結帳擴展或第三方應用，如 配送日時指定。
構建 Next.js 店面
對於前端，我們使用 Next.js 15 與 App Router 和 Server Components。以下是我們的典型堆棧：
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.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 架構。日本谷歌 SERP 大量提供豐富結果。
日本 SEO 特定事項
- 將標題標籤保持在日語中 30 個字符以下（不是英語中的 60）
- 元描述：80-120 日語字符
- 確保適當的
hreflang標籤（如果您有多語言頁面） - 將站點地圖提交到 Google Search Console 和 Bing Webmaster Tools（Bing 在日本具有有意義的市場份額）
日本特定的用戶體驗考慮
日本電子商務用戶體驗具有西方開發者經常忽視的文化差異：
- 信息密度 ——日本消費者期望在頁面上看到更多產品信息。不要過度最小化。
- 信任信號 ——突出顯示運費政策、退貨政策和公司信息。日本購物者進行深入研究。
- 郵遞區號自動填充 ——使用日本郵政 API 或
zipaddress.js等庫實施 郵便番号 → 地址自動完成。 - 敬語 ——在 UI 文案中使用適當的敬語（敬語）。非正式語言會顯得不尊重。
- Line 消息集成 ——LINE 在日本有 9600 萬月活躍用戶。集成 LINE Login 和 LINE 通知。
性能基準：EC-CUBE vs 無頭 Shopify
以下是我們在 2025 年第一季度為日本時尚零售商（~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+ |
這些範圍包括設計、開發、數據遷移、QA 和啟動支持。它們假設您與有經驗的團隊合作。如果您的團隊以前沒有進行過日本電子商務遷移，請為學習曲線將時間表和預算增加 30-50%。
我們通過無頭 CMS 和商務開發實踐來處理跨越此光譜的項目。如果您想了解具體情況，請與我們聯繫，我們會給您一個誠實的評估。
遷移後的月度持續成本通常如下所示：
- Shopify Plus：$2,300/月（~¥345,000）
- Vercel Pro：$20/月 每位團隊成員
- KOMOJU：僅交易費
- Ship&co：¥2,000/月基費
- 總計：~¥380,000-450,000/月 vs. 具有同等功能的自託管 EC-CUBE 的 ¥400,000-800,000/月
有關我們如何構造項目定價的透明說明，請查看我們的定價頁面。
常見問題
我可以直接從 EC-CUBE 2.x 遷移到 Shopify + Next.js 嗎？ 可以，但 EC-CUBE 2.x 遷移由於舊數據庫架構、潛在的 Shift-JIS/EUC-JP 編碼問題以及缺乏現代 ORM 而更複雜。預留額外時間進行數據清理和轉換。我們建議先導出為中性格式（UTF-8 中的 CSV 或 JSON），然後為 Shopify 構建導入腳本。
遷移 EC-CUBE 時，我會失去谷歌排名嗎？ 如果您正確處理重定向，則不會。為每個 URL 實施 301 重定向，維護 XML 站點地圖，並保持標題標籤和元描述一致。期望暫時波動（2-4 週），因為谷歌重新爬取，但排名應該恢復，並且由於改進的 Core Web Vitals 分數，排名通常會上升。
Shopify 是否支持日本稅收計算，包括減稅率？ 是的。Shopify 支持日本的消費稅系統，包括 軽減税率（食品和飲料的 8% 減稅率 vs. 標準 10% 稅率）。您可以為每個產品集合配置稅率，Shopify 處理計算，包括符合發票資格的收據要求（インボイス制度）。
遷移到 Shopify 後，如何處理 EC-CUBE 的積分系統？ Shopify 沒有與 EC-CUBE 內置 ポイント 功能等效的原生積分系統。您最好的選擇是 Smile.io（支持日語）、LoyaltyLion 或使用 Shopify 元字段和無服務器函數的自定義解決方案。對於現有積分餘額，將它們作為客戶記錄上的元字段遷移，並在 Next.js 結帳中構建兌換流程。
Hydrogen 比 Next.js 更好用於無頭 Shopify 店面嗎？ 這取決於。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 週的遷移開發和測試時間。