简介基于Python Django构建的商店购物系统面向毕业设计学生及Django初学者专注解决电商产品模型不灵活、难以适配变体商品的痛点。与常见预定义数据库模型不同它依据物理属性组织产品可创建完整深入的变体层次结构支持颜色、尺寸等多维属性同时避免实体属性值模型带来的高代价表连接。压缩包内共有427个文件以166个Python源码、101个HTML模板为主辅以样式表、配置文档及多语言翻译文件整体仅2.19MB轻量易部署。系统已提供完整可运行代码覆盖商品展示、购物车、订单处理等典型流程包含产品列表、详情、登录注册等页面采用标准Django项目结构目录清晰便于二次开发与功能扩展。目前已有191人学习适合正在完成毕设或希望深入理解Django建模技巧的读者参考。1. 购物系统先把产品模型设计对再谈页面这个项目选题在毕业设计和可运行工程之间找到了平衡点。多数电商Demo把产品表设计成ID、名称、价格、库存四个固定字段产品一带颜色、尺寸、套餐分级就立刻失控另一条路是做“属性名—属性值”的通用表业界叫Entity-Attribute-Value简称EAV筛选会生成大量表连接数据量大就成反模式。这套基于Django的购物系统选择了物理属性映射让产品模型直接对应真实物品的层次结构。项目文件也很有代表性base.html管骨架product-gallery.css管图库product-add2cart.html管加购login-logout.html管会话切换。页面之外产品建模、模板分层、构建链路三层设计如何衔接适合毕业设计选型和想看清Django电商目录结构的从业者参考。2. 放弃EAV后产品变体层次该怎么建模2.1 实体属性值模式为什么会拖垮查询性能EAV的本质是把“属性”本身变成数据行。产品表面只有一行记录颜色红色、尺寸XL、材质纯棉各是一条属性记录。写入自然灵活读取却昂贵筛选“红色且XL”的产品时属性表需要按属性名做两次自连接每次join都要附带属性名过滤和属性值过滤两个条件查询计划器的估算成本直接和属性维度相乘。十万行商品数据下这类查询延迟从几十毫秒涨到几百毫秒而且schema不固定索引很难覆盖全部属性组合最终只能借助外部搜索引擎兜底。所以建模阶段就得做取舍。这个项目采用的方式是每个ProductType对应明确的实体化产品模型具体的变体挂在Product下用ForeignKey引用。代码上是这样拆的# models.py from django.db import models class ProductType(models.Model): label models.CharField(max_length50, uniqueTrue) def __str__(self): return self.label class Product(models.Model): name models.CharField(max_length200) slug models.SlugField(uniqueTrue) product_type models.ForeignKey(ProductType, on_deletemodels.PROTECT) class Meta: indexes [ models.Index(fields[slug]), ] class ProductVariant(models.Model): product models.ForeignKey(Product, on_deletemodels.CASCADE, related_namevariants) sku models.CharField(max_length32, uniqueTrue) stock models.PositiveIntegerField(default0) class Meta: indexes [ models.Index(fields[sku]), ]这三个模型的职责拆分值得细看。ProductType是分类外壳label唯一约束避免后台重复建类Product是展示层实体slug做唯一约束后详情页URL直接用slug而不是数字主键避免主键被遍历猜测也方便SEOProductVariant是真正可售的SKU库存挂在它身上而不在Product上——同一款T恤的L码和XL码库存不同价格也可能不同放Variant上下单时引用的数据才不会错位。字段选型上建议对表确认理由字段类型约束设计意图Product.slugSlugField unique详情页URL入口避免主键暴露ProductType.labelCharField unique类型名天然唯一防重复建类ProductVariant.skuCharField unique库存、订单关联的最小颗粒ProductVariant.stockPositiveIntegerField从字段层杜绝负库存写入Django对unique字段会自动建唯一索引但对不强制唯一的字段不会。按variants__stock__gt0过滤产品时如果product_id上的外键索引被手动关掉过反查询性能会明显吃紧保留默认外键索引通常就够不建议为了省空间去改这个默认行为。2.2 变体筛选prefetch_related和select_related怎么选商品页是电商里查询类型最密集的地方。列表页需要每个产品的最新变体信息详情页需要单个产品下的全部变体两者对应不同的ORM预取方式# views.py from django.shortcuts import get_object_or_404, render from .models import Product def product_detail_view(request, slug): product get_object_or_404( Product.objects.prefetch_related(variants), slugslug, ) return render(request, detail.html, {product: product}) def product_list_view(request): products Product.objects.filter( variants__stock__gt0 ).prefetch_related(variants).distinct()[:24] return render(request, base.html, {products: products})prefetch_related是反向外键和多对多关系的正确预取方式select_related只处理外键方向。上面两个视图最终都拆成两条SQL一条查Product一条按product_id IN查询variants然后ORM在内存中组装而不是每读一个产品触发一次新查询。列表页如果不加distinct()过滤经过变体后结果行数等于“产品数×变体数”加入分页会得到重复产品条目distinct把结果集收回到产品粒度。按属性筛变体再反查产品路径是这样的from django.db.models import Q variant_product_ids ProductVariant.objects.filter( Q(attribute_values__valueXL) Q(attribute_values__attribute__name尺寸) ).values_list(product_id, flatTrue).distinct() products Product.objects.filter( id__invariant_product_ids ).prefetch_related(variants)[:24]如果业务要继续扩展属性维度一般做法是在ProductVariant上增加attribute_values的ManyToMany关联后把属性过滤收敛到Variant这一层用values_list取出命中的product_id再反查主表。只要sku和product_id上的索引在扫描范围就限于属性命中的那组变体不会退化成全表join。注意prefetch_related放进filter链之后才生效写在filter之前的写法会触发两次查询但拿到旧结果集调试时优先检查这条顺序。2.3 删除对象时的级联行为与购物车存量清理运行期还有一个绕不开的操作删除商品。Django的级联删除不会自动清理外部系统里已经存在的购物车引用——SKU删了购物车里的variant_id还在用户结算时才会发现问题。项目里处理这个逻辑的常见做法是先保护再删除from django.db.models import ProtectedError from django.contrib import messages def delete_product(request, slug): product get_object_or_404(Product, slugslug) try: product.delete() except ProtectedError: messages.error(request, 该产品存在进行中的订单无法删除) return redirect(product_detail, slugslug) return redirect(product_list)这里catch住ProtectedError是必须的。ProductType外键用了on_deletemodels.PROTECT当类型下还挂着产品时删除类型会直接抛异常不catch就返回500。变体删除导致购物车出现幽灵数据的场景项目里可以在结算视图开头把购物车键值与现存SKU做一次IN查询不存在的键现场洗掉这个小逻辑能挡住线下商场最常见的结算异常。3. 模板体系怎么搭从base.html到加购流程3.1 base.html与customer.css的职责边界模板层入口是base.html。它的作用不是提供一套漂亮UI而是把导航、页脚、鉴权按钮这些全站公共元素集中管理避免每个页面复制粘贴头部代码。base.html里定了几个blocktitle、content、extra_css、extra_js子模板按需覆盖!-- base.html -- !DOCTYPE html html langzh-CN head meta charsetutf-8 meta nameviewport contentwidthdevice-width, initial-scale1 title{% block title %}商店系统{% endblock %}/title {% load static %} link relstylesheet href{% static css/customer.css %} {% block extra_css %}{% endblock %} /head body header {% if user.is_authenticated %} a href{% url logout %}退出登录/a {% else %} a href{% url login %}登录/a {% endif %} /header main {% block content %}{% endblock %} /main footer{% block footer %}{% endblock %}/footer {% block extra_js %}{% endblock %} /body /htmlcustomer.css承载的是全站基础样式导航、页脚、按钮、表单间距。把它单独抽出来和产品图库样式隔离好处是页面按需引用列表页不加载图库样式详情页不加载表格样式浏览器下载的字节数明显下降。这里有个常见错误是把两套样式都塞进customer.css页面请求数少了一个但每个页面都背着无关样式样式表膨胀后照样卡首页渲染。{% load static %}放在head区域是为了让当前模板能识别{% static %}标签这个加载只对当前模板文件生效。子模板继承base.html之后如果要用到static标签需要在自己的文件顶部再次声明。3.2 详情页与图库静态资源的路由方式detail.html是产品信息的最终呈现页核心是图库区域和加购表单。图库区域由product-gallery.css负责排版HTML结构里把静态资源和表单动作分开!-- detail.html 片段 -- {% extends base.html %} {% load static %} {% block extra_css %} link relstylesheet href{% static css/product-gallery.css %} {% endblock %} {% block content %} article classproduct-gallery {% for image in product.images.all %} img src{{ image.url }} alt{{ product.name }} loadinglazy width400 height400 {% endfor %} /article form methodpost action{% url add_to_cart product.slug %} {% csrf_token %} button typesubmit加入购物车/button /form {% endblock %}三个关键点需要理解。第一{% load static %}必须在模板顶部声明否则static标签原样输出成字符串浏览器解析不到样式路径。第二product.images.all假设Product和Image之间定义了一对多关系视图层要记得把images一起prefetch否则图库几张图就产生几次全表查询。第三加购表单的action指向add_to_cart命名路由路由参数是product.slug页面与具体按钮解耦。product-gallery.css里的布局参数是图库显示的核心常见写法是flex加百分比宽度/* product-gallery.css */ .product-gallery { display: flex; flex-wrap: wrap; gap: 12px; } .product-gallery img { width: calc(50% - 6px); object-fit: cover; border-radius: 4px; }gap为12px时两列布局里每张图占calc(50% - 6px)减去的6px是gap的一半否则两列总宽度超出容器导致右列掉落。改成三列时把百分比换成calc(33.3333% - 8px)并保留gap固定值。3.3 editable.html站内编辑和详情页的差异editable.html是详情页在可编辑场景下的变体。它的结构与detail.html相似区别是增加编辑器容器和保存动作给后台内容管理人员做实时预览!-- editable.html 片段 -- {% extends base.html %} {% block content %} article ideditable-region># cart.py from django.shortcuts import redirect from django.contrib import messages def add_to_cart(request, slug): product Product.objects.get(slugslug) variant_id request.POST.get(variant_id) quantity int(request.POST.get(quantity, 1)) if variant_id: try: variant ProductVariant.objects.select_related(product).get( idvariant_id, productproduct ) except ProductVariant.DoesNotExist: messages.error(request, 商品变体不存在) return redirect(product_detail, slugproduct.slug) if variant.stock quantity: messages.error(request, 库存不足当前剩余 %d % variant.stock) return redirect(product_detail, slugproduct.slug) cart request.session.setdefault(cart, {}) cart[variant_id] cart.get(variant_id, 0) quantity request.session[cart] cart return redirect(cart_detail)try/except捕掉“夹带不存在的变体ID”的请求防止绕过页面直接伪造POST参数库存判断在写会话之前避免超卖数量进购物车request.session.setdefault(cart, {})保证首次加购自动初始化购物车字典cart.get(variant_id, 0) quantity让同一SKU重复加购是累加而不是覆盖。request.session通常不立即写数据库Django会在响应结束前统一保存如果要在同一请求里强制落库手动把request.session.modified True打开。整个模板层与资源的对应关系如下模板文件关联资源实际作用base.htmlcustomer.css全站骨架与导航detail.htmlproduct-gallery.css产品图库与详情展示editable.html后台管理脚本站内编辑预览product-add2cart.htmlcart.py 视图变体选择与加购login-logout.htmlauth 视图登录登出交互4. 项目构建链路从setup.cfg到make.bat4.1 setup.cfg里的依赖声明与版本锁定项目里的setup.cfg走标准Python打包配置把依赖声明从setup.py里剥离构建工具统一读取ini格式配置。对商店项目而言它更像一份环境约束文件把Python版本、第三方依赖、打包范围都写清楚# setup.cfg [metadata] name django-shop version 0.1.0 description 基于Django的商店购物系统 [options] packages find: python_requires 3.10 install_requires Django4.x mysqlclient2.x Pillow [options.packages.find] exclude tests* docs*python_requires写严一点。开发机上跑着3.11部署机是3.7新版本Django直接拒绝安装排查半天才意识到是Python版本问题。install_requires里的Django锁定一个大版本范围避免升级带来的ORM行为变化mysqlclient锁一个小版本范围因为不同小版本的MySQL驱动在Windows与MariaDB兼容性上有差异常见报错是Unknown collation这类字符集问题。Pillow必须有产品图库依赖它处理上传图片的格式和尺寸校验。4.2 make.bat链路上的关键命令make.bat是Windows下的启动脚本把初始化、建表、收集静态文件、启动开发服务合并成一条链echo off REM 初始化并启动商店项目 python -m venv .venv call .venv\Scripts\activate.bat pip install -r requirements.txt python manage.py makemigrations python manage.py migrate python manage.py collectstatic --noinput python manage.py runserver 0.0.0.0:8000三条顺序细节值得说明。makemigrations必须在migrate之前models.py变更没生成迁移文件migrate自然没有可执行内容collectstatic要在runserver之前模板里的{% static %}只有先收集到STATIC_ROOT才能解析到实际文件地址否则开发环境看得到样式、部署后全是404venv激活用call而不是直接执行activate.batbatch文件不call会把控制权交给子脚本后面的命令不会执行。提示collectstatic --noinput里的--noinput在非交互终端是必需的少了它执行到“是否覆盖已存在文件”会直接挂起。4.3 config目录与数据库会话的匹配config目录保存Django的配置模块通常涵盖settings、urls、wsgi。针对商店系统有一张配置参数值得直接参考参数推荐值理由SESSION_ENGINEdb后端购物车落库进程重启不丢CACHESlocmem开发省事生产换RedisSTATIC_ROOTstatic/collectstatic输出目录MEDIA_ROOTmedia/产品图上传目录ALLOWED_HOSTS显式域名列表生产环境防Host头攻击SESSION_ENGINE选db而不是locmem的原因在于购物车数据要跨进程共享locmem每进程独立多worker下会话互不可见db后端靠数据库持久化重启后购物车还在。ALLOWED_HOSTS本地写*能跑部署到服务器换成域名列表。STATIC_ROOT与MEDIA_ROOT要提前区分开否则CSS资源和用户上传的产品图混在一起部署时收集体积和权限管理都很被动。4.4 首次启动的验证路径make.bat跑完不要直接开浏览器看首页。先从命令行做三个检查查表——连接数据库看是否生成以expected业务表为前缀的表查静态文件——collectstatic是否报缺失文件报错多半是模板里引用的静态路径与资源实际路径拼写不一致最后才runserver在浏览器里完整走一遍加购、登录、登出观察终端日志有没有500和404。这三步确认完说明构建链路本身没有断裂后续改模板和加模块都有可复现的基础。5. 验证方法与排错技巧让这套系统稳定跑起来5.1 抛开浏览器用Django测试客户端模拟核心流程如果项目包里没带tests可以自己补一个最小冒烟测试。Django的测试客户端不需要启动服务器直接调用URL路由验证登录、加购、登出这些核心流程# tests.py from django.test import Client, TestCase from django.urls import reverse class CartFlowTest(TestCase): def setUp(self): self.client Client() self.variant ProductVariant.objects.create( skuTEST-001, stock5 ) self.product self.variant.product def test_add_to_cart_increases_session_cart(self): url reverse(add_to_cart, args[self.product.slug]) resp self.client.post(url, {variant_id: self.variant.id, quantity: 2}) self.assertEqual(resp.status_code, 302) session self.client.session self.assertEqual(session[cart][str(self.variant.id)], 2)这个测试的关键是用self.client.session读取会话而不是操作实际请求对象。测试客户端post完成后Django已经把回写过的会话挂在client上读取时才能拿到最新字典。断言302失败时优先排查反向解析参数和库存校验分支。5.2 静态文件与登录登出接口的排查思路静态文件404的排查顺序比较固定。先看模板里{% static %}生成的实际URL拿它和浏览器请求路径对比再确认产品图等上传资源走MEDIA_URL而不是STATIC_URL最后检查runserver或部署服务的目录下STATIC_ROOT是否为空。如果图库能显示但样式错乱重点观察product-gallery.css里的calc表达式百分比与固定像素混合计算在不同浏览器下的兼容行为有明显差异。login-logout.html里的登录状态按钮依赖user.is_authenticated这个变量来自auth context processor。settings里如果删掉了django.contrib.auth.context_processors.auth页面直接报未定义变量。此类问题开发环境正常、部署环境报错往往是部署机上重新生成过settings文件而丢失默认配置。最后提一个实用技巧删除对象前先检查购物车引用。加购后后台把对应变体删除购物车里的variant_id就成了幽灵数据结算时无法定位产品500直接抛给用户。可以在结算视图开头加一条治理语句把购物车里的所有键和现存SKU做一次IN查询查不到的键现场从会话里删除再继续下单。这个步骤不复杂但能把“变体删除导致结算失败”这类线上事故挡在发生之前。本文还有配套的精品资源点击获取