我看過的所有 Python 電商文章都遵循相同的結構:列出框架、列出功能,最後以「Python 很適合電商」作結。技術上正確,但如果你真的要動手建立,卻沒什麼幫助。

這篇文章採取更實務的觀點。我想涵蓋真正重要的決策——帶有實際理由的框架選擇、比外觀看起來更困難的功能、值得認識的程式碼模式,以及那些在早期避開遠比日後修復容易的架構陷阱。


從這裡開始:你真的需要自訂建置嗎?

在討論任何框架之前——如果你的電商需求是標準的(產品目錄、購物車、結帳、Stripe 付款、訂單管理),請考慮是否需要自己建立。Shopify、WooCommerce,甚至 Saleor 的託管方案,都可能讓你更快上線,且持續維護負擔較小。

自訂 Python 平台適合以下情況:

  • 你的產品模型不尋常(可配置商品、組合商品、訂閱制、具有複雜交付機制的數位商品)
  • 你要建立多商家市集
  • 你需要與現有後端服務深度整合
  • 你想加入 ML 驅動的功能(推薦、動態定價、需求預測),並希望它們存在於同一份程式碼庫中

如果你無法清楚說明為什麼 Shopify 不適用於你,你可能解決了錯誤的問題。


框架比較:誠實版

Django

Django 是正確的預設選擇。不是因為它在每個面向都是最好的,而是因為它開箱即用地解決了商務的正確問題:

  • 具備 migrations 的 ORM → 你的產品與訂單模型從第一天起就已版本化
  • 管理後台介面 → 營運團隊無需碰觸程式碼即可管理庫存、訂單與客戶
  • 內建身份驗證 → 使用者註冊、登入、工作階段、權限
  • 表單處理與 CSRF 保護 → 安全性基礎已處理
# Django model for a basic product — you get admin, ORM queries, migrations for free
from django.db import models

class Product(models.Model):
    name = models.CharField(max_length=255)
    slug = models.SlugField(unique=True)
    price = models.DecimalField(max_digits=10, decimal_places=2)
    stock = models.PositiveIntegerField(default=0)
    is_active = models.BooleanField(default=True)
    created_at = models.DateTimeField(auto_now_add=True)

    class Meta:
        ordering = ['-created_at']

    def is_in_stock(self):
        return self.stock > 0

Enter fullscreen mode Exit fullscreen mode

這個模型可以立即查詢、立即在管理後台顯示,並立即進行遷移。這就是 Django 的價值主張。

Flask

Flask 是一種刻意的極簡選擇,而不是預設選項。你只會得到路由與請求處理。其他所有東西——ORM、身份驗證、表單驗證、快取、管理後台——都是你自己加入的函式庫。

# Flask requires you to wire everything manually
from flask import Flask, request, jsonify
from flask_sqlalchemy import SQLAlchemy
from flask_login import LoginManager

app = Flask(__name__)
db = SQLAlchemy(app)
login_manager = LoginManager(app)# You're assembling pieces; Django ships them assembled

Enter fullscreen mode Exit fullscreen mode

Flask 適合當你要在現有服務之上建立薄型 API 層,或是你的「電商平台」實際上只是建立在專有後端邏輯之上的專門結帳流程。在這些情況下,你不想要 Django 的意見——你想要自行組合。

Saleor

Saleor 是一個基於 Django、以 GraphQL 為先的電商框架。它確實已準備好上線,並內建付款處理、多幣別支援、產品目錄,以及基於 React 的儀表板。

權衡之處:你會繼承 Saleor 的資料模型。當你的需求符合時,這是一個重大的起步優勢。當它們不符合時,你就是在與框架對抗,而非與它合作。

如果你的需求在標準商務領域內,且希望快速前進,值得評估。

Oscar

Oscar 是另一個 Django 電商框架,在資料模型自訂方面比 Saleor 更具彈性。它被設計成可分叉與擴展——採用「分叉以自訂」的模式,而非「覆寫以自訂」。

# Oscar setup
pip install django-oscar
# Fork the app you want to customize
python manage.py oscar_fork_app catalogue myshop/

Enter fullscreen mode Exit fullscreen mode

Oscar 的產品抽象概念(產品類別、屬性、變體)可以在不需要修改綱要的情況下處理廣泛的產品結構。適合複雜的目錄。


八大核心功能——真正困難之處

1. 產品管理

對於簡單的目錄來說很簡單。當你遇到以下情況時,會快速變得複雜:

  • 產品變體(尺寸 × 顏色組合)
  • 可配置產品(客製化雕刻、組合選項)
  • 具有交付機制的數位產品
  • 具有不同稅務規則或運送配置的產品

Oscar 的產品模型開箱即用地很好地處理變體。如果你使用的是原始 Django,請在擁有真實資料之前仔細設計你的產品綱要——在有庫存的情況下遷移產品模型是痛苦的。

2. 身份驗證與安全性

Django 的身份驗證系統很穩固。針對商務的特定需求,請再加上:

# settings.py — minimum security baseline for an e-commerce platform
AUTH_PASSWORD_VALIDATORS = [
    {'NAME': 'django.contrib.auth.password_validation.MinimumLengthValidator', 
     'OPTIONS': {'min_length': 10}},
    {'NAME': 'django.contrib.auth.password_validation.CommonPasswordValidator'},
]

SESSION_COOKIE_SECURE = True       # HTTPS only
CSRF_COOKIE_SECURE = True
SECURE_HSSL_REDIRECT = True
X_FRAME_OPTIONS = 'DENY'

Enter fullscreen mode Exit fullscreen mode

管理後台存取的雙重驗證(django-two-factor-auth)、登入端點的速率限制,以及 GDPR/CCPA 合規性的適當 PII 處理,都是必要的附加功能。

3. 購物車與結帳

比看起來更複雜。你會面臨的購物車狀態問題:

  • 訪客購物車如何在登入時與已驗證使用者的購物車合併?
  • 如何在結帳期間處理庫存保留(軟保留 vs 硬保留)?
  • 當產品在工作階段中途缺貨時,購物車會發生什麼事?

如果你的結帳流程相當標準,請從 Saleor 或 Oscar 的結帳管道開始。這些邊緣案例已經被思考過了。

4. 付款整合

Stripe 是新專案的正確預設選擇。Python SDK 維護良好:

import stripe
stripe.api_key = settings.STRIPE_SECRET_KEY

def create_payment_intent(amount_cents, currency, metadata):
    return stripe.PaymentIntent.create(
        amount=amount_cents,
        currency=currency,
        metadata= metadata,
        automatic_payment_methods={"enabled": True},
    )

Enter fullscreen mode Exit fullscreen mode

要做好的是你的付款狀態模型,而不是選擇哪個閘道。付款流程有比外觀看起來更多的邊緣案例(扣款失敗、部分退款、爭議、webhook 順序錯亂)。請明確地對付款狀態進行建模,而不是從 webhook 歷史記錄推斷。

5. 訂單管理

營運骨幹。除了基本的狀態生命週期之外,你還需要退貨與退款、訂單編輯,以及履行整合。Django 的 ORM 讓資料建模保持乾淨:

class Order(models.Model):
    class Status(models.TextChoices):
        PENDING = 'pending', 'Pending'
        CONFIRMED = 'confirmed', 'Confirmed'
        PROCESSING = 'processing', 'Processing'
        SHIPPED = 'shipped', 'Shipped'
        DELIVERED = 'delivered', 'Delivered'
        CANCELLED = 'cancelled', 'Cancelled'
        REFUNDED = 'refunded', 'Refunded'

    user = models.ForeignKey(User, on_delete=models.PROTECT)
    status = models.CharField(max_length=20, choices=Status.choices, default=Status.PENDING)
    total = models.DecimalField(max_digits=10, decimal_places=2)
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)

Enter fullscreen mode Exit fullscreen mode

6. 搜尋與篩選

Django ORM 可以處理簡單的篩選。超出此範圍,請及早整合真正的搜尋引擎:

# Elasticsearch via elasticsearch-dsl-py
from elasticsearch_dsl import Document, Text, Keyword, Float

class ProductIndex(Document):
    name = Text(analyzer='english')
    category = Keyword()
    price = Float()

    class Index:
        name = 'products'

Enter fullscreen mode Exit fullscreen mode

Typesense 是一個更輕量的替代方案,具有良好的 Python 支援,且自我託管更容易。不要將此作為事後想法加入——將搜尋基礎設施改裝到現有資料管道中,比從一開始就建立它更困難。

7. 非同步任務——在你需要之前就設定好

這不在大多數功能清單中,但它應該在。電子郵件發送、webhook 處理、庫存更新、搜尋索引更新、報表生成——這些都不應該在請求週期中同步執行:

# Celery task for order confirmation email
from celery import shared_task
from django.core.mail import send_mail

@shared_task
def send_order_confirmation(order_id):
    order = Order.objects.get(id=order_id)
    send_mail(
        subject=f'Order #{order.id} confirmed',
        message=render_confirmation_email(order),
        from_email=settings.DEFAULT_FROM_EMAIL,
        recipient_list=[order.user.email],
    )

Enter fullscreen mode Exit fullscreen mode

Celery + Redis 是標準設定。及早加入它,因為之後再加入意味著要碰觸程式碼庫中目前以同步方式執行慢速操作的每個地方。

8. SEO

Django 在這方面表現出色——乾淨的 URL 路由、簡單的 meta 標籤控制、內建的網站地圖生成。django-meta 處理大部分的樣板:

# SEO-friendly URL structure
urlpatterns = [
    path('shop/<slug:category_slug>/<slug:product_slug>/', views.product_detail, name='product-detail'),
]
# Produces: /shop/mens-shoes/nike-air-max-90/ — clean, descriptive, indexable

Enter fullscreen mode Exit fullscreen mode

對於產品變體,請小心處理標準 URL,以避免重複內容的懲罰。


早期要做的架構決策

在撰寫後端程式碼之前選擇你的前端架構。 Django 模板(伺服器渲染)與 Django REST Framework + React 前端,會改變你結構化 URL、處理身份驗證(基於工作階段 vs JWT)以及如何將頁面傳遞給行動裝置的方式。兩者都可行——但在專案中途混合方法成本很高。

為你要前往的地方建模你的產品綱要,而不是你目前所在的地方。 如果你有任何機會擁有變體、組合商品或多種產品類型,請建立這種彈性。即使你不使用 Oscar,也值得研究 Oscar 的產品抽象概念。

從第一天起就設定非同步任務。 Celery + Redis。不要延後這件事。

及早設定搜尋基礎設施。 Elasticsearch 或 Typesense。不要日後才附加。


快速參考:框架選擇

情境 建議
標準商務,需要快速前進 Saleor
複雜目錄,需要彈性 Oscar
標準商務、綠地專案、完全控制 Django
在現有服務之上的薄型 API 層 Flask
到處都是非標準需求 從頭開始使用 Django

在 Innostax,我們已經在各種規模下交付了 Python 電商平台。 如果你正在進行商務建置的框架選擇或架構思考,請在此處聯絡我們——很樂意一起思考。

最初發表於 Innostax Engineering Blog