团购网站源码的商品、订单和支付流程怎么梳理

团购网站的业务看起来像“选商品、下单、付款”，实际还要处理团购活动、库存占用、人数门槛、支付回调和退款等状态。只沿着页面按钮或接口名称读代码，容易把“订单已创建”“支付成功”和“团购已成团”混为一谈，进而造成超卖、重复发货或退款遗漏。

梳理源码时，建议先回答三个问题：商品和活动分别存什么；订单在哪个时点占用库存、何时算支付成功；支付完成后，系统根据什么规则判断成团并履约。下面从领域关系、状态边界、代码实现和排查方法展开。示例以普通限时团购为背景，适合用于理解单店或中小型团购项目，不代表所有平台都采用相同规则。

一、先分清商品、团购活动、订单和支付

这四类数据相关，但不应当是同一件事。

• 商品描述可售的货品，例如名称、规格、图片、基础售价和商品状态。商品回答“卖什么”。
• 团购活动描述某个时间段内的售卖规则，例如活动价、起止时间、成团人数、每人限购数量和活动库存。活动回答“这次怎么卖”。
• 订单是一次购买意图及其价格快照，记录购买数量、应付金额、收货信息和业务状态。订单回答“买家这次买了什么”。
• 支付记录关联支付渠道的交易号、金额、支付状态等信息。支付记录回答“款项是否到账”。

用户看到的商品详情可以组合商品与活动信息，但下单时不能只保存商品 ID。活动价、商品名称、规格、数量和应付金额等关键数据应写入订单快照。否则商品改名、改价后，历史订单展示和对账可能跟着变化。

价格必须由服务端依据数据库中的商品、活动规则及优惠计算。前端传来的商品 ID、数量、优惠券 ID 可以作为请求参数，但前端展示的单价和总价不能作为可信依据。金额应使用整数的最小货币单位（例如按分存储），或使用有明确精度的十进制类型；不要用二进制浮点数直接计算钱。

二、先画状态，再读接口和表结构

建议先把两条状态线分开，再观察它们如何关联。

订单状态

• 待支付：订单已生成，等待付款；是否已占库存要由项目规则明确。
• 已支付：支付已由可信渠道确认，或由服务端查询渠道后确认。
• 已取消、已关闭：用户取消或超时关闭。关闭后不能再按普通流程付款。
• 退款中、已退款：退款是独立的资金流程，不应简单把订单状态改回“未支付”。

团购活动或团次状态

一种常见设计是把具体一团建模为独立的“团次”：买家加入某个团次，团次有成团人数、已支付人数、截止时间及状态。团次可处于进行中、已成团、失败等状态。也有项目按活动汇总人数，再由后台或定时任务判定是否成团。读源码时要确认项目采用哪种口径，不能把“活动剩余库存”和“某一团还差几人”当作同一个字段。

例如，买家创建订单时，订单可能只是待支付，并不计入成团人数；只有确认支付后，才算有效参团。若团次已失败，后来到达的支付通知不能直接让它重新成团，必须走项目定义的迟到支付处理策略，例如自动退款或人工处理。

把规则写成状态转换表，比凭接口名字猜业务更可靠：

三、检查商品和活动的数据边界

查看数据库表或 ORM 模型时，重点找出这些信息分别存在哪里：

• 商品是否有上下架状态、规格与库存；库存是按商品、SKU 还是活动独立维护。
• 活动是否有起止时间、活动价、限购规则、成团条件和活动库存。
• 订单是否保存了商品、规格、价格、数量、收货信息的快照。
• 支付表是否单独保存渠道订单号、渠道交易号、金额、币种及状态。
• 退款是否有单独的退款单和渠道退款号，还是仅靠订单字段表达。

库存模型要能回答“扣的是哪一份库存”。若活动库存独立于商品库存，售卖判断可能同时受两者约束；若库存按 SKU 管理，则仅检查商品总库存可能不够。还要厘清库存的“可售、已占用、已售出”定义：有些系统创建订单时预占库存，支付后将占用转为售出；另一些系统在支付成功时才扣库存。两种方案都可能成立，但释放条件和并发控制必须配套。

一个容易被忽略的边界是订单创建时记录规则快照。订单在 10:00 创建、10:05 支付时，活动可能已结束或价格已调整。系统要依据下单时的有效价格和规则，还是在支付时重新判断，需由业务明确。通常已成功创建且仍在支付期限内的订单会按订单快照支付，但具体要求以项目约定和支付单生成逻辑为准。

四、订单创建的关键是原子性和重复请求

创建订单一般要在同一个可靠的事务边界里完成：校验活动与数量、锁定或条件更新库存、计算金额、写订单及订单明细。不能先查“库存大于零”，隔一段时间再无条件扣减；两个并发请求可能同时读到同一份库存。

下面是一个可运行的 Python 3 标准库示例，使用 SQLite 展示原子扣减库存和订单创建。示例中的金额单位为分；活动开始和结束时间使用 Unix 时间戳；活动库存采用“创建待支付订单时预占，订单取消时释放”的简化策略。SQLite 的 BEGIN IMMEDIATE 会先取得写事务锁，适合这个小型示例；生产环境应结合实际数据库和并发模型设计，不要把它当作所有数据库的通用锁方案。

import sqlite3
import time
import uuid

DB = "groupbuy_demo.sqlite3"

def connect():
    conn = sqlite3.connect(DB, timeout=10)
    conn.row_factory = sqlite3.Row
    return conn

def init_db():
    with connect() as db:
        db.executescript("""
        CREATE TABLE IF NOT EXISTS campaigns (
            id INTEGER PRIMARY KEY,
            name TEXT NOT NULL,
            price_cents INTEGER NOT NULL CHECK(price_cents >= 0),
            stock_available INTEGER NOT NULL CHECK(stock_available >= 0),
            starts_at INTEGER NOT NULL,
            ends_at INTEGER NOT NULL,
            active INTEGER NOT NULL DEFAULT 1
        );

        CREATE TABLE IF NOT EXISTS orders (
            id TEXT PRIMARY KEY,
            campaign_id INTEGER NOT NULL,
            quantity INTEGER NOT NULL CHECK(quantity > 0),
            unit_price_cents INTEGER NOT NULL CHECK(unit_price_cents >= 0),
            total_cents INTEGER NOT NULL CHECK(total_cents >= 0),
            status TEXT NOT NULL,
            created_at INTEGER NOT NULL,
            FOREIGN KEY(campaign_id) REFERENCES campaigns(id)
        );
        """)
        db.execute(
            """INSERT OR IGNORE INTO campaigns
               (id, name, price_cents, stock_available, starts_at, ends_at, active)
               VALUES (1, '示例团购', 1290, 20, ?, ?, 1)""",
            (int(time.time()) - 60, int(time.time()) + 3600)
        )

def create_order(campaign_id, quantity):
    # 这里只演示服务端基础校验；具体限购数应按业务配置并在服务端执行。
    if isinstance(quantity, bool) or not isinstance(quantity, int):
        raise ValueError("quantity 必须是整数")
    if quantity < 1 or quantity > 10:
        raise ValueError("本示例允许购买 1 到 10 件")

    now = int(time.time())
    order_id = uuid.uuid4().hex

    with connect() as db:
        db.execute("BEGIN IMMEDIATE")
        campaign = db.execute(
            "SELECT * FROM campaigns WHERE id = ?", (campaign_id,)
        ).fetchone()

        if campaign is None:
            raise ValueError("活动不存在")
        if not campaign["active"] or not (campaign["starts_at"] <= now < campaign["ends_at"]):
            raise ValueError("活动当前不可购买")

        changed = db.execute(
            """UPDATE campaigns
               SET stock_available = stock_available - ?
               WHERE id = ? AND stock_available >= ?""",
            (quantity, campaign_id, quantity)
        ).rowcount
        if changed != 1:
            raise ValueError("库存不足")

        unit_price = campaign["price_cents"]
        total = unit_price * quantity
        db.execute(
            """INSERT INTO orders
               (id, campaign_id, quantity, unit_price_cents, total_cents, status, created_at)
               VALUES (?, ?, ?, ?, ?, 'pending_payment', ?)""",
            (order_id, campaign_id, quantity, unit_price, total, now)
        )
        return {"order_id": order_id, "total_cents": total}

if __name__ == "__main__":
    init_db()
    print(create_order(1, 2))

保存为 demo.py 后运行 python demo.py 即可创建示例数据库和一笔订单。示例中的 1 到 10 件是为了演示输入校验而设置的业务限制，不是 Python、SQLite 或团购系统的通用上限；实际限制应由产品规则配置，并在服务端验证。

这个示例只演示订单创建，未实现用户身份、SKU、地址、优惠券、支付、团次、超时任务和退款。真实项目不能只依赖页面限制购买数量，也不能把示例的“扣减可用库存”直接当作完整库存方案。特别是用户重复点击或网络重试时，应考虑幂等键：同一用户在限定时间内携带相同请求标识再次提交，返回既有结果，而不是重复创建订单。幂等键应由服务端约束其作用范围与有效期，并对重复请求参数进行一致性校验。

五、支付不是前端跳转成功，而是服务端确认

发起支付时，服务端应根据自己的订单记录创建或获取支付单，明确订单号、应付金额和币种，再调用支付渠道。不要相信浏览器传回的“支付成功”页面参数；用户可能直接访问成功页，或修改请求内容。页面跳转适合展示结果，不适合作为到账凭证。

支付结果通常由渠道异步通知，也可以由服务端主动查询渠道交易状态补偿。收到通知后，至少需要按支付渠道的接入规范完成签名或其他认证校验；再检查商户、订单号、金额、币种、渠道交易状态及通知所对应的业务关系。签名校验只能证明通知符合渠道定义的认证机制，不会自动替代金额核对、订单状态检查或业务授权。

具体签名字段、算法、证书处理、通知响应格式和重试规则都由渠道文档决定，不能用一个通用代码片段替代。不要自行猜测签名参数顺序，也不要把验签密钥放在浏览器、日志或公开仓库里。接收通知的接口还应使用 HTTPS，并按渠道要求保护密钥、证书及运行环境。

回调处理至少应满足的条件

1. 先解析并按渠道规范验证通知，验证失败不得改订单为已支付。
2. 通过渠道订单号找到本地支付单和订单，并核对金额、币种、商户等信息。
3. 在数据库事务中记录支付事件、更新支付单和订单；重复通知不能重复累计成团人数、扣库存或触发发货。
4. 对并发通知使用唯一约束、条件更新或行锁等手段，确保同一笔交易只有一次业务效果。
5. 只有在业务状态已可靠落库后，才按渠道要求返回成功响应；若处理失败，应根据渠道重试机制和接口约定设计恢复方式。

可把通知事件表设置为渠道与事件编号的唯一组合，或对渠道交易号设置适当约束。若渠道会重复发送同一笔支付通知，幂等处理的目标不是“拒收重复请求”，而是“重复请求不会产生第二次业务副作用”。第一次处理成功后，后续相同事件可以返回成功，但仍应以数据库状态为准。

六、付款、成团和履约之间要有明确边界

“订单已支付”不一定等于“团购已成团”，更不一定等于“可以发货”。例如，活动规定达到 5 人成团，某订单支付后团次只有 4 人，此时款项已确认，但团次仍可能处于进行中。系统要根据规则决定等待其他成员、截止后失败退款，还是采用其他安排。

团次人数应统计符合规则的有效订单，例如已支付且未退款的订单。若用户部分退款、整单退款、支付后取消或支付通知迟到，是否继续计入人数，需要明确。退款成功后若要减少成团人数，也要处理已经开始履约的情况，不能只在订单页面上改一个状态。

在分布式系统中，数据库事务不能同时原子地覆盖本地数据库和外部支付渠道。常见做法是先在本地事务中可靠记录待执行事项，再由后台任务调用外部服务；或者在业务事务提交后通过消息队列推进后续步骤。对于“订单支付成功后通知仓库”这类动作，可使用事务性发件箱（outbox）思路：订单状态和待发送事件写在同一数据库事务里，后台任务再可靠投递，并对消费者做幂等。这样可以降低“订单已更新但消息没发出去”的概率。

七、超时关闭、库存释放与退款不要混为一谈

待支付订单通常有支付期限。超时任务应先确认订单仍处于待支付、截止时间确已过去，再在事务中关闭订单并按库存策略释放占用。若支付成功和超时任务并发，必须通过条件更新或锁保证只有一个合法转换先落地。不能因为定时任务扫描到了旧数据，就无条件把已支付订单关闭。

更棘手的是超时关闭之后才收到支付成功通知。系统需要区分“通知重复”和“真实的迟到到账”：核对渠道支付状态后，根据业务规则继续履约、拒绝履约并发起退款，或转人工处理。无论采用哪种策略，都应记录原因和处理结果，保留订单、支付与退款之间的关联，方便客服和财务核对。

退款应单独追踪申请、处理中、成功、失败等结果，并保存渠道退款号及金额。发起退款成功不一定代表退款已经到账；应按渠道通知或查询结果更新状态。部分退款还要校验累计退款金额，不能超过可退款金额。订单“已退款”这样的简化状态，通常不足以表达多次或部分退款的完整过程。

八、常见错误与排查顺序

• 把前端价格当权威：检查下单接口是否重新读取活动价格并在服务端计算总额。
• 库存先查后扣：检查扣减是否有原子条件、事务或适当锁，并观察并发下是否可能出现负库存。
• 支付成功页直接改状态：搜索订单状态更新入口，确认只有通过可信支付确认的服务端流程能够标记到账。
• 回调不幂等：检查是否有支付事件去重、状态条件更新和唯一约束；重复通知时观察人数、库存和发货记录是否重复变化。
• 只有订单状态，没有支付单：排查渠道订单号、交易号、支付金额和退款记录是否丢失，避免对账困难。
• 超时任务无条件关单：检查关单条件是否包含当前状态、到期时间，支付与关闭并发时是否能安全处理。
• 活动库存和团次人数混用：明确库存是可销售数量，人数是符合参团规则的订单数，分别定义更新时机。
• 订单没有价格快照：商品或活动改价后检查历史订单金额、订单详情和退款计算是否仍然正确。
• 只测试顺序流程：补充重复提交、回调重试、支付与超时并发、库存耗尽、退款失败和团次截止等测试。

排查时可以从入口开始：找到创建订单接口，沿着调用链追踪价格计算、库存更新和订单写入；再找到支付单创建与回调入口，检查验签、金额核对、状态更新及后续事件；最后追踪定时任务、退款流程和履约消费者。阅读每个状态更新处时都问一句：谁能触发、前置状态是什么、是否处于事务中、重试会发生什么。

九、上线前的最小检查清单

• 价格由服务端计算，订单保存足够的商品与价格快照；金额使用明确的精度。
• 购买数量、活动时间、限购规则和库存都在服务端校验，具体范围来自业务配置。
• 并发扣库存有原子保护，取消订单和释放库存也有对应的幂等保护。
• 重复创建请求、重复支付通知和重复退款通知都不会造成重复副作用。
• 支付成功来自渠道验签通知或服务端查询确认，不由前端跳转结果决定。
• 订单、支付、团次、退款各有清晰状态和可追踪的关联编号。
• 超时关闭与支付并发、成团失败与迟到支付、退款失败等情况有明确处理策略。
• 日志不记录密钥或不必要的敏感支付数据，并可按订单号、渠道交易号追查。

梳理团购源码的重点不在于先找到某个“下单接口”，而在于还原状态转换和数据责任：商品与活动提供规则，订单保存购买事实，支付记录证明资金状态，团次决定成团条件，退款与履约处理后续结果。把每次状态变更的前置条件、事务边界、重试行为和失败补偿写清楚，再回到代码逐项验证，通常比从页面一路猜到数据库更快，也更不容易漏掉并发和异常场景。