Django校园二手交易平台：MTV、查询与流式导出部署

简介这份面向高校计算机专业学生与毕业设计学习者的文档围绕基于 Django 框架搭建校园二手交易平台展开可帮助读者理解 Web 项目从选题、论证到落地的完整思路。文档以 Python 语言、Django 技术与 MySQL 数据库为主线梳理了 B2C、O2O 冲击下传统零售的转型背景以及校园闲置图书、手机、游戏卡带等物品线上交易的现实需求并给出系统功能设计、数据库建模与论文写作结构重点说明线上交易在便捷性与 24 小时咨询议价方面的优势。压缩包仅含 1 个 docx 文件体积约 2.24MB内含中英文摘要、关键词、目录及各章节正文可作为课程设计或毕业设计的写作参考。目前已有 252 人学习下载适合需要快速搭建论文框架、补齐技术选型说明与可行性分析的学习者借鉴。1. 校园二手交易为什么用 Django 落地更省事毕业季一到宿舍楼下的二手群就开始刷屏教材、显示器、自行车、小冰箱出物和求购都挤在两周内。给这个场景做一套「诚交」式的校内二手交易平台第一反应往往是用 Flask 或 FastAPI 更轻,真写下去才发现真正耗时间的不是路由而是用户体系、商品多图、订单状态流转和后台增删改查。Django 把 ORM、Admin、表单校验、权限、会话这几件基础设施一次性给全论文要讲的结构也清晰MTV 各自对应什么数据表怎么设计查询和删除对象怎么控制图片和订单文件怎么流式返回。这套东西适合计算机专业的课程设计、毕业设计也适合刚接手 python django 项目、想把一个 django 项目从能跑到讲得清的人。2. MTV 模式下「诚交」二手交易平台的模型设计2.1 MTV 三个字母在这个平台里的具体落点django 框架常被概括成 MTV但很多人讲不清它在二手交易里的落点。Model 负责商品、订单、收藏这些持久数据和它们之间的关系Template 负责商品列表页、详情页、个人中心这些渲染结果View 负责接住请求从 Model 取数、做筛选和状态判断再交给 Template。django 之 mtv 模式真正的作用是强制把数据长什么样和页面长什么样分开改字段不用动模板改样式不用动查询逻辑。补一句容易漏的URLconf 是把 URL 映射到 View 的第四层论文里如果只写 MTV 三个字母答辩时大概率会被追问请求怎么进来的把 urls.py 那一层补上更完整。对二手交易这种状态多的业务Model 层还承担一个隐性职责把状态约束写死。商品能不能下单、订单能不能取消、收藏有没有重复这些判断放在 Model 的方法和约束里比散在十几个 View 里可靠得多。2.2 四张核心表的字段设计平台的核心数据关系并不复杂但字段类型选错会留下长期隐患。最典型的是价格用 FloatField 存金额几次加减之后就会出现 19.999999 这种值前端展示和订单对账都很难看正确做法是 DecimalField。下面是这个题目里常见的建表方案用 MySQL 作为后端库。模型关键字段字段类型设计说明User继承 AbstractUserstudent_noCharField(20, uniqueTrue)学号作为登录凭证比邮箱更贴校园场景campusCharField(30)校区用于就近筛选和同城自提creditIntegerField(default100)信用分爽约、虚假描述可扣分Categoryname / parentCharField(20) / FK(self)自关联实现两级分类如教材-考研Producttitle / priceCharField(60) / DecimalField(8,2)金额必须用 Decimal避免浮点误差seller / statusFK(User) / SmallIntegerFieldstatus 用整数枚举0 在售 1 预订 2 已售 3 下架created_atDateTimeField(auto_now_addTrue)列表默认按它倒序ProductImageproduct / imageFK(Product) / ImageField一商品多图用外键而不是存逗号串Orderorder_no / buyer / productCharField(32) / FK / FKorder_no 用时间戳加随机串方便人工核对amount / statusDecimalField(8,2) / SmallIntegerField订单状态单独枚举不与商品状态混用Favoriteuser / productFK / FKMeta 里加 unique_together 防重复收藏图片单独建表而不是在 Product 上塞一个 JSON 字符串原因是二手商品图往往要控制展示顺序、要能单独删除某一张外键结构让这些操作都变成普通的 django 执行查询。2.3 用 django 创建 app 并把模型落到 MySQL一个可持续维护的 django 项目不会把所有代码堆在默认 app 里。常见做法是按业务拆成 accounts用户与认证和 trade商品、订单、收藏两个 appdjango 创建 app 的命令很简单难的是拆完之后 settings 里的注册和引用路径要同步改。# Windows 10 下创建虚拟环境并激活 python -m venv venv venv\Scripts\activate # 安装依赖Django 本体、MySQL 驱动、图片处理库 pip install django pymysql pillow # 创建项目骨架注意结尾的点避免多套一层目录 django-admin startproject config . # 创建两个业务 app python manage.py startapp accounts python manage.py startapp trade命令执行完目录下会多出 accounts 和 trade 两个文件夹。很多人卡在下一步app 建好了但模型不生效因为没在 settings.py 的 INSTALLED_APPS 里登记。同时要注册 AUTH_USER_MODEL因为自定义用户模型必须在第一次 migrate 之前确定建库之后再改会非常麻烦。# config/settings.py INSTALLED_APPS [ django.contrib.admin, django.contrib.auth, django.contrib.contenttypes, django.contrib.sessions, django.contrib.messages, django.contrib.staticfiles, accounts, # 用户与认证 trade, # 商品、订单、收藏 ] AUTH_USER_MODEL accounts.User # 必须在首次 migrate 前设置 DATABASES { default: { ENGINE: django.db.backends.mysql, NAME: campus_trade, USER: root, PASSWORD: your_password, HOST: 127.0.0.1, PORT: 3306, OPTIONS: {charset: utf8mb4}, # 支持 emoji 和生僻字 } }utf8mb4 这一项不要省。二手商品标题里出现一个 emoji 或者生僻姓氏用 utf8 会直接写入报错而报错信息往往指向 ORM 层排查时容易误判成代码问题。数据库本身也要用 utf8mb4 建库CREATE DATABASE campus_trade DEFAULT CHARSET utf8mb4;。2.4 迁移与 Django Admin 后台初始化模型写完接下来是迁移。这一步的顺序不能乱先 makemigrations 生成迁移文件再 migrate 落库中间如果报Table doesnt exist或者外键指向错误八成是自定义用户模型和第一个 app 的依赖顺序没理清。python manage.py makemigrations accounts python manage.py makemigrations trade python manage.py migrate # 建一个后台管理员用于演示增删改查 python manage.py createsuperuserdjango 教程里经常跳过 Admin但对校园二手平台来说它价值很高老师要看的后台管理基本可以直接用它交差。在 trade/admin.py 里把 Product 注册进去配上 list_display、list_filter、search_fields一个能按状态筛选、按标题搜索、批量改状态的后台几分钟就能用。# trade/admin.py from django.contrib import admin from .models import Product, ProductImage, Order admin.register(Product) class ProductAdmin(admin.ModelAdmin): list_display (title, seller, price, status, created_at) list_filter (status, category) # 右侧筛选器 search_fields (title, seller__student_no) # 双下划线跨表搜索 list_editable (status,) # 列表页直接改状态 inlines [] # 需要时挂 ProductImagelist_editable 和 list_display 有冲突规则被 list_editable 指定的字段必须出现在 list_display 里第一个字段不能可编辑。这类小约束不踩一次很难记住。3. django 执行查询与删除对象商品列表的筛选链路3.1 QuerySet 惰性求值与商品列表页django 执行查询的核心是 QuerySet它最大的特点是惰性写Product.objects.filter(status0)时数据库没有任何动静只有真正迭代、切片、len()、list() 的时候才发 SQL。理解这一点能解释很多为什么我的查询没生效的困惑也能避免重复查询。二手平台首页的典型需求是列出在售商品、按时间倒序、分页展示代码不长但每行都有讲究。# trade/views.py from django.core.paginator import Paginator from django.shortcuts import render from .models import Product def product_list(request): # 只取在售商品用 select_related 一次性把卖家信息带出来 qs (Product.objects .filter(status0) .select_related(seller, category) .order_by(-created_at)) # 分类和校区作为可选筛选条件 cat request.GET.get(cat) if cat: qs qs.filter(category_idcat) paginator Paginator(qs, 12) # 每页 12 件适配三列网格 page paginator.get_page(request.GET.get(page)) return render(request, trade/list.html, {page: page})filter 里面的条件会拼成 WHEREorder_by 决定排序。select_related 是这里最关键的一行模板里每件商品都要显示卖家昵称不写它就会触发 N1 查询12 件商品发 13 条 SQL写了它只有一条 JOIN。Paginator 的第二个参数是每页条数校园网环境下建议控制在 12 到 24 之间太大首屏加载会明显变慢。get_page 比 page 方法更宽容页码非法时返回第一页而不是抛 404。3.2 用 Q 对象和 F 表达式处理多条件筛选真实的搜索框远比单条件复杂用户可能输入关键字同时勾选只看本校区、价格 50 元以下。多个 filter 链式调用是 AND 关系一旦需要 OR 就必须引入 Q 对象。价格区间和浏览量自增则是 F 表达式的主场。写法生成的语义适用场景filter(a1, b2)a1 AND b2固定条件组合filter(Q(a1) | Q(b2))a1 OR b2关键字匹配标题或描述filter(price__range(0, 50))price BETWEEN 0 AND 50价格区间筛选filter(title__icontainskw)不区分大小写模糊匹配搜索框update(viewsF(views) 1)数据库层自增不读回内存浏览量、收藏数from django.db.models import Q, F def search(request): kw request.GET.get(kw, ).strip() campus request.GET.get(campus) max_price request.GET.get(max_price) qs Product.objects.filter(status0) if kw: # 标题或描述任一命中即可两个条件用 OR 连接 qs qs.filter(Q(title__icontainskw) | Q(desc__icontainskw)) if campus: qs qs.filter(seller__campuscampus) if max_price: qs qs.filter(price__ltemax_price) # 详情页浏览量自增在数据库端完成避免并发覆盖 Product.objects.filter(pk1).update(viewsF(views) 1) return render(request, trade/search.html, {page: qs})F 表达式的价值在并发场景才体现出来。如果写成p.views p.views 1; p.save()两个人同时打开详情页后写的会把前一次的加一覆盖掉浏览量长期偏低。用 update 加 F自增在数据库端原子完成不需要加锁。icontains 在 MySQL 上依赖排序规则默认 utf8mb4_general_ci 已经是大小写不敏感中文检索则不受影响。3.3 django 执行查询-删除对象的三种写法删除是二手平台里最容易被写错的操作。django 执行查询-删除对象常见有三种粒度用错粒度要么删不干净要么误删整表。# 写法一删单个对象先取再删能触发模型的 delete() 和信号 p Product.objects.get(pkproduct_id) p.delete() # 写法二删 QuerySet返回值是 (总删除数, {模型名: 数量}) n, detail Product.objects.filter(status3, sellerrequest.user).delete() # 例detail 可能是 {trade.ProductImage: 6, trade.Product: 2} # 说明级联删除把 6 张关联图片一起删了 # 写法三软删除不真删数据只改状态 Product.objects.filter(pkproduct_id).update(status3, deleted_attimezone.now())这三种写法差别很大。写法一能触发模型上重写的 delete() 方法适合需要在删除前清理图片文件或写审计日志的场景代价是每个对象一次查询。写法二直接生成 DELETE 语句效率高级联规则由外键的 on_delete 决定CASCADE 会连带删掉关联图片记录PROTECT 会直接抛异常阻止删除。二手平台上商品一旦有订单就不该被硬删除外键应设成 PROTECT 或 SET_NULL。写法三是生产环境更推荐的做法也就是软删除。校园二手交易里买家可能回头查三个月前的订单商品记录被真删掉会导致订单详情页报错。软删除需要配合自定义 Manager默认查询自动过滤掉已删除记录class ActiveManager(models.Manager): def get_queryset(self): # 默认只返回未软删除的记录 return super().get_queryset().filter(deleted_at__isnullTrue) class Product(models.Model): deleted_at models.DateTimeField(nullTrue, blankTrue) objects ActiveManager() # 业务查询用这个 all_objects models.Manager() # 后台需要看全量时用这个提示软删除会改变数据行的可见性写任何统计查询比如在售商品总数之前先确认用的是 objects 还是 all_objects混用会导致数字对不上。3.4 分页、关联查询与常见性能坑列表页一旦加上收藏数、图片数这类统计字段性能问题就会冒出来。每件商品显示3 张图如果都去product.productimage_set.count()12 件商品又是 12 条 SQL。正确做法是用 annotate 在查询阶段把计数算出来。from django.db.models import Count qs (Product.objects .filter(status0) .annotate(img_countCount(productimage)) # 一条 SQL 带出图片数 .prefetch_related(productimage_set) # 需要展示图片时预取 .order_by(-created_at))select_related 适用于外键和一对一prefetch_related 适用于多对多和反向外键。反向外键关系不能用 select_related写了会直接报错这是新手最常见的报错之一。另外注意 annotate 和 filter 的顺序先 filter 再 annotate计数只统计过滤后的结果反过来会得到全量计数两种结果看起来都合理非常隐蔽。4. StreamingHttpResponse 的 content_type 与 content-disposition4.1 二手平台的多媒体资源管理选型二手交易平台的图片量比一般管理系统大一件商品 3 到 6 张图还要生成缩略图给列表页用。django 多媒体资源管理系统常见做法是 ImageField 配合 Pillow上传时在模型的 save 或信号里压缩出缩略图原图和缩略图分目录存放。开发阶段由 django 直接托管 MEDIA 静态资源部署时交给 nginx这条边界要在 settings 里写清楚否则上线后图片全 404。订单导出是另一个高频需求卖家想看本月成交明细管理员要拉一份全站订单做统计。文件一大会占用大量内存尤其是把几万行订单一次性拼成字符串再返回。django streaminghttpresponse 参数 content_type 和 content-disposition 就是为这种流式下载场景准备的响应体分块生成浏览器边收边存。4.2 content_type 与 content-disposition 两个参数怎么设StreamingHttpResponse 第一个位置参数是迭代器不是字符串content_type 决定浏览器如何理解这个响应Content-Disposition 决定是内联预览还是触发下载。参数常见取值作用与注意点content_typetext/csv; charsetutf-8导出 CSV必须带 charset否则 Excel 打开乱码application/octet-stream通用二进制流浏览器一律下载image/jpeg图片直出用于受权限保护的商品原图Content-Dispositionattachment; filenamea.csv触发下载文件名含中文会乱码attachment; filename*UTF-8%E8%AE%A2%E5%8D%95.csvRFC 5987 编码中文文件名的正确写法inline浏览器内直接展示适合图片和 PDF4.3 导出订单 CSV 的流式写法csv 模块本身要求写文件对象直接写内存字符串再返回就失去了流式的意义。常见技巧是写一个只实现 write 方法的伪对象把每次写入的行通过生成器 yield 出去。import csv from django.http import StreamingHttpResponse from .models import Order class Echo: 只实现 write 的伪文件对象把 csv 的写入变成可迭代的返回 def write(self, value): return value def export_orders(request): rows (Order.objects .filter(buyerrequest.user) .select_related(product) .values_list(order_no, product__title, amount, status) .iterator(chunk_size500)) # 分批从数据库取不全量载入 writer csv.writer(Echo()) def row_gen(): yield \ufeff # BOMExcel 识别 UTF-8 的关键 yield writer.writerow([订单号, 商品, 金额, 状态]) for r in rows: yield writer.writerow(r) resp StreamingHttpResponse(row_gen(), content_typetext/csv; charsetutf-8) resp[Content-Disposition] attachment; filename*UTF-8%E8%AE%A2%E5%8D%95%E5%AF%BC%E5%87%BA.csv return respiterator(chunk_size500) 让数据库游标分批返回结果几万行订单不会一次性堆进内存。开头的 \ufeff 是 BOM只加 charset 还不够Windows 上的 Excel 不认没有 BOM 的 UTF-8 文件打开就是乱码这一点在答辩演示时特别容易翻车。Content-Disposition 里的 filename 用百分号编码表示订单导出.csv写死中文文件名在部分浏览器上会直接丢失文件名。4.4 大文件与中文文件名的三个坑第一个坑是把 StreamingHttpResponse 用在需要 Content-Length 的场景。流式响应的长度事先未知想要下载进度条就得自己算总行数再设置响应头。第二个坑是中间件干扰某些会读取完整响应体的中间件比如压缩、日志会让流式退化成一次性加载排查时可以先注释掉中间件验证。第三个坑是导出图片时的权限判断——导出接口如果没有登录校验别人改一下 URL 参数就能拉到全部订单务必加 login_required 并在查询里用 request.user 收口。注意图片这类已知长度的文件优先用 FileResponse它会自动处理 Content-Length 和 Range 请求StreamingHttpResponse 留给长度不可预知的动态内容。5. waitressnginx 的 Windows 部署与接口验证开发阶段python manage.py runserver很方便但它单线程、带调试信息不能直接对外。python django 项目在 Windows 10 上部署的常见组合是 waitress 做 WSGI 服务器、nginx 做反向代理和静态资源服务原因是 waitress 纯 Python 实现不需要额外编译环境比在 Windows 上折腾 uWSGI 省事。先关掉调试模式这决定了静态文件由谁托管。# config/settings.py 生产段 DEBUG False ALLOWED_HOSTS [127.0.0.1, localhost] STATIC_ROOT BASE_DIR / staticfiles # collectstatic 的输出目录 MEDIA_ROOT BASE_DIR / media然后收集静态文件并启动 waitresspython manage.py collectstatic --noinput pip install waitress waitress-serve --listen127.0.0.1:8000 config.wsgi:application--listen指定绑定地址和端口只绑 127.0.0.1 意味着外部必须经过 nginx 才能访问这是推荐做法。config.wsgi:application指向项目里的 WSGI 入口。nginx 侧的关键是静态和媒体目录用 alias 直出其余请求转发给 waitressserver { listen 80; server_name localhost; client_max_body_size 20m; # 二手商品多图上传默认 1m 不够 location /static/ { alias C:/proj/staticfiles/; } location /media/ { alias C:/proj/media/; } location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }client_max_body_size 是最常被忽略的一行默认 1MB 会让上传三张手机照片就返回 413。部署完不要只看首页能不能打开用几条命令确认每层都通# 1. 绕过 nginx确认 waitress 本身正常 curl -I http://127.0.0.1:8000/ # 2. 走 nginx确认反代生效 curl -I http://localhost/ # 3. 确认静态文件由 nginx 直出响应头没有 Django 痕迹 curl -I http://localhost/static/css/app.css第 3 条返回 404 时先检查 collectstatic 是否真的把文件放到了 STATIC_ROOT再检查 nginx 的 alias 路径斜杠是否和 location 一致——location /static/配alias C:/proj/staticfiles少一个斜杠会导致路径拼接错误。最后一个技巧是导出接口的验证用curl -I看订单导出的响应头里 Content-Disposition 是否带上了编码后的文件名再实际下载一次用 Excel 打开确认 BOM 生效、中文不乱码。这两步做完图片上传、列表分页、订单导出这三条主链路就算在 Windows 上跑通了。本文还有配套的精品资源点击获取