我读过的每一篇 Python 电商文章都遵循相同的结构:列出框架、列出功能,再加上一段结论说“Python 非常适合电商”。技术上准确,但如果你真的要构建一个系统,那就没什么用处。

本文将提供更实用的视角。我想讨论真正重要的决策——带有实际推理的框架选择、比看起来更难实现的功能、值得了解的代码模式,以及那些在早期就避免比后期修复容易得多的架构陷阱。


从这里开始:你真的需要自定义构建吗?

在讨论任何框架之前——如果你的电商需求是标准的(产品目录、购物车、结账、Stripe 支付、订单管理),请考虑是否需要自己构建。Shopify、WooCommerce,甚至 Saleor 的托管服务,可能让你更快上线,同时减少持续维护负担。

以下情况适合使用自定义 Python 方案:

  • 你的产品模型不寻常(可配置商品、捆绑销售、订阅模式、具有复杂交付机制的数字商品)
  • 你正在构建多供应商市场
  • 你需要与现有后端服务进行深度集成
  • 你想添加基于机器学习的功能(推荐、动态定价、需求预测),并希望这些功能与主代码库共存

如果你无法清楚说明为什么 Shopify 不适合你,那么你可能解决的是错误的问题。


框架对比:真实版本

Django

Django 是默认的正确选择。不是因为它在每个维度上都是最好的,而是因为它开箱即用地解决了电商所需的核心问题:

  • 带迁移的 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

当你正在构建一个覆盖现有服务的轻量 API 层,或者你的“电商平台”实际上是一个位于专有后端逻辑之上的专用结账流程时,Flask 是有意义的。在这些情况下,你不需要 Django 的“意见”,而是希望自行组合。

Saleor

Saleor 是一个基于 Django、优先使用 GraphQL 的电商框架。它真正具备生产就绪性,内置了支付处理、多币种支持、产品目录以及基于 React 的仪表板。

权衡之处:你会继承 Saleor 的数据模型。当你的需求符合标准电商领域时,这是一个显著的起点;当不符合时,你就是在与框架对抗而非合作。

如果你的需求在标准电商领域内,并且希望快速推进,值得评估。

Oscar

Oscar 是另一个基于 Django 的电商框架,在数据模型定制方面比 Saleor 更灵活。它设计为可被 fork 并扩展——采用“通过 fork 进行定制”的模式,而非“通过 override 进行定制”。

# 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 的产品抽象(产品类、属性、变体)能够处理广泛的产品结构,而无需修改 schema。适合复杂的目录。


八大核心功能——真正困难的部分

1. 产品管理

对于简单目录来说很简单。当你遇到以下情况时会迅速变得复杂:

  • 产品变体(尺寸 × 颜色组合)
  • 可配置产品(自定义雕刻、捆绑选项)
  • 具有交付机制的数字产品
  • 具有不同税率规则或配送配置的产品

Oscar 的产品模型开箱即用地很好地处理变体。如果你使用原生 Django,请在拥有真实数据之前仔细设计产品 schema——在已有库存的情况下迁移产品模型会非常痛苦。

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、如何处理身份验证(基于会话还是 JWT),以及如何向移动端交付页面。两种方式都可行——但在项目中途混用方法成本高昂。

为未来而非现在设计产品 schema。如果将来有可能出现变体、捆绑或多种产品类型,请提前构建这种灵活性。即使不使用 Oscar,也值得研究其产品抽象。

从第一天起就设置异步任务。Celery + Redis。不要推迟。

尽早搭建搜索基础设施。Elasticsearch 或 Typesense。不要事后添加。


快速参考:框架选择

场景 推荐方案
标准电商需求,需要快速上线 Saleor
复杂目录,需要灵活性 Oscar
标准电商需求,绿地项目,需要完全控制 Django
在现有服务之上构建轻量 API 层 Flask
到处都是非标准需求 从零开始使用 Django

在 Innostax,我们已交付了不同规模的 Python 电商平台。如果你正在为电商项目进行框架选择或架构设计,欢迎在此联系我们——我们很乐意一起探讨。

原文发布于 Innostax 工程博客