简介这是一套基于Python Django框架开发的完整电商购物商城系统含支付宝支付功能适用于计算机相关专业学生毕设、课程设计或初学者项目实践。资源包含可直接运行的源码、数据库脚本、详细文档说明及配套前端页面覆盖用户注册激活、登录、个人中心、商品展示、搜索、购物车管理、订单提交与支付全流程。压缩包共295个文件以45个Python后端逻辑文件、36个HTML模板页、20个PNG/JPG图片资源、10个JS交互脚本及4个CSS样式文件为主辅以SQL数据库导出、DOCX说明文档和配置文件整体11.92MB结构清晰、模块解耦明确。已有303人学习下载代码经实际测试运行无误答辩平均分达96分附带README指引与远程答疑支持适合从零入门到二次开发进阶使用。1. 这不是一个“拿来就能上线”的商城而是一套可拆解、可验证、可进化的 Django 支付闭环实践样本你下载的这个名为“Python基于Django带支付宝支付电商购物商城网站源代码文档说明数据库.zip”的压缩包本质不是成品软件而是面向 Python Web 开发者的一套支付集成教学型工程骨架。它不解决高并发库存扣减或分布式事务但完整呈现了从用户下单、生成支付订单、调用支付宝开放平台接口、接收异步通知、更新订单状态到前端轮询展示结果的全链路逻辑。适合两类人一是刚学完 Django Model/View/Template 的新手想把“书本上的视图函数”变成“能真实跳转到支付宝收银台”的可交互流程二是已有项目需快速接入支付宝 PC 网页支付非 App 或小程序的工程师可直接提取alipay相关模块、信号处理机制和回调路由设计。它默认使用 SQLite但所有数据库操作均通过 Django ORM 实现迁移到 MySQL 或 PostgreSQL 仅需修改settings.py中的DATABASES配置——这正是其作为学习样本的核心价值支付逻辑与数据层解耦业务流程可复用技术选型可替换。2. 拆解支付宝支付在 Django 中的三层落地结构配置、签名、回调支付宝支付不是简单调个 URL 就能完成它依赖一套严格的身份认证与消息防篡改机制。该商城项目将这一过程拆解为三个可独立验证的层级全局配置初始化、支付请求签名生成、异步通知验签与状态更新。这三层不是线性执行而是构成一个闭环校验体系——缺少任一环支付就无法安全落地。2.1 初始化支付宝 SDK 并注入 Django 配置体系项目中通常存在一个alipay_config.py或直接在settings.py中定义支付宝参数。但真正可靠的做法是将其封装为 Django App 的配置类避免硬编码密钥。常见做法是创建payment/alipay_config.py# payment/alipay_config.py from django.conf import settings class AlipayConfig: APP_ID getattr(settings, ALIPAY_APP_ID, 2021000123456789) APP_PRIVATE_KEY_PATH getattr(settings, ALIPAY_APP_PRIVATE_KEY_PATH, payment/keys/app_private_key.pem) ALIPAY_PUBLIC_KEY_PATH getattr(settings, ALIPAY_ALIPAY_PUBLIC_KEY_PATH, payment/keys/alipay_public_key.pem) GATEWAY_URL getattr(settings, ALIPAY_GATEWAY_URL, https://openapi.alipay.com/gateway.do) classmethod def get_private_key(cls): with open(cls.APP_PRIVATE_KEY_PATH, r) as f: return f.read() classmethod def get_alipay_public_key(cls): with open(cls.ALIPAY_PUBLIC_KEY_PATH, r) as f: return f.read()注意APP_PRIVATE_KEY_PATH和ALIPAY_PUBLIC_KEY_PATH必须指向 PEM 格式密钥文件且私钥文件权限应设为600Linux/macOS 下chmod 600 app_private_key.pem防止被 Web 服务器意外暴露。Django 启动时若读取失败会抛出IOError这是第一道安全拦截。2.2 构建支付请求并生成带签名的跳转 URL用户点击“去支付”后后端需构造符合支付宝规范的请求参数并用应用私钥签名。关键不在拼接字符串而在参数排序、空值过滤、UTF-8 编码、签名算法选择。项目中常见实现位于views.py的下单视图内# views.py from alipay import AliPay from payment.alipay_config import AlipayConfig from django.urls import reverse from django.http import JsonResponse, HttpResponseRedirect def create_order(request): if request.method POST: # 1. 创建订单记录省略 ORM 保存逻辑 order_no fORD{int(time.time())}{request.user.id:06d} amount Decimal(99.90) # 2. 初始化支付宝 SDK 实例 alipay AliPay( appidAlipayConfig.APP_ID, app_notify_urlrequest.build_absolute_uri(reverse(alipay_notify)), return_urlrequest.build_absolute_uri(reverse(alipay_return)), app_private_key_stringAlipayConfig.get_private_key(), alipay_public_key_stringAlipayConfig.get_alipay_public_key(), sign_typeRSA2, # 必须为 RSA2SHA256withRSA debugFalse # 生产环境必须设为 False ) # 3. 构造支付参数注意subject 必须 UTF-8 编码不能含特殊符号 params { out_trade_no: order_no, total_amount: str(amount), subject: Python Django 商城商品, product_code: FAST_INSTANT_TRADE_PAY } # 4. 生成支付链接关键get_gateway_url 返回的是重定向 URL pay_url alipay.api_alipay_trade_page_pay(**params) gateway AlipayConfig.GATEWAY_URL redirect_url f{gateway}?{pay_url} return JsonResponse({redirect_url: redirect_url})参数说明与避坑点app_notify_url必须是公网可访问的绝对路径支付宝服务器会向此地址发起 POST 请求不是浏览器跳转用于异步通知支付结果return_url用户支付完成后支付宝控制台页面跳转回的地址仅作前端展示不可用于更新订单状态易被伪造sign_typeRSA2支付宝自 2019 年起强制要求使用 RSA2SHA256withRSA旧版 RSA 已停用若填错将返回INVALID_PARAMETER错误product_codeFAST_INSTANT_TRADE_PAY表示普通即时到账交易适用于实物商品不可用于虚拟商品或分账场景。2.3 处理支付宝异步通知验签、幂等、状态更新三步不可少支付宝的notify_url是整个支付链路中最易出错的环节。开发者常犯错误包括未验签直接更新订单、未判断trade_status字段、未做幂等处理导致重复发货。标准处理流程如下# views.py from django.views.decorators.csrf import csrf_exempt from django.http import HttpResponse import json csrf_exempt def alipay_notify(request): if request.method POST: # 1. 获取原始 POST 数据不能用 request.POST因支付宝发送的是 form-data 且含 sign 字段 body_str request.body.decode(utf-8) post_data dict(urllib.parse.parse_qsl(body_str)) # 2. 提取 sign 和 sign_type用于验签 sign post_data.pop(sign, None) sign_type post_data.pop(sign_type, None) # 3. 初始化 SDK同上 alipay AliPay( appidAlipayConfig.APP_ID, app_notify_urlrequest.build_absolute_uri(reverse(alipay_notify)), return_urlrequest.build_absolute_uri(reverse(alipay_return)), app_private_key_stringAlipayConfig.get_private_key(), alipay_public_key_stringAlipayConfig.get_alipay_public_key(), sign_typeRSA2, debugFalse ) # 4. 验签核心必须传入原始未 decode 的字节流或正确解析后的 dict result alipay.verify(post_data, sign) if result and post_data.get(trade_status) TRADE_SUCCESS: # 5. 幂等处理检查 out_trade_no 是否已存在成功支付记录 order_no post_data.get(out_trade_no) try: order Order.objects.get(order_noorder_no) if order.status ! paid: order.status paid order.pay_time timezone.now() order.save() # 触发库存扣减、物流单生成等后续动作建议用 Celery 异步 from .tasks import deduct_inventory deduct_inventory.delay(order.id) return HttpResponse(success) # 必须返回 success 字符串否则支付宝持续重发 except Order.DoesNotExist: return HttpResponse(fail) else: return HttpResponse(fail) return HttpResponse(fail)关键逻辑说明csrf_exempt是必需的因为支付宝服务器不会携带 CSRF tokenalipay.verify(post_data, sign)内部会自动按字母序对post_datakey 排序、拼接、验签传入的post_data必须不含sign和sign_type字段trade_status TRADE_SUCCESS是唯一可信的成功状态TRADE_FINISHED表示交易关闭如退款不可视为支付成功返回success是硬性协议要求支付宝收到后停止重试返回其他任何内容包括空字符串、HTML 页面都会触发每 2m/4m/6m/9m/15m/30m/60m/120m/240m 共 13 次重发。3. 数据库设计与订单状态机从 SQLite 到生产环境的迁移路径该商城的数据库结构虽以 SQLite 为默认载体但其表设计已预留生产级扩展能力。核心在于Order模型的状态字段设计与外键约束策略而非具体数据库类型。理解其状态流转逻辑是将 demo 升级为可用系统的前提。3.1 订单模型的关键字段与状态枚举定义项目中models.py的Order类通常包含以下不可简化的字段组合# models.py from django.db import models from django.contrib.auth.models import User class Order(models.Model): STATUS_CHOICES ( (created, 待支付), (paid, 已支付), (shipped, 已发货), (completed, 已完成), (cancelled, 已取消), ) user models.ForeignKey(User, on_deletemodels.CASCADE, verbose_name用户) order_no models.CharField(max_length64, uniqueTrue, verbose_name订单号, db_indexTrue) total_amount models.DecimalField(max_digits10, decimal_places2, verbose_name总金额) status models.CharField(max_length20, choicesSTATUS_CHOICES, defaultcreated, verbose_name状态) pay_time models.DateTimeField(nullTrue, blankTrue, verbose_name支付时间) created_at models.DateTimeField(auto_now_addTrue, verbose_name创建时间) updated_at models.DateTimeField(auto_nowTrue, verbose_name更新时间) class Meta: ordering [-created_at] verbose_name 订单 verbose_name_plural 订单字段设计意图解析order_no设为uniqueTrue且添加db_indexTrue确保高并发下单时生成唯一订单号如ORD20240520123456789并加速按订单号查询status使用choices而非整数枚举便于 Django Admin 展示中文状态且避免魔法数字如1,2带来的维护风险pay_time允许为空仅在status paid时才写入作为支付成功的事实时间戳而非updated_at后者会被任何更新操作刷新created_at与updated_at分离created_at固定为订单创建时刻updated_at反映最后修改时间二者共同支撑订单生命周期分析。3.2 从 SQLite 迁移到 MySQL 的实操步骤与参数调优SQLite 仅适用于开发与测试生产环境必须切换至 MySQL或 PostgreSQL。迁移本身只需两步但配套优化决定系统稳定性# 步骤 1修改 settings.py 中的 DATABASES 配置 DATABASES { default: { ENGINE: django.db.backends.mysql, NAME: django_shop, USER: shop_user, PASSWORD: StrongPass123!, HOST: 127.0.0.1, PORT: 3306, OPTIONS: { init_command: SET sql_modeSTRICT_TRANS_TABLES, charset: utf8mb4, }, TEST: { CHARSET: utf8mb4, COLLATION: utf8mb4_unicode_ci, } } }# 步骤 2安装 mysqlclient 并执行迁移 pip install mysqlclient python manage.py makemigrations python manage.py migrateMySQL 关键参数说明需在 my.cnf 中配置参数推荐值作用innodb_buffer_pool_size物理内存的 50%~70%InnoDB 缓存池直接影响读写性能必须调大max_connections≥ 500防止高并发时连接数耗尽Django 默认CONN_MAX_AGE0会频繁新建连接wait_timeout288008小时避免 MySQL 主动断开空闲连接与 DjangoCONN_MAX_AGE配合使用character-set-serverutf8mb4支持 emoji 及四字节 Unicode 字符utf8在 MySQL 中实际为 utf8mb3已过时提示若使用宝塔面板部署 Django需在 MySQL 管理界面中手动执行ALTER DATABASE django_shop CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;再对每个表执行ALTER TABLE xxx CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;否则中文可能乱码。3.3 订单状态变更的原子性保障数据库事务 vs 应用层锁当用户支付成功后需同时更新订单状态、扣减库存、生成物流单。若用多个.save()分散操作可能因异常导致状态不一致。正确做法是将关键操作包裹在数据库事务中# views.py 或 services.py from django.db import transaction def handle_payment_success(order_no): try: with transaction.atomic(): # 1. 锁定订单行SELECT FOR UPDATE order Order.objects.select_for_update().get(order_noorder_no) if order.status ! created: raise ValueError(订单状态非法无法重复支付) # 2. 更新订单 order.status paid order.pay_time timezone.now() order.save() # 3. 扣减库存假设商品在 Product 表中 product order.items.first().product if product.stock order.items.aggregate(total_qtySum(quantity))[total_qty]: raise ValueError(库存不足) product.stock - order.items.aggregate(total_qtySum(quantity))[total_qty] product.save() # 4. 记录支付日志可选 PaymentLog.objects.create( orderorder, amountorder.total_amount, payment_methodalipay, statussuccess ) except Exception as e: # 事务自动回滚 logger.error(f支付成功处理失败: {e}) raise为什么select_for_update()不可替代它在数据库层面加行锁阻止其他事务同时修改同一订单避免“ABA 问题”即两次读取status均为created但中间已被其他请求改为paid注意select_for_update()仅在transaction.atomic()块内生效且要求数据库引擎为 InnoDB。4. 支付回调验证失败的五大高频原因与逐项排查清单即使代码逻辑无误支付宝支付回调仍可能持续返回fail导致订单长期卡在“待支付”。这不是代码 Bug而是环境、配置、网络协同问题。以下是生产环境中最常出现的五类原因附带可立即执行的验证命令。4.1 验证支付宝公钥是否与沙箱/正式环境匹配支付宝提供两套密钥沙箱环境密钥用于开发测试和正式环境密钥上线后使用。若alipay_public_key.pem文件内容与当前使用的网关openapi.alipaydev.comvsopenapi.alipay.com不匹配alipay.verify()永远返回False。验证步骤登录 支付宝开放平台 → 进入对应应用 → 查看“接口加签方式”下的公钥内容将其与本地alipay_public_key.pem文件内容逐行比对注意PEM 文件首尾含-----BEGIN PUBLIC KEY-----和-----END PUBLIC KEY-----若不一致重新下载并覆盖本地文件。# 快速比对命令Linux/macOS openssl x509 -pubkey -noout -in payment/keys/alipay_public_key.pem | sha256sum # 将输出的哈希值与开放平台后台显示的公钥指纹对比4.2 检查app_notify_url是否可被支付宝服务器访问支付宝服务器位于阿里云杭州节点其 IP 段会动态变化。若你的 Django 服务部署在本地或内网或 Nginx/Apache 配置了allow/deny规则会导致通知请求被拒绝。验证方法在 Django 日志中搜索Invalid HTTP_HOST header或DisallowedHost错误临时在settings.py中添加ALLOWED_HOSTS [*] # 仅调试用上线前必须限定域名 LOGGING { version: 1, handlers: {console: {class: logging.StreamHandler}}, loggers: {django.security.DisallowedHost: {handlers: [console], level: ERROR}}, }使用 curl 模拟支付宝请求需替换为你的真实 notify URLcurl -X POST https://yourdomain.com/payment/notify/ \ -H Content-Type: application/x-www-form-urlencoded \ -d out_trade_noTEST123 \ -d trade_statusTRADE_SUCCESS \ -d signxxx \ -d sign_typeRSA24.3 确认时间戳是否同步误差 ≤ 15 分钟支付宝验签时会校验timestamp参数若存在及请求到达时间。若服务器时间与支付宝服务器偏差过大超过 15 分钟验签失败。校准命令# Ubuntu/Debian sudo apt install ntp sudo systemctl enable ntp sudo systemctl start ntp # CentOS/RHEL sudo yum install chrony sudo systemctl enable chronyd sudo systemctl start chronyd # 验证同步状态 timedatectl status | grep System clock synchronized # 输出 yes 表示已同步4.4 排查 Django 中间件对 POST 数据的篡改某些安全中间件如django.middleware.csrf.CsrfViewMiddleware或 WSGI 服务器如 uWSGI配置不当会修改原始 POST body导致alipay.verify()计算的签名与支付宝发送的不一致。快速定位在alipay_notify视图开头添加日志logger.info(fRaw POST body: {request.body[:200]}) logger.info(fParsed POST data keys: {list(post_data.keys())})对比日志中body与post_data是否丢失字段如sign被截断、被转义为amp;若发现异常检查MIDDLEWARE设置确保CsrfViewMiddleware在alipay_notify路由前被跳过已用csrf_exempt。4.5 检查ALIPAY_APP_PRIVATE_KEY_PATH文件路径与权限私钥文件路径错误或权限过高如755会导致alipaySDK 读取失败verify()方法内部静默返回False。验证脚本# test_key.py from payment.alipay_config import AlipayConfig try: key AlipayConfig.get_private_key() print(✅ 私钥读取成功长度:, len(key)) except Exception as e: print(❌ 私钥读取失败:, e)运行python test_key.py若报错Permission denied执行chmod 600 payment/keys/app_private_key.pem chown www-data:www-data payment/keys/app_private_key.pem # Ubuntu/Debian # 或 chown nginx:nginx payment/keys/app_private_key.pem # CentOS/RHEL5. 前端支付跳转与轮询方案脱离 iframe用 fetch setInterval 实现轻量级状态同步该商城的前端支付流程通常采用最简方案后端返回跳转 URL前端window.location.href直接跳转。但用户支付完成后返回return_url时订单状态尚未更新因异步通知有延迟需前端主动轮询确认。这里提供一个不依赖 jQuery、兼容现代浏览器的轻量实现。5.1 构建可中断的轮询函数与状态映射表轮询不是无脑setInterval需支持超时、失败重试、手动终止。核心是将支付宝trade_status映射为前端可读状态// static/js/payment.js function pollOrderStatus(orderNo, maxRetries 10, interval 3000) { let retryCount 0; let pollingId null; const checkStatus () { fetch(/api/order/status/?order_no${orderNo}) .then(response response.json()) .then(data { if (data.status paid) { clearInterval(pollingId); showSuccessMessage(); } else if (data.status cancelled) { clearInterval(pollingId); showCancelMessage(); } else if (retryCount maxRetries) { clearInterval(pollingId); showTimeoutMessage(); } else { retryCount; } }) .catch(error { console.warn(轮询请求失败重试中..., error); if (retryCount maxRetries) { retryCount; } else { clearInterval(pollingId); showNetworkErrorMessage(); } }); }; pollingId setInterval(checkStatus, interval); return () clearInterval(pollingId); // 返回取消函数 } // 状态映射表与后端 Order.STATUS_CHOICES 保持一致 const STATUS_MAP { created: 订单已创建等待支付, paid: 支付成功订单已确认, shipped: 商品已发出正在配送, completed: 订单已完成, cancelled: 订单已取消 };5.2 后端提供幂等的状态查询 API前端轮询必须对接一个无副作用的只读接口该接口应直接查库不触发任何业务逻辑# views.py from django.http import JsonResponse from django.views.decorators.http import require_http_methods require_http_methods([GET]) def order_status_api(request): order_no request.GET.get(order_no) if not order_no: return JsonResponse({error: 缺少 order_no 参数}, status400) try: order Order.objects.get(order_noorder_no) return JsonResponse({ status: order.status, message: STATUS_MAP.get(order.status, 未知状态), pay_time: order.pay_time.isoformat() if order.pay_time else None }) except Order.DoesNotExist: return JsonResponse({error: 订单不存在}, status404)路由配置urls.pyurlpatterns [ # ... 其他路由 path(api/order/status/, views.order_status_api, nameorder_status_api), ]5.3 在return_url页面启动轮询并绑定取消逻辑用户从支付宝返回后页面需自动开始轮询并在用户关闭页面时清理定时器!-- templates/payment/return.html -- script src{% static js/payment.js %}/script script document.addEventListener(DOMContentLoaded, function() { const orderNo {{ order_no }}; // 由后端模板传入 const stopPolling pollOrderStatus(orderNo); // 页面卸载时清除轮询 window.addEventListener(beforeunload, function() { stopPolling(); }); // 可选添加手动停止按钮 document.getElementById(stop-polling).addEventListener(click, function() { stopPolling(); alert(轮询已停止); }); }); /script关键设计点beforeunload事件确保用户关闭标签页时释放资源避免内存泄漏maxRetries与interval可根据业务容忍度调整如电商常用 5 次 × 5 秒 25 秒状态映射表STATUS_MAP与后端STATUS_CHOICES严格一致避免前后端状态语义错位。提示若项目已接入 WebSocket如 Django Channels可用长连接替代轮询但对中小项目而言fetch setInterval组合更轻量、更易调试、兼容性更好。本文还有配套的精品资源点击获取
