简介这是一套基于Python Django框架开发的完整电商商城项目源码面向Web后端初学者与Django进阶学习者适用于课程设计、毕业项目或企业级商城系统原型开发。项目涵盖商品展示、购物车、订单管理、用户登录注册等核心电商功能结构清晰、模块解耦便于理解Django MTV模式在真实业务中的落地实践。压缩包共403个文件包含53个Python后端逻辑文件、11个HTML模板页、8个CSS样式表如proList.css、detail.css、login.css等、7个JSON配置与数据文件以及大量静态资源293张JPG商品图、11张PNG图标整体体积33.44MB。目前已有3684人下载学习读者可直接运行调试快速掌握Django路由配置、ORM建模、模板渲染、静态文件管理及前后端协同开发流程是少有的兼顾功能性、可读性与工程规范性的实战级教学源码。1. 项目概述一个Django全栈商城项目的深度解构最近在整理硬盘翻出来一个几年前用Django做的商城项目源码包。这个项目不是玩具而是一个功能相对完整、曾用于实际教学和小型团队内部验证的电商系统。今天我就以这个“商城项目源码.zip”为引子带大家彻底拆解一个Django全栈电商项目的核心架构、技术选型背后的思考以及那些在官方文档里不会写的“踩坑”实录。无论你是刚学完Django基础想找个实战项目练手还是已经有一定经验、想看看一个成型项目的组织方式这篇文章都能给你提供一份可以直接“抄作业”的路线图。这个项目涵盖了用户系统、商品管理、购物车、订单流程、支付集成模拟等电商核心模块我们会从“为什么这么设计”开始一直聊到“怎么避免那些常见的坑”。2. 项目整体架构与设计思路拆解2.1 技术栈选型为什么是Django首先聊聊为什么选择Django。很多人会问做电商PHP的Laravel、Java的Spring Boot不香吗对于这个项目选择Django是基于几个非常实际的考量。第一是“开箱即用”。Django自带的Admin后台对于快速搭建商品、分类、订单的管理界面来说效率极高。你几乎不需要写前端代码就能得到一个功能强大的管理后台这在项目初期验证业务逻辑时至关重要。第二是Django的ORM对象关系映射。它让我们能用Python类的方式来定义数据模型比如一个Product类对应数据库里的一张商品表。这种声明式的方法让数据库操作变得非常直观和安全能有效避免手写SQL语句可能带来的注入风险。第三是Django的生态系统。从用户认证django.contrib.auth、表单处理、到缓存、国际化Django都提供了成熟的解决方案。这意味着我们可以把更多精力花在业务逻辑上而不是重复造轮子。当然Django也有其特点它是一个“大而全”的框架有一定的学习曲线但一旦掌握开发常规业务系统的速度是飞快的。对于这个商城项目我们采用了经典的MTVModel-Template-View模式这是Django的核心设计模式。Model负责数据层Template负责展示层View负责业务逻辑层。整个项目的目录结构也是围绕这个模式展开的。2.2 核心功能模块设计在动手写代码之前我对商城的需求进行了梳理并将其拆解为以下几个核心模块这构成了整个项目源码的骨架用户中心模块负责用户注册、登录、退出、个人信息管理、收货地址管理。这是任何电商系统的基石。商品模块包括商品分类多级分类、商品详情、商品SKU库存量单位管理、商品搜索与筛选。这里的设计难点在于如何优雅地处理商品的多规格如颜色、尺寸和对应的库存。购物车模块用户可以将商品加入购物车支持增删改查。购物车数据需要区分用户登录状态存入数据库和未登录状态存入Session或Cookie这是一个典型的细节。订单模块这是最复杂的模块之一。涉及购物车结算、订单生成包含订单号生成规则、订单状态流转待支付、待发货、待收货、已完成等、订单详情展示。支付模块为了简化本项目集成了支付宝沙箱环境进行模拟支付。实际开发中你需要根据选择的支付渠道微信支付、支付宝等接入其官方SDK。后台管理模块基于Django Admin进行深度定制让运营人员可以方便地管理商品、订单、用户等信息。每个模块对应Django中的一个或多个“应用”App。例如我创建了users、goods、cart、orders、pay等应用。这种分应用的方式让代码结构清晰便于团队协作和维护。3. 核心细节解析与实操要点3.1 数据模型设计商品与SKU的艺术商品模型的设计是电商系统的核心。一个常见的误区是只用一个Product模型来存储所有信息。但对于有规格的商品比如iPhone 14有不同颜色和存储容量这会导致数据冗余和查询复杂。在这个项目中我采用了“SPU SKU”的设计模式。SPU标准化产品单元。比如“iPhone 14”就是一个SPU它描述了商品的公共属性如名称、描述、品牌、所属分类等。SKU库存量单位。比如“iPhone 14 深空黑 128GB”就是一个具体的SKU它有自己独立的价格、库存、规格属性。在models.py中你会看到类似这样的定义# goods/models.py from django.db import models class GoodsCategory(models.Model): 商品分类 name models.CharField(max_length50, verbose_name分类名) parent models.ForeignKey(self, on_deletemodels.CASCADE, nullTrue, blankTrue, verbose_name父分类) # ... 其他字段 class GoodsSPU(models.Model): 商品SPU name models.CharField(max_length100, verbose_name商品名称) category models.ForeignKey(GoodsCategory, on_deletemodels.PROTECT, verbose_name商品分类) desc models.TextField(verbose_name商品描述) # ... 其他公共属性字段 class GoodsSKU(models.Model): 商品SKU spu models.ForeignKey(GoodsSPU, on_deletemodels.CASCADE, related_nameskus, verbose_name所属SPU) price models.DecimalField(max_digits10, decimal_places2, verbose_name价格) stock models.IntegerField(default0, verbose_name库存) sales models.IntegerField(default0, verbose_name销量) # 规格信息可以用JSONField存储或者关联到单独的规格表 specs models.JSONField(defaultdict, verbose_name规格属性) # Django 3.1 支持 # ... 其他字段实操心得使用JSONField来存储SKU的规格属性如{color: 深空黑, storage: 128GB}非常灵活特别适合规格不固定的商品。但缺点是难以基于某个具体的规格值进行高效的数据库查询如“找出所有颜色为深空黑的SKU”。如果查询需求复杂建议还是采用传统的多对多关系建立独立的规格名和规格值表。3.2 用户认证与购物车状态管理Django自带的django.contrib.auth提供了强大的用户认证系统。我们直接继承AbstractUser来扩展用户模型添加手机号、头像等字段。# users/models.py from django.contrib.auth.models import AbstractUser from django.db import models class User(AbstractUser): mobile models.CharField(max_length11, uniqueTrue, verbose_name手机号) avatar models.ImageField(upload_toavatar/%Y%m%d/, blankTrue, nullTrue, verbose_name用户头像) # ... 其他扩展字段购物车的设计需要兼顾用户体验和数据一致性。对于未登录用户我们将购物车数据临时保存在Session中。一旦用户登录我们需要将Session中的购物车数据合并到该用户的数据库购物车记录中。这个过程需要注意商品去重和数量累加。注意事项Session在默认情况下可能不适合存储大量或复杂的购物车数据。如果购物车项很多可以考虑将未登录用户的购物车数据加密后存储在客户端的Cookie中但要注意Cookie的大小限制通常每个域名4KB和安全问题需要签名防止篡改。3.3 订单系统的核心状态机与事务订单的生命周期由一系列状态组成。在代码中我使用了一个选择字段来定义这些状态并在关键操作如支付成功、发货时更新状态。# orders/models.py class OrderInfo(models.Model): 订单信息 ORDER_STATUS ( (1, 待支付), (2, 待发货), (3, 待收货), (4, 已完成), (5, 已取消), ) order_id models.CharField(max_length64, primary_keyTrue, verbose_name订单号) # 自定义生成规则 user models.ForeignKey(User, on_deletemodels.CASCADE, verbose_name下单用户) total_amount models.DecimalField(max_digits10, decimal_places2, verbose_name订单总金额) pay_method models.SmallIntegerField(choices((1, 支付宝), (2, 微信支付)), default1, verbose_name支付方式) status models.SmallIntegerField(choicesORDER_STATUS, default1, verbose_name订单状态) # ... 地址、运费等其他字段生成订单是电商系统中最需要保证数据一致性的操作。它至少包含以下几步1. 从购物车中读取商品信息并校验库存2. 生成唯一的订单号3. 创建订单主信息OrderInfo4. 创建订单商品详情OrderGoods5. 扣减对应SKU的库存6. 清空用户购物车。这些步骤必须在一个数据库事务中完成要么全部成功要么全部回滚。Django中使用transaction.atomic()装饰器或上下文管理器可以轻松实现。from django.db import transaction transaction.atomic def create_order(request): # 设置事务保存点 sid transaction.savepoint() try: # 1. 校验数据... # 2. 创建订单... # 3. 扣减库存... # 如果库存不足手动抛出异常 if sku.stock buy_count: raise Exception(f商品{sku.name}库存不足) # ... 其他操作 # 提交事务 transaction.savepoint_commit(sid) return success_response except Exception as e: # 回滚到保存点 transaction.savepoint_rollback(sid) return error_response踩坑实录在高并发场景下仅仅使用事务还不够。比如“超卖”问题两个用户同时购买最后一个商品在事务内读取库存时都看到stock1都认为可以购买然后都执行stock-1的操作最终库存变成了-1。解决这个问题需要在更新库存时使用“乐观锁”或“悲观锁”。在Django中可以使用select_for_update()进行行级锁悲观锁或者使用F()表达式进行原子更新类似乐观锁。例如GoodsSKU.objects.filter(idsku_id, stock__gtebuy_count).update(stockF(stock) - buy_count)然后检查更新影响的行数是否为0来判断是否更新成功即库存是否充足。4. 实操过程与核心环节实现4.1 开发环境搭建与项目初始化首先你需要一个干净的Python环境。强烈建议使用虚拟环境venv或virtualenv来隔离项目依赖。# 创建项目目录并进入 mkdir django_mall cd django_mall # 创建虚拟环境 python -m venv venv # 激活虚拟环境 (Windows) venv\Scripts\activate # 激活虚拟环境 (Mac/Linux) source venv/bin/activate # 安装Django和必要依赖 pip install django3.2.* # 选择一个稳定的LTS版本 pip install pillow # 用于处理图片上传 pip install django-redis # 用于缓存和Session存储接下来创建Django项目和应用django-admin startproject mall . python manage.py startapp users python manage.py startapp goods python manage.py startapp cart python manage.py startapp orders python manage.py startapp pay别忘了在settings.py的INSTALLED_APPS中注册这些应用。同时配置数据库默认SQLite生产环境用PostgreSQL或MySQL、静态文件、媒体文件路径等。4.2 深度定制Django Admin后台Django Admin默认已经很强大了但为了更符合商城后台的需求我们需要进行定制。主要涉及两个方面一是美化展示二是增加动作。在admin.py中通过定义ModelAdmin类来实现# goods/admin.py from django.contrib import admin from .models import GoodsCategory, GoodsSPU, GoodsSKU class GoodsSKUAdmin(admin.ModelAdmin): # 列表中显示的字段 list_display [id, spu, price, stock, sales] # 支持搜索的字段 search_fields [spu__name] # 右侧过滤器 list_filter [spu__category] # 每页显示数量 list_per_page 20 # 在编辑页字段分组显示 fieldsets ( (基础信息, {fields: (spu, price, stock)}), (规格与销量, {fields: (specs, sales)}), ) # 增加一个“补货”动作 actions [replenish_stock] def replenish_stock(self, request, queryset): # queryset是用户选中的SKU对象集合 updated_count queryset.update(stockmodels.F(stock) 100) self.message_user(request, f成功为{updated_count}个商品补充了100件库存。) replenish_stock.short_description 批量补充库存 (100) admin.site.register(GoodsSKU, GoodsSKUAdmin)实操心得对于订单管理你很可能需要在Admin后台直接操作订单状态如“发货”。你可以通过重写ModelAdmin的response_change方法在状态变更为“待发货”时自动触发物流单号生成等后续逻辑。这能让后台操作与业务流程紧密耦合。4.3 前端页面与后端API的协作这个项目采用了前后端轻度耦合的模式。即后端使用Django的模板引擎Django Template Language渲染大部分页面但在一些需要动态交互的地方如添加购物车、修改商品数量使用了jQuery发起Ajax请求与后端API交互。例如购物车页面数量的增减!-- 模板中 -- input typenumber classcart-num-input>// 对应的jQuery代码 $(.update-cart-btn).click(function(){ var $input $(this).siblings(.cart-num-input); var sku_id $input.data(sku-id); var new_count $input.val(); $.ajax({ url: /cart/update/, type: POST, data: { sku_id: sku_id, count: new_count, csrfmiddlewaretoken: {{ csrf_token }} }, dataType: json, success: function(data){ if(data.code 0){ // 更新页面总价等 location.reload(); // 简单粗暴或局部刷新 }else{ alert(data.msg); } } }); });后端对应的视图函数需要处理JSON请求# cart/views.py from django.http import JsonResponse from django.views.decorators.http import require_POST require_POST def cart_update(request): sku_id request.POST.get(sku_id) count request.POST.get(count) # 1. 校验数据 # 2. 获取购物车对象从Session或数据库 # 3. 更新数量 # 4. 返回JSON响应 return JsonResponse({code:0, msg:更新成功, cart_total_count: new_total_count})注意事项这种模式在中小型项目中很常见开发速度快。但对于复杂的单页面应用SPA建议将前后端完全分离后端只提供RESTful API可以使用Django REST framework前端使用Vue.js或React等框架。这需要更系统的设计和团队协作。5. 常见问题与排查技巧实录在开发和部署这个商城项目的过程中我遇到了不少典型问题。这里总结一份“避坑指南”希望能帮你节省时间。5.1 静态文件收集失败404错误问题描述在开发环境DEBUGTrue下静态文件正常显示。但一旦部署到生产环境DEBUGFalseCSS、JS、图片全部加载失败报404错误。原因分析Django在开发模式下会自动处理静态文件。但在生产模式下出于安全和性能考虑Django不再处理静态文件这项工作应交由前端的Web服务器如Nginx或专门的CDN来处理。解决方案正确配置settings.py# 生产环境设置 DEBUG False # 允许访问的域名替换为你的域名或IP ALLOWED_HOSTS [yourdomain.com, 服务器IP] # 静态文件URL前缀 STATIC_URL /static/ # 静态文件收集目录运行collectstatic命令后文件会集中到这里 STATIC_ROOT os.path.join(BASE_DIR, static_collected)运行收集命令在部署服务器上进入项目根目录运行python manage.py collectstatic。这个命令会将所有app下的static文件夹内的文件以及你配置的静态文件全部复制到STATIC_ROOT目录中。配置Nginx在Nginx配置文件中添加一个location块来处理静态文件请求。server { listen 80; server_name yourdomain.com; location /static/ { alias /path/to/your/project/static_collected/; # 指向STATIC_ROOT目录 } location /media/ { # 处理用户上传的媒体文件 alias /path/to/your/project/media/; } location / { proxy_pass http://127.0.0.1:8000; # 转发动态请求给Gunicorn/Uwsgi proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }5.2 数据库迁移冲突与合并问题描述在团队协作中A同事创建了一个AddField的迁移文件0002_xxx.pyB同事创建了另一个AddField的迁移文件0002_yyy.py因为他们的基础都是0001_initial。当合并代码后运行python manage.py migrate会失败提示依赖冲突。原因分析Django的迁移文件是线性依赖的。当分支开发时容易产生基于同一父迁移的不同子迁移导致迁移树分叉。解决方案预防优于治疗在团队中约定每次修改模型前先拉取最新代码并运行迁移确保本地数据库是最新状态。发生冲突后首先备份你的数据库非常重要。查看当前迁移状态python manage.py showmigrations。尝试使用python manage.py makemigrations --merge命令让Django尝试自动创建一个合并迁移。如果成功会生成一个新的迁移文件如0003_merge它同时依赖冲突的两个迁移。如果自动合并失败就需要手动介入。步骤比较繁琐可能需要回退迁移migrate app_name previous_migration_number删除冲突的迁移文件重新生成一个包含所有变更的迁移文件。这个过程需要谨慎操作并充分测试。实操心得对于小型团队或个人项目一个简单的策略是在推送模型改动前确保只有一个人生成了迁移文件。或者在开发新功能时可以暂时不生成迁移等所有模型改动确定后由一个人统一执行makemigrations。5.3 性能瓶颈首页商品列表加载慢问题描述商城首页需要展示大量商品每个商品又要显示分类、SPU等信息。随着数据量增长页面加载速度明显变慢。原因分析这很可能是因为产生了“N1查询问题”。在模板中循环渲染商品列表时如果对每个商品都去查询其关联的分类或SPU信息就会产生大量单独的数据库查询。排查技巧使用Django Debug Toolbar这个神器。安装配置后它会在页面侧边栏显示当前请求的所有SQL查询、耗时、缓存命中等信息。你可以清晰地看到哪些视图产生了过多的查询。解决方案使用select_related和prefetch_related进行查询优化。select_related用于一对一OneToOneField或外键ForeignKey关系通过SQL的JOIN一次性获取关联对象。适用于“向前”查询。# 优化前在模板中访问 sku.spu.name 会产生额外查询 skus GoodsSKU.objects.all()[:20] # 优化后一次性通过JOIN获取关联的spu对象 skus GoodsSKU.objects.select_related(spu).all()[:20]prefetch_related用于多对多ManyToManyField或反向ForeignKey关系通过额外的查询而不是JOIN预取相关对象集。适用于“向后”查询或ManyToMany。# 假设SPU有多个图片反向查询 spus GoodsSPU.objects.prefetch_related(images).all()[:10] # 在模板中循环 spu.images.all 就不会产生额外查询在我的项目中首页商品列表的查询最终优化为hot_skus GoodsSKU.objects.filter(is_hotTrue)\ .select_related(spu)\ .prefetch_related(spu__images)\ .only(id, price, spu__name, spu__desc)[:12]only()方法用于指定只查询需要的字段进一步减少数据传输量。5.4 支付回调验证与幂等性问题描述集成支付宝支付时支付成功后支付宝会异步通知回调我们的服务器。如何确保回调请求的真实性并且由于网络问题支付宝可能会多次发送同样的回调通知如何防止因重复通知导致订单被重复处理例如重复发货解决方案验证回调真实性支付宝回调时会携带一系列参数和一个签名。我们必须用支付宝的公钥从支付宝开放平台获取对这个签名进行验证确保该请求确实来自支付宝而不是伪造的。绝对不要跳过签名验证这是支付安全的第一道防线。保证处理幂等性幂等性是指同一个操作执行多次结果与执行一次相同。对于支付回调关键逻辑是更新订单状态为“已支付”。实现幂等性的常见方法是在更新前检查状态在处理回调的业务逻辑开始时先根据回调中的商户订单号即我们系统生成的order_id查询订单。如果订单状态已经是“已支付”或后续状态则直接返回成功响应不再执行后续的库存扣减、发放积分等操作。使用数据库唯一约束或乐观锁例如可以创建一个“支付流水记录表”将支付宝的交易号trade_no设为唯一索引。每次回调都尝试插入这条流水记录如果因重复trade_no插入失败则说明该支付已处理过。# pay/views.py (简化示例) from django.views.decorators.csrf import csrf_exempt from alipay import AliPay # 使用支付宝Python SDK csrf_exempt # 支付宝回调是POST请求需要豁免CSRF检查 def alipay_callback(request): # 1. 获取POST数据并验证签名 data request.POST.dict() signature data.pop(sign, None) alipay AliPay(...) # 初始化Alipay对象配置好公钥私钥 success alipay.verify(data, signature) if not success: return HttpResponse(fail) # 签名验证失败告诉支付宝 # 2. 获取订单号和处理业务逻辑 order_id data.get(out_trade_no) trade_no data.get(trade_no) try: order OrderInfo.objects.get(order_idorder_id) except OrderInfo.DoesNotExist: return HttpResponse(fail) # 3. 幂等性处理检查订单状态 if order.status ! 1: # 假设1是“待支付” # 订单已处理过直接返回成功 return HttpResponse(success) # 4. 开始事务处理核心业务 with transaction.atomic(): # 再次查询并锁定订单行悲观锁防止并发 order OrderInfo.objects.select_for_update().get(order_idorder_id) if order.status ! 1: return HttpResponse(success) # 更新订单状态、记录支付流水等 order.status 2 # 更新为“待发货” order.trade_no trade_no order.save() # ... 其他业务逻辑如扣减库存、增加销量 return HttpResponse(success) # 必须返回success支付宝才会停止发送此通知最后再分享一个小技巧在开发支付功能时务必充分利用支付宝的“沙箱环境”。它模拟了真实的支付流程但用的都是虚拟资金可以让你尽情测试各种正常和异常情况如支付成功、支付失败、重复通知、网络超时等而不用担心产生真实的资金损失。在settings.py里通过一个变量如ALIPAY_DEBUG True来切换沙箱和正式环境的配置会让你的开发调试过程顺畅很多。本文还有配套的精品资源点击获取