企业官网建设流程全解析

简介：这份毕业设计源码资源以Python语言为核心，基于Django框架与MySQL数据库构建面向校园场景的二手交易跳蚤市场网站，适合计算机相关专业学生用于毕业设计参考、课程实训及项目二次开发。网站覆盖用户注册登录与个人信息管理、商品发布编辑与分类展示、购物车管理、订单交易流程及安全防护等核心模块，完整呈现了从数据库设计、后端逻辑到前端渲染的全栈实现链路。资源包共494个文件，以50个Python源码、124个pyc编译文件、222张JPG图片、24个HTML页面、7个CSS样式、11个JavaScript脚本和2个SQL数据库脚本为主体，辅以PNG图片、字体及配置文件，压缩包总大小41.29MB，目录结构清晰便于检索。技术栈涉及Bootstrap响应式布局、AJAX异步交互和Git版本管理，已有94人浏览学习，源码、页面素材与数据库脚本可直接导入运行，适合希望快速理解Django项目结构、掌握Web全栈开发流程的学生复用参考。

1. 校园二手交易网站：毕业设计最容易被导师挑刺的三个点，这份源码都提前解决了

做毕业设计选“校园二手交易”这个题目的人每年都不少，但真正能一次性过盲审的却不多。大部分人的系统要么只有发布和浏览，没有完整的交易闭环；要么用户体系只做了个登录注册，权限和状态管理全是窟窿；要么数据库设计得一塌糊涂，两张表硬撑起全部业务。这份基于 Python + Django + MySQL 的校园跳蚤市场网站源码，把上述三个最容易被导师质疑的短板都补齐了：完整的用户体系、商品发布到订单确认的闭环流程、以及足够撑起一篇毕业论文的关系型数据库设计。它的定位很直接——不是教学 Demo，而是一套能直接改改跑起来的毕设系统，适合正在选题或者是代码基础一般、想找可靠蓝图的同学。

2. 项目全貌拆解：从功能模块到技术选型，为什么这套组合最稳

拿到任何一份毕设源码，第一件事不是急着运行，而是先把它的功能边界和技术栈摸清楚。这套校园二手交易系统从功能上看，覆盖了典型 C2C 交易平台的主干链路，而它的技术选型恰好是当前高校毕设中既不容易翻车、又能讲出设计深度的组合。

2.1 功能模块盘点：四个核心角色与完整交易闭环

这套系统的功能划分非常清晰，从使用角色去拆，可以分为四类：游客、注册用户、卖家（也是注册用户的一部分）、管理员。

游客能做的很有限，就是浏览商品列表、查看商品详情、根据关键词搜索商品，这是所有电商类系统的门面功能。而注册用户则在这个基础上，多了完整的交易操作能力：登录后可以发布商品、编辑和下架自己发布的商品、对心仪的商品下单购买、管理自己的订单状态（比如卖家发货后确认收货）、以及对自己的个人资料进行维护。这里有一个细节值得注意，就是买家下单后，卖家的“我发布的商品”列表里会出现待处理的订单提醒，而买家下单后，商品在首页的“可购买”状态会变为“已预订”，这解决了不少同类仿站里“商品被下单了还在卖”的尴尬逻辑问题。

管理员角色的功能独立成一个后台模块。管理员可以审核用户发布的商品（上架或驳回）、管理用户账号（禁用或启用）、查看全站订单流水和统计信息。这套权限划分直接对应了论文里可以写的“系统角色分析与权限控制”一章，导师问起来你有的讲。

额外值得提的是系统内置了简单的数据统计看板，管理员登录后台能看到商品总量、用户总量、订单总量和交易成功率的简单图表。这为论文里的“系统测试与运行结果”提供了现成的截图素材。

2.2 技术选型分析：Django 的 MTV 架构如何承接这个业务场景

选 Python + Django 做毕设，本质上选的是开发效率和安全性。Django 自带 Admin 后台、ORM 数据库映射、CSRF 防护和用户认证体系，这意味着你不需要从零写登录注册和数据库连接代码，可以把精力集中在业务逻辑上。而在论文里，你完全可以把“选用 Django 框架的理由”写成一个小节：基于 MTV（Model-Template-View）设计模式，模型层负责与 MySQL 交互，模板层负责页面渲染，视图层负责业务逻辑处理，三层各司其职，耦合度低，便于维护和扩展。

与直接用 Flask 这类微框架相比，Django 对毕设场景更友好。Flask 虽然灵活，但用户认证、Admin 后台、ORM 这些能力都要自己集成，对于基础一般的同学来说，集成过程中产生的代码量会让你在写论文时无从解释。而 Django 是“全家桶”式的，每一样功能都有官方文档支撑，出错了也更容易在搜索引擎里找到解决方案，这一点在赶 DDLine 的时候是实打实的优势。

前端方面，这套资源没有引入复杂的前端框架，而是使用 Django 模板语言配合原生 JavaScript、CSS 和 Bootstrap 类库来实现页面交互。这么做的好处是显而易见的：你不用维护前后端分离的两套工程，部署的时候不必处理跨域问题，对于毕设答辩的演示环境来说，单体应用结构的稳定性更高，也更容易在实验室的电脑上跑起来。

2.3 代码结构导读：拿到压缩包后先看哪些目录

解压之后你会看到典型的 Django 工程结构，初次接触的同学可能会被一堆文件和目录吓到，这里给一条最省力的路径：manage.py 是入口，一切的运行命令都从它发起；项目配置目录（通常叫 config 或与项目同名）里放着 settings.py、urls.py 等全局配置文件；每个业务 App 目录（用户模块、商品模块、订单模块等）里是 models.py（数据模型）、views.py（业务逻辑）、urls.py（路由映射）等核心文件。

建议你拿到源码后，按照“配置目录 → 业务 App 的 models.py → views.py → templates 模板目录”这个顺序去读代码。先通过 models.py 理解数据库有哪些表、表和表之间是什么关系，再去 views.py 看页面渲染和数据操作是怎么串起来的，最后看模板目录的结构，知道每个页面长什么样。千万不要一上来就运行服务器到处点，那样你只会得到一个“能用但讲不出原理”的系统，答辩时一问三不知，反而比交一个简单但不完整的系统更糟糕。

3. 环境搭建与项目运行：从 Python 版本到 MySQL 配置，一步一步跑起来

任何一个毕设源码，只有先在本地跑起来，后续的二次开发才有基础。这一章以 Windows 环境为例，带你完整走一遍环境配置和项目启动的流程，每一步都会解释“为什么这么做”以及“不这么做会踩什么坑”。

3.1 Python 虚拟环境与依赖安装：隔离环境是避免依赖冲突的第一步

一个最常见的翻车现场是：系统里已经装了很多 Python 库，版本各不相同，直接运行项目导致报错。解决方案是用虚拟环境把项目的依赖隔离出来。

# 创建虚拟环境（在项目根目录下执行） python -m venv venv # 激活虚拟环境（Windows 系统） venv\Scripts\activate # 激活后命令行前会出现（venv）前缀，代表已在虚拟环境中 # 安装项目依赖 pip install -r requirements.txt

这段操作里，第一行的python -m venv venv是调用了 Python 内置的虚拟环境模块，在项目文件夹下生成一个名叫 venv 的独立目录。第二行的激活命令在 Windows 和 Linux/macOS 下是不同的，Windows 是venv\Scripts\activate，而 Linux 和 macOS 是source venv/bin/activate，这一点经常有人搞混。

最后一行安装依赖，requirements.txt文件里已经列出了这个项目需要的所有第三方库及其版本号。我用这个项目的时候注意到它的依赖锁得比较细，Django 版本和 MySQL 驱动版本都有指定范围，这避免了“代码是对的，但库版本不兼容所以跑不起来”的尴尬情况。如果你打开 requirements.txt 发现里面内容很少，通常是类似 Django、mysqlclient（或 pymysql）、Pillow（处理图片上传用）这几个核心依赖。

3.2 MySQL 数据库创建与配置：字符集和时区是第一次启动失败的高发区

Django 项目默认使用 SQLite，但这套毕设题目明确是 MySQL，所以你需要在本地安装 MySQL 服务（或使用集成环境），并创建一个专用的数据库。

# 登录 MySQL（root 用户） mysql -u root -p # 创建数据库，指定 utf8mb4 字符集 CREATE DATABASE campus_market DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; # 创建专用账号（可选，但推荐，论文里写“最小权限原则”有素材） CREATE USER 'campus_user'@'localhost' IDENTIFIED BY 'your_password'; # 授权该账号访问刚才创建的数据库 GRANT ALL PRIVILEGES ON campus_market.* TO 'campus_user'@'localhost'; # 使权限生效 FLUSH PRIVILEGES;

创建数据库时指定utf8mb4字符集是很有必要的。utf8mb4 是 utf8 的超集，能完整支持中文和 emoji 表情符号。如果你的数据库字符集默认是 latin1 或者 utf8（非 mb4），插入中文商品描述时可能出现乱码或者“Incorrect string value”的报错。时区问题则体现在 Django 的settings.py配置里，后面会提到。

数据库建好之后，需要把连接信息同步到 Django 的配置文件中。找到项目配置目录下的settings.py，定位到 DATABASES 配置块，按下述内容修改：

# settings.py 中的数据库配置（示例） DATABASES = { 'default': { 'ENGINE': 'django.db.backends.mysql', 'NAME': 'campus_market', # 刚才创建的数据库名 'USER': 'campus_user', # 数据库用户名 'PASSWORD': 'your_password', # 你的数据库密码 'HOST': '127.0.0.1', # 数据库地址，本地就是 127.0.0.1 'PORT': '3306', # MySQL 默认端口 'OPTIONS': { 'charset': 'utf8mb4', }, } }

这边除了常规的主机地址和端口之外，OPTIONS里的charset参数是一个容易被忽略但很关键的配置。Django 连接 MySQL 时默认使用的字符集可能与你数据库不一致，显式指定utf8mb4可以保证存储的中文不乱码。这个配置在不少旧版本的教程里没有提及，等你在页面里看到“???”的时候，再回头找这个参数就晚了。

3.3 数据库迁移与超级用户创建：让数据表结构落库

配置好数据库连接后，接下来要做的是让 Django 根据项目里的 models.py 自动在 MySQL 中创建对应的数据表。这一步有两个命令：先生成迁移脚本，再执行迁移。

# 生成迁移脚本（根据 models.py 的变化生成） python manage.py makemigrations # 执行迁移，在数据库中创建/更新数据表 python manage.py migrate # 创建超级管理员账号（用于登录 Admin 后台） python manage.py createsuperuser

makemigrations的作用是生成迁移文件，这些文件保存在每个 App 的 migrations 目录下，记录了数据模型的变更历史。migrate则是把迁移文件中记录的变更实际同步到数据库。在论文的系统测试章节里，可以把这一过程的截图放进去，配上“数据持久化层测试通过”的描述。

createsuperuser创建的账号是用来登录 Django 自带 Admin 后台的，管理员运营界面就构建在这个后台之上。注意这个账号跟你系统里注册的用户是两套体系，Admin 账号属于“超级用户”，拥有整个 Django 后台的管理权限。

3.4 启动开发服务器与常见启动报错对照

数据表落库后就到了激动人心的启动环节：

# 启动 Django 开发服务器 python manage.py runserver 127.0.0.1:8000

浏览器访问http://127.0.0.1:8000，能看到系统首页说明你已经成功了一大半。但这只是第一步，真正会消耗你时间的是启动过程中可能出现的报错。这里列几个最常碰到的：

报错 1：ModuleNotFoundError: No module named 'pymysql'或mysqlclient相关错误

原因是 MySQL 驱动没有安装成功。在 Windows 上安装mysqlclient经常因为缺少编译环境而失败，最常见也最省心的补救方案是安装pymysql，然后在项目的__init__.py文件里加上：

# 项目根目录的 __init__.py import pymysql pymysql.install_as_MySQLdb()

这行代码的作用是让 pymysql 伪装成 MySQLdb，Django 就能以操作 MySQLdb 的方式正常连接数据库了。对毕设场景来说，这是一个学界和业界都普遍接受的过渡方案。

报错 2：django.core.exceptions.ImproperlyConfigured: Error loading MySQLdb module

这与上面报错同源，属于驱动缺失或版本不兼容。解决方式同上，或者回头检查 requirements.txt 里的驱动列表。

报错 3：Access denied for user 'campus_user'@'localhost'

这是数据库账号权限问题，说明账号密码错误或者授权没生效。回到 MySQL 命令行执行GRANT ALL PRIVILEGES ON campus_market.* TO 'campus_user'@'localhost';并FLUSH PRIVILEGES;。

报错 4：Unknown collation: 'utf8mb4_unicode_ci'

这个报错一般出现在 MySQL 版本过旧（低于 5.7）的情况下。建议确认一下本机 MySQL 版本，如果确实是旧版本，一个变通方案是修改settings.py中OPTIONS的charset为'utf8'，并把建库语句中的COLLATE utf8mb4_unicode_ci去掉。但从长期角度，我更推荐升级 MySQL 版本，因为旧版本在事务支持和性能上都有明显短板。

4. 核心业务实现：用户体系、商品发布与订单流转的代码级拆解

跑起来只是开始，答辩时导师的注意力会集中在核心业务流程是怎么实现的。这一章深入代码层面，拆解这套系统里最值得讲的三块业务：用户认证、商品发布、以及订单状态流转。理解了这三块，你就基本掌握了整个系统的骨架。

4.1 用户认证与权限控制：Django 内置 User 模型的扩展与登录装饰器应用

这套系统的用户表并不是从零建的，而是在 Django 内置的auth.User模型之上进行扩展。这样做的好处是密码哈希、会话管理、权限校验这些安全机制都是 Django 官方实现，不需要自己造轮子。

# users/models.py（用户模块的数据模型，节选） from django.contrib.auth.models import AbstractUser from django.db import models class UserProfile(AbstractUser): # 扩展字段：手机号 phone = models.CharField(max_length=11, blank=True, null=True) # 扩展字段：头像图片 avatar = models.ImageField(upload_to='avatars/%Y/%m/', default='default_avatar.png') # 扩展字段：信用评分（交易完成后可互相评价） credit_score = models.IntegerField(default=100) class Meta: db_table = 'user_profile' verbose_name = '用户信息' def __str__(self): return self.username

这段代码里最核心的是AbstractUser。它把 Django 原生的用户模型整个继承下来，然后你可以像拼接积木一样往里面加自定义字段。phone字段用来存手机号，avatar是用户头像，upload_to参数指定了头像图片上传到服务器的子目录，且按年月分目录存储，这样文件管理会清晰很多。

在settings.py中需要把这个自定义用户模型指定为默认用户模型：

# settings.py 中的配置 AUTH_USER_MODEL = 'users.UserProfile'

这一行配置的意思是：整个项目里凡是涉及到用户的地方，都用的是你自己扩展的 UserProfile 模型，而不是 Django 原生 User。这个配置必须在第一次migrate之前就写进 settings.py，如果已经执行过迁移再改，会有一堆外键关联问题，处理起来比较痛苦，这个坑后面避坑章节会细说。

登录权限控制则是通过装饰器实现的，Django 提供了现成的工具：

# goods/views.py（商品模块视图，节选） from django.contrib.auth.decorators import login_required from django.shortcuts import render, redirect @login_required(login_url='/users/login/') def publish_goods(request): if request.method == 'POST': # 处理商品发布表单数据 pass return render(request, 'goods/publish_goods.html')

@login_required装饰器的作用是：如果当前用户未登录，直接跳转到login_url指定的登录页面；如果已登录，则正常执行视图函数。这种方式在入口处就完成拦截，比在每个视图函数内部手动判断request.user.is_authenticated要优雅得多，代码也更整洁。论文里可以把这个设计归纳为“基于装饰器的统一登录校验机制”，是个能写到“系统设计亮点”里的点。

4.2 商品发布与图片上传：表单验证与文件存储的实现细节

商品发布是整个系统的核心交互场景。用户在页面上填写商品名称、描述、价格、分类，并上传商品图片。这里的后端逻辑分为两部分：处理表单数据和存储上传的图片文件。

# goods/views.py 中处理商品发布 POST 请求的代码（节选） from django.shortcuts import redirect, get_object_or_404 from .models import Goods, GoodsImage def publish_goods(request): if request.method == 'POST': # 从表单中提取数据 title = request.POST.get('title') desc = request.POST.get('description') price = request.POST.get('price') category = request.POST.get('category') images = request.FILES.getlist('images') # 简单的表单校验 if not title or not price: # 校验不通过则返回错误提示 return render(request, 'goods/publish_goods.html', {'error': '标题和价格是必填项'}) # 创建商品主记录 goods = Goods.objects.create( title=title, description=desc, price=price, category=category, seller=request.user, status='on_sale' ) # 保存上传的图片文件 for img in images: GoodsImage.objects.create(goods=goods, image=img) return redirect('goods:detail', goods_id=goods.id) return render(request, 'goods/publish_goods.html')

逻辑拆开看就三步。第一步，通过request.POST拿到表单提交上来的文本数据；第二步，用 Django ORM 的Goods.objects.create()在数据库里插入一条新的商品记录，seller=request.user把当前登录用户作为卖家关联进去；第三步，遍历request.FILES.getlist('images')拿到所有上传的图片文件，逐个保存到GoodsImage这个图片表中。

这里值得深入研究的是 ORM 的create()方法，它等价于先Goods()实例化一个对象，再save()保存到数据库。使用create()可以在一步内完成创建和落库，逻辑更紧凑。而商品状态status='on_sale'是一个字符串字段，表明商品“在售”。这个字段会在订单流转时被反复修改，理解这一点对于后续订单逻辑的掌握很重要。

在上传图片这一点上，需要去settings.py确认 MEDIA 配置：

# settings.py 中的媒体文件配置 MEDIA_URL = '/media/' MEDIA_ROOT = BASE_DIR / 'media'

MEDIA_ROOT指定了用户上传的文件保存在服务器文件系统的哪个目录，MEDIA_URL则是访问这些文件的 URL 前缀。图片上传后，Django 会把图片存到项目根目录的 media 文件夹下，而在页面上访问这张图片的 URL 是/media/xxx.jpg。不少第一次做 Django 项目的同学会忘记在urls.py中配置媒体文件的访问路由，导致图片上传成功但页面加载不出来。

4.3 订单状态机：从下单到收货的完整流转与异常处理

订单模块是整个系统里业务逻辑最复杂的部分，也是答辩时导师最喜欢深挖的地方。这套系统的订单状态设计是一条典型的线性链路：待付款 → 待发货 → 待收货 → 已完成。每一个状态之间都有严格的边界条件和触发动作。

# order/models.py 中的订单模型（节选） from django.db import models from django.conf import settings class Order(models.Model): ORDER_STATUS = [ ('pending', '待付款'), ('paid', '待发货'), ('shipped', '待收货'), ('completed', '已完成'), ('cancelled', '已取消'), ] goods = models.ForeignKey('goods.Goods', on_delete=models.CASCADE, related_name='orders') buyer = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.CASCADE, related_name='buy_orders') seller = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.CASCADE, related_name='sell_orders') status = models.CharField(max_length=20, choices=ORDER_STATUS, default='pending') price = models.DecimalField(max_digits=10, decimal_places=2) create_time = models.DateTimeField(auto_now_add=True) class Meta: db_table = 'order'

choices=ORDER_STATUS是 Django 的一个特性，它定义了 status 字段的合法取值，任何不在元组中的赋值都会在数据校验阶段被拒绝。这样的设计在数据层面保证了状态不会被随意篡改成未知值，增强了系统的健壮性。

下单和状态更新的核心逻辑在视图中：

# order/views.py 中创建订单的视图（节选） from django.shortcuts import get_object_or_404 from django.contrib.auth.decorators import login_required from goods.models import Goods @login_required def create_order(request, goods_id): goods = get_object_or_404(Goods, id=goods_id, status='on_sale') # 不允许购买自己的商品 if goods.seller == request.user: return render(request, 'order/error.html', {'msg': '不能购买自己发布的商品'}) # 创建订单 order = Order.objects.create( goods=goods, buyer=request.user, seller=goods.seller, price=goods.price, status='pending' ) # 商品状态变为“已预订” goods.status = 'reserved' goods.save() return redirect('order:detail', order_id=order.id)

这一段逻辑里有两个关键点。第一，get_object_or_404(Goods, id=goods_id, status='on_sale')在查询商品时加上了status='on_sale'的过滤条件，意思是只有处于“在售”状态的商品才能被下单购买。这在并发场景下能有效防止同一件商品被两个人同时下单的冲突问题，虽然对于毕设项目来说并发量不大，但这样的设计体现了工程师思维，论文里可以加一句“基于乐观锁思想的商品状态前置校验”。

第二，goods.status = 'reserved'是在订单创建后立刻把商品状态改为“已预订”。这是一种防止超卖的兜底策略。从这里可以看到，商品状态并不只有“在售”和“下架”两个值，中间还有“已预订”这个不可见状态，这套设计比很多简单毕设里只有“在售/已售”两个状态的做法要真实得多。

卖家发货、买家确认收货的状态流转逻辑类似，都是先将 Order 状态更新，再去操作相关的商品状态。这里不再展开代码，但你可以按这个思路去阅读源码里的对应视图，理解状态机的流转脉络。

5. 部署与避坑指南：环境不一致、迁移顺序和文件权限是三大坑

这一章把我在复现和二次开发这套系统时实际踩过的坑集中整理出来，按“现象 → 原因 → 解决”的格式给出，每条都是可以直接照做的排错经验。

5.1 数据库迁移顺序错误：自定义用户模型必须在首次 migrate 前配置完成

现象：按照教程执行python manage.py migrate时报错django.db.migrations.exceptions.InconsistentMigrationHistory，或者明明什么都没改，但后面再执行迁移时提示表已存在。

原因：在使用AUTH_USER_MODEL自定义用户模型的场景下，必须先完成自定义用户模型的配置，再执行首次 migite。如果没有遵守这个顺序，Django 会优先依据默认的auth.User建立表结构，后续你改成了自定义模型，就会产生数据表关联冲突，迁移记录历史变得不一致。

解决：最干净的办法是删库重来。删除数据库中的所有表，或者直接 drop database 后重建库，然后按照下面顺序重新执行：

# 确保 settings.py 中的 AUTH_USER_MODEL 配置正确后执行 python manage.py makemigrations users python manage.py makemigrations goods order python manage.py migrate

先给用户模块单独生成迁移脚本，再处理其他模块，最后统一执行迁移。这么做是为了让数据库在第一时间按自定义用户模型建表，避免后面的外键关系找到错误的用户表。

5.2 图片上传后页面 404：MEDIA_URL 与 urls.py 配置缺失

现象：商品发布成功后，在商品详情页能看到文字信息，但图片区域是一个破图图标或者 404 错误。检查服务器上的 media 目录，图片文件确实存在，但浏览器加载不出来。

原因：Django 开发服务器默认不提供媒体文件的服务，需要你在项目的urls.py中显式配置。缺少这一步，浏览器请求/media/商品图片.jpg时 Django 找不到对应的路由，自然返回 404。

解决：在项目根配置的urls.py中添加代码：

# 项目配置目录 urls.py 中的路由配置（节选） from django.conf import settings from django.conf.urls.static import static urlpatterns = [ # ... 已有的 URL 配置 ] # 开发环境下，将 media 目录映射到 URL if settings.DEBUG: urlpatterns += static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)

加这三行代码后，重新启动服务器，图片就能正常显示了。注意这段配置在论文里可以归入“开发环境静态资源配置”的章节，它本身也暗示了生产环境中应当用专门的静态文件服务器（比如 Nginx）来负责媒体文件的托管，这在答辩时讲出来会是加分项。

5.3 商品价格字段用浮点型导致精度丢失：必须用 DecimalField

现象：价格为 19.9 元的商品，订单详情页计算后显示 19.899999，或者当商品价格经过优惠、满减等计算后，出现尾数错误。

原因：在数据库设计阶段，将价格字段定义成了 FloatField 或直接使用 Django 的 FloatField 模型字段。浮点数在计算机内部以二进制存储，无法精确表示大部分十进制小数，因此任何涉及浮点的计算都会产生微小误差。在涉及金钱的场景，这是致命的。

解决：检查所有涉及金额的字段（商品价格、订单金额、交易金额等），确保使用的是DecimalField：

# 商品价格字段的正确写法 price = models.DecimalField(max_digits=10, decimal_places=2)

max_digits=10表示该字段最多能存储 10 位数字，decimal_places=2表示其中小数点后占 2 位，即最大可存储范围为 99999999.99。设置这两个参数的目的就是让数据库用定点数而非浮点数存储金钱值。这篇项目源码里已经用正确的方式定义了，二开时你只需注意不要再改回 FloatField。

5.4 数据库备份与 .gitignore：SQLite 顺手，MySQL 容易丢数据

现象：项目开发到一半，修改了某个模型或数据后，系统崩溃或误操作导致 MySQL 数据全部丢失，只能从头再来。

原因：很多同学在本地开发调试时，习惯使用集成环境中的 MySQL，但并没有养成定时备份的习惯。而 MySQL 的数据不像是文件工程，它存在于数据库服务中，一旦数据库被误删或服务重装，数据就灰飞烟灭。

解决：将数据导出成 SQL 文件是成本最低的备份手段，建议使用 Django 的 dumpdata 命令进行全量备份：

# 备份所有模型数据到 JSON 文件 python manage.py dumpdata > backup.json # 恢复备份 python manage.py loaddata backup.json

dumpdata命令会遍历当前项目中所有应用的所有模型，把数据序列化为 JSON 格式输出。恢复时使用loaddata命令即可。我建议每次完成一个功能模块的调试后，就执行一次备份，并把备份文件单独存放。另外，还需要检查项目根目录下是否有.gitignore文件，确认venv虚拟环境目录、media上传文件目录、以及本地数据库配置文件都被排除了。这样即使用 Git 管理代码，也不会因为同步媒体文件和密钥配置而引发意外。

5.5 时区配置错误导致订单时间不准：USE_TZ 与 TIME_ZONE 的配合

现象：订单创建时间显示为 UTC 时间，比北京时间晚了 8 个小时。用户看到的“下单时间”和实际下单时间对不上，后台统计的每日订单量也与事实不符。

原因：Django 在settings.py中默认启用USE_TZ = True，时区为TIME_ZONE = 'UTC'。时间戳在存入 MySQL 时以 UTC 时间存储，而在模板中渲染输出时，如果没有激活本地时区，就会按照 UTC 输出，导致时间显示偏差。

解决：明确将时区设置为北京时间：

# settings.py 中的时区配置 TIME_ZONE = 'Asia/Shanghai' USE_TZ = True

需要说明的是，USE_TZ = True仍然建议保持为 True，这代表 Django 的“时区支持”是开启的，好处是所有的时间戳在内部以 UA 标准处理，存储和比较都不会乱。而TIME_ZONE = 'Asia/Shanghai'则告诉 Django 在渲染模板时，将内部时间转换为东八区时间展示给用户。这两行配置配合使用，既能保证底层数据一致性，又能保证用户看到的时间是正确的。

6. 进阶验证：用 Django 自带测试框架搭建核心链路的自动化回归

很多同学的毕设项目有一个通病：开发完功能就完事了，论文里的“系统测试”一章全靠手工截图拼凑。而这份资源在源码中保留了部分基础测试用例，你可以借助 Django 的测试框架，将测试代码写进自己的项目里，既能为论文提供真实的测试数据，又能为你后续二次开发提供一套安全的回归机制。

先在项目中的任意一个 App（例如order/tests.py）中补充测试代码：

# order/tests.py 订单模块测试用例（节选） from django.test import TestCase from django.contrib.auth import get_user_model from goods.models import Goods from .models import Order User = get_user_model() class OrderFlowTestCase(TestCase): """订单核心流程测试""" def setUp(self): # 每个测试方法运行前，创建两个用户 self.seller = User.objects.create_user(username='seller', password='test12345') self.buyer = User.objects.create_user(username='buyer', password='test12345') # 创建一个在售商品 self.goods = Goods.objects.create( title='测试商品', description='单元测试用的商品', price='99.90', seller=self.seller, status='on_sale' ) def test_create_order_changes_goods_status(self): """测试下单后商品状态变为已预订""" # 买家下单 response = self.client.post(f'/order/create/{self.goods.id}/') # 断言请求成功 self.assertEqual(response.status_code, 302) # 从数据库重新读取商品状态 self.goods.refresh_from_db() # 断言商品状态变为 reserved self.assertEqual(self.goods.status, 'reserved') def test_buyer_cannot_buy_own_goods(self): """测试买家不能购买自己发布的商品""" # 让卖家自己给自己下单 self.client.login(username='seller', password='test12345') response = self.client.post(f'/order/create/{self.goods.id}/') # 断言订单数量没有增加 self.assertEqual(Order.objects.count(), 0)

这份测试代码里有三个核心点。setUp方法是 Django 测试框架的生命周期钩子，每个测试方法执行之前，它都会先运行，用来准备数据。self.client是 Django 提供的测试客户端，可以模拟浏览器发起 GET 和 POST 请求。refresh_from_db()这个方法很关键，它的作用是从数据库中重新加载对象的最新状态——因为在创建订单的视图里，我们对商品状态做了修改，而当时内存中的self.goods对象并不会自动感知到数据库的变化。

执行测试的命令也非常简单：

# 运行所有测试用例 python manage.py test # 只运行 order 模块的测试 python manage.py test order

测试通过后，终端会显示 OK，并告诉你运行了几个测试、耗时多少。这两条输出截图放到论文的“系统测试”章节，比手写一段“功能经测试正常”要有说服力得多。

讲一个我自己的习惯：从那以后，我每改一次商品或订单模块代码，就强制跑一遍python manage.py test order。这个习惯帮我拦住过至少三次回归问题——改商品列表排序时不小心把详情页的get_object_or_404条件多加了一个status过滤，改订单状态时调整了状态枚举值但没有同步视图逻辑。测试一旦变红，我就知道是哪里碰断了链路。这份源码给了你一套能跑的场馆，你再给它加上靠谱的护栏，后面的路会顺很多。希望帮到你。

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