Django购物商城系统毕设实战：部署、避坑与答辩完整指南

简介：一份基于Django框架的购物商城系统毕业设计资料，适合计算机相关专业学生、毕业设计选题者及初级Web开发者参考。资源以“论文.zip”形式打包，压缩包大小约4.79MB，内部文件总数与类型明细在平台未展示，下载后可直接查阅论文主体。论文内容通常覆盖需求分析、Django技术选型、MVC系统架构、数据库设计、各核心模块实现（用户、商品、购物车、订单、支付及管理后台）、测试优化与总结展望，可作为毕业设计论文的结构与写法范例。已有90人学习该资源，说明其具备一定的参考价值。通过学习可快速理解Django电商项目从需求到落地的完整流程，并借鉴论文的组织方式来完成自己的毕业设计或课程设计。

1. 你下载的 Django 购物商城系统 zip，可能和你想象的不一样

很多同学拿到这个「django购物商城系统-o9m4k-论文.zip」压缩包时，心情是又激动又忐忑：激动的是感觉毕设有救了，忐忑的是解压之后大概率跑不起来。我见过不止一个同学卡在第一步就翻车——要么依赖装不上，要么数据库连不上，最后只能盯着满屏红字怀疑人生。这个标题其实透露了不少信息：它是一个典型的毕设/课设打包件，zip 里装的是 Django 写的商城项目源码，外加一篇用来对应说明的论文文档。那个o9m4k就是打包批次标识，没有特殊含义。这篇笔记要做的，不是替你重新发明一套商城，而是把这条「解压 → 跑通 → 看懂 → 改明白 → 能答辩」的路踩平：先讲清楚 Django 商城系统的骨架，再给你能在本地跑起来的最小步骤，接着拆开商品、购物车、订单这三段核心链路，最后把最容易翻车的几个坑一次说完。新手上路能跟步骤走，熟手也能看到边界和参数取舍。

2. Django 商城系统的骨架：MTV 分层、ORM 与后台管理怎么撑起一个商城

2.1 MTV 结构里，商城的 Model / View / Template 各自承担什么

Django 用的是 MTV（Model-Template-View）分层，理解它比背概念更重要，因为整个商城系统的代码组织方式都围绕这个展开。Model 管数据：商品、用户、订单这些业务实体最终都变成一张张数据库表，而你在代码里操作的是 Python 类而不是 SQL；View 写逻辑：把「购物车里勾选的三件商品汇总成一张订单」这种判断和计算，全部住在 View 函数里；Template 管渲染：从数据库拿出来的商品列表，怎么变成用户浏览器里那个带价格、带图片、带加购按钮的页面，这就是 Template 的活。URL 分发器则负责决定一个请求进来之后该找哪个 View 函数，它相当于整个系统的路由表。

看这套源码的顺序，我的习惯是先读models.py，把数据关系摸清楚；再打开urls.py，把路由全画一遍；最后才看views.py和模板。顺序反过来的话，你很容易迷失在几十个视图函数里，不知道谁调了谁。商城这种系统，数据流是主干——用户、商品、订单之间的关系一旦读懂了，整个系统就懂了一半。先顺着一条「用户浏览商品 → 加购物车 → 下订单 → 订单状态变化」的数据走向去读代码，比从头文件第一个函数往后看要高效得多。

2.2 ORM 数据模型：商品、SKU、订单、用户之间的外键关系怎么设计

Django 商城系统的数据模型，业内做法其实比较统一，很多套代码翻来覆去就是那几个实体。用户通常基于auth.User做扩展，有的项目会新建一个 Profile 表，用 OneToOneField 和 User 关联，用来存手机号、收货地址这些扩展信息；商品分两级，分类（Category）和具体商品（Product），复杂一点的还往上加品牌，往下加 SKU 规格；订单这头是经典的主子表结构，Order 主表存用户、总额、状态，OrderItem 子表存每一件商品的名称、单价、数量快照。以下是一段非常典型的核心模型设计，很多打包项目的 models.py 里就是这类结构：

class Category(models.Model): name = models.CharField(max_length=64, verbose_name="分类名") parent = models.ForeignKey( "self", null=True, blank=True, on_delete=models.CASCADE, verbose_name="父分类" ) class Product(models.Model): name = models.CharField(max_length=128, verbose_name="商品名") category = models.ForeignKey(Category, on_delete=models.PROTECT, verbose_name="分类") price = models.DecimalField(max_digits=10, decimal_places=2, verbose_name="销售价") stock = models.IntegerField(default=0, verbose_name="库存") is_on_sale = models.BooleanField(default=True, verbose_name="是否上架") class Order(models.Model): user = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.CASCADE, verbose_name="下单用户") total_amount = models.DecimalField(max_digits=10, decimal_places=2, verbose_name="订单总额") status = models.CharField(max_length=16, choices=ORDER_STATUS_CHOICES, default="pending", verbose_name="订单状态") class OrderItem(models.Model): order = models.ForeignKey(Order, related_name="items", on_delete=models.CASCADE, verbose_name="所属订单") product_name = models.CharField(max_length=128, verbose_name="商品快照名称") price = models.DecimalField(max_digits=10, decimal_places=2, verbose_name="下单时单价") quantity = models.IntegerField(default=1, verbose_name="数量")

这段代码里有几个细节值得单独拿出来说。第一，金额字段用DecimalField而不是FloatField，浮点数做金额计算会出现 0.1 + 0.2 不等于 0.3 这种经典问题，凡是涉及钱的字段都要用 Decimal，这是血泪经验。第二，OrderItem里的product_name和price是快照字段，也就是说订单明细里存的商品名和价格，是下单那一刻从商品表复制过来的，不是外键关联实时查询。这样做的原因是：商品之后可能改名、改价，但历史订单上的信息不能跟着变。第三，分类外键用了on_delete=models.PROTECT，被引用的分类不允许直接删除，防止后台管理员手滑删掉一个有商品的分类导致数据全乱。CASCADE适合用户删了连订单一起删的场合，但商品分类这种被依赖的基础数据，PROTECT更稳妥。

2.3 Django Admin 为什么是商城后台的「免费午餐」

Django 自带的后台管理（django.contrib.admin）是这类项目里价值很高的一环，也是很多人忽略的部分。只要在admin.py里注册模型，Django 会自动生成一套基于模型字段的增删改查界面，商品录入、订单改状态这些后台操作不用写一行前端代码就能用。对商城系统来说，这就是现成的运营后台，比你自己从零写管理页面省太多事。

from django.contrib import admin from .models import Product, Order, OrderItem class OrderItemInline(admin.TabularInline): model = OrderItem extra = 1 @admin.register(Order) class OrderAdmin(admin.ModelAdmin): list_display = ("id", "user", "total_amount", "status", "created_at") list_filter = ("status",) inlines = [OrderItemInline] @admin.register(Product) class ProductAdmin(admin.ModelAdmin): list_display = ("name", "category", "price", "stock", "is_on_sale") list_editable = ("price", "stock", "is_on_sale") search_fields = ("name",)

这段配置里，list_display决定后台列表页显示哪些列；list_filter是侧边栏筛选器，按订单状态筛单子很方便；search_fields给顶部搜索框加按商品名搜索的字段索引；list_editable允许在列表页直接改价格和库存，这是运营最高频的操作，不用点进详情页。OrderItemInline是订单管理的关键，它让管理员在订单编辑页直接看到并维护订单明细，省去来回切换页面。

但要说清楚边界：Admin 适合做后台管理操作，不适合做复杂业务。扣库存、校验订单金额、支付回调这类逻辑不应该写在 admin 的 save_model 里，而要放在 View 层或 Model 方法中。Admin 是给内部运营用的工具，不是给消费者的下单入口，把这条边界记清楚，你改这套源码时才不会把业务逻辑堆错地方。

3. 让商城在本地跑起来：环境、依赖与两条启动命令

3.1 解压后的目录结构：先分清源码、虚拟环境和论文

拿到 zip 后第一件事不是急着找代码跑，而是先看目录结构。这种打包件的布局其实有规律可循，一般是总目录下同时放着 Django 项目源码和论文文档。我见过最常见的排斥组合是这样：

django购物商城系统-o9m4k/ ├── manage.py ├── requirements.txt ├── 商城项目配置目录/ │ ├── settings.py │ ├── urls.py │ ├── wsgi.py │ └── __init__.py ├── apps/ │ ├── users/ │ ├── goods/ │ ├── cart/ │ └── order/ ├── static/ ├── media/ └── 论文文档/ ├── 开题报告.docx └── 论文正文.docx

manage.py是项目入口，后面所有管理命令都是通过python manage.py xxx执行的；和它同级的那个「项目配置目录」是整个系统的全局配置，settings.py和urls.py都在这；apps目录按业务模块拆分，商品、购物车、订单都是独立的应用；static放 CSS、JS、图片等静态资源，media放运行时上传的商品图片和用户文件。论文目录通常和源码同级，是打包时一起放进去的。

真正需要警惕的是requirements.txt这个文件。它很可能会出现版本号锁得特别死的情况，比如Django==3.2.10、mysqlclient==2.1.0这种。如果本机 Python 是 3.10 以上，而依赖里锁的是 Django 3.2 系列，大概率会遇到兼容性问题——Django 3.2 官方支持到 Python 3.10，3.11 以上直接跑不起来。看到这种版本组合，要做好心理准备：要么降 Python，要么把 Django 升级到 4.x 并顺手改一两个废弃 API。别急着删 requirements 里的包，先装完再逐个解决报错更靠谱。

3.2 创建虚拟环境并安装依赖：requirements.txt 里最容易翻车的三个包

拿到这套代码，我一般会先建虚拟环境再装依赖，绝不让它污染系统 Python。虚拟环境的好处是依赖隔离，装坏了删掉 venv 目录重新来，不伤本机环境。Windows 和 Linux 的命令略有差异，但思路一样：

cd django购物商城系统-o9m4k python3 -m venv venv source venv/bin/activate # Windows 下用 venv\Scripts\activate python --version # 确认当前解释器版本 pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple

venv命令创建隔离环境，source activate激活它，之后的 pip 安装都只进这个环境。后面的-i是切换 pip 源，因为默认的 PyPI 在国外，下载慢且容易超时，用清华镜像能省很多时间。

requirements.txt里最容易翻车的是三个包。第一个是mysqlclient，它在 Windows 上安装需要一个叫 MySQL C 库的依赖，很多人直接卡在这里报错。第二个是Pillow，老版本在 Python 3.11 上编译时常失败，报一堆红色编译错误。第三个是uwsgi，它在 Windows 上根本没有预编译包。遇到装不上的，我的处理方式是：先找到 requirements 里对应那一行，单独执行pip install 包名看看真实报错；如果是编译类错误，优先换 Python 小版本或者升级包版本，而不是把依赖从文件里删掉——删了之后跑代码时才会发现少东西，报错更隐蔽。依赖装完，用一条命令验证：

pip list | grep -E "Django|mysql|Pillow|celery"

看到 Django 版本和 requirements 一致，说明环境这关过了。这步虽然简单，但它决定了后面所有排错时的起点——很多「莫名其妙的问题」，最后查到底都是依赖没装干净。

3.3 数据库迁移与本地启动：三条命令和一个必改的配置项

依赖装完，跑通系统靠三条命令：

python manage.py makemigrations python manage.py migrate python manage.py runserver 0.0.0.0:8000

makemigrations根据models.py的变化生成迁移文件，migrate把这些迁移文件真正同步到数据库。这两条命令的顺序不能反，也不能跳——很多同学拿到代码直接runserver，页面报「table goods_category does not exist」，就是因为跳过了迁移。如果 zip 里自带了db.sqlite3文件而且人家已经迁移过，第二条可以跳过，但我建议改任何代码之前先看一眼 settings.py 里的数据库配置，确认它用的是 SQLite 还是 MySQL。

有一个配置项是必改的：ALLOWED_HOSTS。老项目的 settings.py 里通常写着ALLOWED_HOSTS = []，如果你用0.0.0.0:8000启动想让局域网里其他电脑访问，浏览器会报 DisallowedHost。开发演示阶段直接改成通配：

ALLOWED_HOSTS = ["*"] DEBUG = True

DEBUG = True是开发模式，Django 会输出详细错误页帮你排查问题；ALLOWED_HOSTS = ["*"]允许任意域名访问。上线部署前再收紧，本地开发这么设最省事。另一个高频问题是静态文件 404，页面能出来但没有任何样式，打开浏览器开发者工具一片红。这时候检查 settings.py 里有没有这两行：

STATIC_URL = "/static/" STATICFILES_DIRS = [BASE_DIR / "static"]

STATIC_URL是浏览器请求静态资源时的 URL 前缀，STATICFILES_DIRS告诉 Django 去哪里找本地静态文件。这两个经常只写了一半，导致后台页面有数据没样式。

跑完runserver，浏览器打开http://127.0.0.1:8000/，看到商城首页或者后台登录页，说明本地环境已经通了。如果这套系统自带了初始化好的管理员账号，通常会写在论文的摘要页或目录文档里；没找到的话，自己造一个：

python manage.py createsuperuser

按提示输入用户名、邮箱、密码，然后访问/admin就能进后台。到这里，系统已经从「一堆文件」变成了「能访问的网站」，接下来要做的就是花时间理解业务链路，再改成自己的东西。

4. 商品、购物车、订单链路怎么在 Django 里落地：核心代码与论文对照

4.1 用户注册登录与 session：商城系统的「入口守卫」

用户模块在这类系统中不会从零造轮子，基本都是基于 Django 内置的auth应用做改造。登录走authenticate加login，密码加密由 Django 的 PBKDF2 算法完成，不需要自己写哈希。身份维持方面，毕设源码一种常见的简化做法是：登录成功后，把用户 ID 放进 session，购物车数据也直接挂在 session 上，这样用户不登录也能加购，登录后合并购物车即可。一个常见的登录视图长这样：

from django.contrib.auth import authenticate, login from django.shortcuts import render, redirect def user_login(request): if request.method == "POST": username = request.POST.get("username") password = request.POST.get("password") user = authenticate(request, username=username, password=password) if user is not None: login(request, user) return redirect("cart:cart_detail") error_msg = "用户名或密码错误" return render(request, "users/login.html", {"error_msg": error_msg}) return render(request, "users/login.html")

authenticate负责校验用户名和密码是否匹配，成功后返回一个 User 对象；login把用户信息写入 session，之后的请求里request.user就能拿到当前登录用户；redirect("cart:cart_detail")用的是 URL name 而不是硬编码路径，这样即使以后改了路由地址，代码不用动。

这段逻辑本身不难，但有两个隐藏问题值得警惕。第一，这里没有验证码也没有登录失败次数限制，真实上线的站会被撞库攻击，毕设演示层面可以接受，但论文里最好不要写成「系统具有完备的防护机制」。第二，login(request, user)之后一定要 return，否则代码会继续往下走到渲染登录页，出现「登录成功但页面没跳转」的诡异现象。

4.2 购物车的两种实现：session 存储与 redis 缓存的取舍

购物车是整个商城系统里最值得拆开讲的部分，因为它直接决定这套代码的复杂度和答辩时的技术亮点。常见的方案有两类：一类是把购物车数据直接塞进 session，实现极简、不依赖额外组件；另一类是把购物车存到 Redis，性能和跨端体验更好，但要多维护一个中间件。

基于 session 的加购视图，核心逻辑如下：

def add_to_cart(request, product_id): product = Product.objects.filter(id=product_id, is_on_sale=True).first() if not product: return JsonResponse({"code": 1, "msg": "商品不存在或已下架"}) cart = request.session.get("cart", {}) key = str(product.id) if key in cart: cart[key]["quantity"] += 1 else: cart[key] = {"quantity": 1, "price": str(product.price)} request.session["cart"] = cart request.session.modified = True return JsonResponse({"code": 0, "msg": "已加入购物车"})

有两个细节特别容易踩。一是价格在放进 session 时用str(product.price)转成了字符串，因为 session 的序列化基于 JSON，DecimalField的值直接放进去会报TypeError: Object of type Decimal is not JSON serializable。二是修改完 session 后要置request.session.modified = True，否则 Django 不保证把改动写回存储，这是 session 方案里最常见的「加购没反应」的坑。

如果换成 Redis 方案，逻辑上的核心变化是：把request.session换成 Redis 的 hash 结构，键名设计成cart:{user_id}，每个用户一个命名空间；同时给键设一个过期时间，比如 7 天，模拟购物车「放着不丢」的体验。你要是论文里写了「系统采用 Redis 做购物车缓存」，那代码里就得真的有 redis 连接和对应的读写调用，否则答辩老师顺着架构图一追，当场穿帮。我的建议是：论文没提 Redis 就老老实实用 session，提了就把单机 Redis 真正接入，别整哨兵集群那些自己都讲不清楚的词。

4.3 订单创建与状态流转：从下单到支付的代码顺序

订单链路是整套系统的价值中枢，下单这个动作在代码上是三段式：先校验库存和价格，再创建订单主表，最后创建订单明细。一个复杂的点在于，明细里存的是商品快照，而总价必须由后端计算而不是信前端传值。下面是完整下单逻辑的一种常见写法：

def create_order(request): if request.method != "POST": return JsonResponse({"code": 1, "msg": "请求方式错误"}) cart = request.session.get("cart", {}) if not cart: return JsonResponse({"code": 1, "msg": "购物车为空"}) user = request.user total = 0 order_items = [] for product_id, item in cart.items(): product = Product.objects.filter(id=int(product_id)).first() if not product or product.stock < item["quantity"]: return JsonResponse({"code": 1, "msg": f"商品库存不足"}) total += product.price * item["quantity"] order_items.append(OrderItem( product_name=product.name, price=product.price, quantity=item["quantity"] )) order = Order.objects.create(user=user, total_amount=total) order.items.bulk_create(order_items) request.session["cart"] = {} request.session.modified = True return JsonResponse({"code": 0, "msg": "下单成功", "order_id": order.id})

这段代码里有三个准则。第一，总价total是在后端循环里累加计算的，绝不直接采用前端传上来的金额，否则用户改个请求参数就能「免费下单」，这是黑匣子里最经典的漏洞。第二，每个商品都做库存校验，任何一个库存不足就整体返回失败，避免生成半张残单。第三，OrderItem存的是product_name和price快照，而不是外键关联商品表，保证下单后商品改名、改价不影响历史订单展示。

订单状态流转一般靠一个choices元组加一个status字段完成，典型状态机是未支付 → 已支付 → 已发货 → 已完成，外加一个已取消。支付环节在这类毕设项目里大多是模拟支付：用户点「去支付」后跳到一个视图，代码里time.sleep(2)模拟支付处理，然后把订单状态改成已支付。如果你的需求要接真实第三方支付，那就得加一个支付平台的异步回调 URL，回调请求来的时候改订单状态。毕设用模拟支付可以，但论文里要诚实地写「模拟支付」，别把没做过真实对接的模块描述成完整支付系统。

4.4 论文与源码怎么对齐：答辩老师最常问的「三处对应关系」

这个 zip 的名字带了「论文」，所以代码跑通之后，最该花时间的是让论文和源码对得上。答辩老师不会逐行读论文，但会挑三处硬点问：第一，论文里写了哪些功能模块，代码里能不能演示；第二，论文里的架构图是不是网上找的，跟你的实际项目对不对应；第三，关键技术点是不是「只写没做」。

我见过最典型的穿帮案例：论文系统功能结构图画了前台展示、用户模块、购物车模块、订单模块，代码里也确实有对应的product_list、user_login、add_to_cart、create_order这些视图，这没问题。但论文「关键技术」一章写「系统采用 Redis 缓存热点商品」，代码里却没有一个 Redis 连接，老师一问「Redis 装在哪、缓存了哪些数据」就卡壳。对这种问题，解决办法只有两条：要么把 Redis 真正接进系统，哪怕只是缓存商品列表；要么把论文里这段删掉，改成你实际用到的技术，比如「基于 session 的购物车实现」，并讲清楚它和 Redis 方案的取舍。代码和论文对齐这件事没有捷径，但有一条笨办法很管用：对照论文目录，把每章提到的技术点逐个在源码里搜索一遍，搜索不到的地方，要么补代码，要么改论文。

5. 把 Django 商城系统从「能跑」调到「能答辩」：避坑清单

5.1 数据库连不上：MySQL 8 的认证插件与 PyMySQL 版本不匹配

• 现象：执行migrate时报Access denied for user 'root'@'localhost'，或者干脆Can't connect to MySQL server。
• 原因：这套源码如果数据库配的是 MySQL，而本机装的是 MySQL 8.0 以上版本，默认认证插件是caching_sha2_password，老版本的 PyMySQL 不支持这个插件。另外也可能是 settings.py 里的密码、端口和本机 MySQL 实际配置不一致。
• 解决：先确认 settings.py 里的DATABASES配置，再用 MySQL 客户端单独测一下账号密码能不能连。能连说明账号没问题，问题在 Python 驱动，升级 PyMySQL 到 2.0 以上；连不上则是账号或权限问题，到 MySQL 里修复授权。这个坑排在第一位，因为它直接卡死后续所有步骤。

5.2 静态资源全部 404：settings.py 里 static 路径设置不完整

• 现象：页面能出来但没有任何样式，打开浏览器开发者工具，/static/css/style.css返回 404，后台管理页面一片素颜。
• 原因：settings.py 里只有STATIC_URL没有STATICFILES_DIRS，或者DEBUG = False时 Django 开发服务器默认不提供静态文件服务。
• 解决：开发阶段把DEBUG设回True，确认STATICFILES_DIRS指向真实存在的目录。路径用BASE_DIR / "static"拼接，不要写死盘符。改完配置后按一次Ctrl+F5强制刷新，浏览器缓存有时候也会背锅，让你以为配置没生效。

5.3 中文乱码与 Excel 导出失败：字符编码和 openpyxl 的坑

• 现象：后台导出订单报表，生成的 CSV 用 Excel 打开全是乱码；或者用 openpyxl 导出 xlsx 时直接报zipfile.BadZipFile: File is not a zip file。
• 原因：CSV 导出时用了系统默认编码，Windows 上是 GBK，而 Python 字符串是 Unicode，写文件时没有指定编码就乱了。Excel 报错通常是代码里先以文件路径打开了一个空句柄，又用workbook.save()保存到同一个路径，导致读到损坏文件。
• 解决：CSV 写文件时指定encoding="utf-8-sig"，这个编码带 BOM，Excel 能正确识别中文；openpyxl 导出时直接在内存里wb.save(response)或者wb.save(io.BytesIO())，不要先 open 再 save。顺带确认 openpyxl 版本在 3.1 以上，老版本写 Excel 容易踩别的坑。

5.4 秒杀/高并发场景的过度设计：为什么演示项目不需要 Redis 集群

• 现象：论文「系统亮点」里写了「利用 Redis 解决高并发下的订单超卖问题」，实际代码里既没有 redis 连接，也没有任何库存保护逻辑，演示时老师一问就露馅。
• 原因：写论文时为了拔高技术含量，往系统上堆了它根本不是同一个量级的架构设计。毕设/课设的并发量就演示教室里那几台电脑，谈集群没有意义。
• 解决：把库存校验和订单状态流转写对，比背一个 Redis 集群架构有价值得多。论文里真要提 Redis，就把「购物车数据缓存到 Redis」这个点落实，单机 Redis 完全够用，别写哨兵、集群这些自己都解释不清的名词。答辩不是比谁的架构大，而是比谁能把自己的系统讲到让别人挑不出刺。

6. 从 Demo 到可演示：数据初始化与答辩前检查清单

系统能跑之后，我花时间最多的不是改代码，而是「让演示不出丑」。这里有两个技巧特别值得分享：一个是用 fixtures 做数据初始化，另一个是答辩前固定一套演示流程。

fixtures 是 Django 自带的「一键灌数据」机制，把商品、分类、测试账号这些数据导出成 JSON 文件，之后在任何机器上都能一条命令恢复：

python manage.py dumpdata goods.Category --output goods/fixtures/category.json python manage.py dumpdata goods.Product --output goods/fixtures/product.json python manage.py loaddata category.json product.json

dumpdata把当前数据库内容导出成 JSON 文件，loaddata在数据搞乱或者换电脑之后一键恢复。这个技巧的救命场景是：答辩前夜手贱删了数据库，不用哭丧着脸重新录几十件商品，一条 loaddata 全回来。

答辩前的检查清单我固定走五步：第一步，创建两个演示账号，管理员一个、普通用户一个；第二步，录入至少三件不同分类的商品，其中一件故意把库存设为零，用来演示「无货不能下单」的校验逻辑；第三步，跑通完整链路：登录 → 加购 → 购物车 → 下单 → 模拟支付 → 后台确认发货，每一步截一张图放进答辩 PPT；第四步，把DEBUG改成False再跑一遍页面，确认静态文件不炸；第五步，用 loaddata 灌一份干净数据，确保演示当天数据状态是可控的。这套流程完整跑过三遍以上，现场基本不会翻车。

最后说点踩出来的教训。我经手这类商城系统最深的感受是：永远不要在答辩前三天才开始改代码，数据模型和订单流程是整套系统里最难临时修改的部分，早一周动手，你才有底气回答「库存超卖怎么处理」「订单状态怎么流转」这类必问题。把模拟数据准备好、把演示路径练熟、把论文里每一句技术描述都在代码里找到落点，这套系统才真正是你的东西。希望帮到你。

本文还有配套的精品资源，点击获取