1. 为什么选Django做二手交易系统选型逻辑与项目范围做毕设项目第一件事不是打开IDE写代码而是先想清楚我到底要交一个什么东西。二手物品交易系统这个题目在计算机类毕设里属于标准的Web应用方向看起来简单但如果没有明确边界很容易在购物车、支付、实时聊天这些功能上把自己拖死。我选Django核心原因有三个。第一Django自带Admin后台、用户认证、ORM、表单处理这些对二手交易系统来说几乎全是刚需省掉大量重复造轮子的时间。第二Django的MTV架构清楚写起文档和画架构图来非常顺手答辩时好讲。第三部署资料多宝塔面板Python项目管理器uWSGINginx这条路已经非常成熟遇到问题搜得到答案。但这里要提醒一句选Django没问题但千万别把需求清单做太大。我看到很多人做这类系统一开始就规划了站内信、实时聊天、支付接口对接、推荐算法最后做到一半全烂尾。我的做法是先把基础功能做扎实再用扩展功能加分。我最终锁定的功能范围是这样的用户模块注册、登录、退出、个人信息编辑含头像上传商品模块发布闲置商品、编辑下架、商品详情页、图片多图上传检索模块关键词搜索、分类筛选、价格区间筛选订单模块买家下单、卖家确认、交易状态流转后台管理Django Admin管理用户、商品、订单、分类这个范围做完已经足够覆盖一个完整Web系统的所有关键环节而且每一项都符合Django的舒适区。更重要的它可以完整演示用户从注册到下单的完整闭环答辩时最有说服力的就是这条链路。2. 数据库建模二手交易的核心是商品状态机2.1 用户、商品、订单三大核心表设计Django的ORM建模我建议先从核心实体入手。二手物品交易系统里用户、商品、订单是三个最基础的实体。用户这块我直接继承Django内置的AbstractUser而不是自己写一个User表。这样做的好处太明显了内置认证逻辑直接可用request.user拿用户、login_required做登录校验、密码加密存储这些都是现成的。我在User上扩展了手机号和头像两个字段。from django.contrib.auth.models import AbstractUser from django.db import models class User(AbstractUser): phone models.CharField(max_length11, blankTrue, verbose_name手机号) avatar models.ImageField(upload_toavatar/%Y/%m/, blankTrue, nullTrue, verbose_name头像) class Meta: verbose_name 用户 verbose_name_plural verbose_name这里注意如果你在项目中途改了AUTH_USER_MODEL需要先建库再迁移顺序错了会非常麻烦。所以第一步写model时就要把AUTH_USER_MODEL apps.users.User写进settings。商品表是核心中的核心。我设计的时候把分类单独拆了一张表用ForeignKey关联。同时把图片拆成独立的GoodsImage表因为二手商品通常需要传多张图每张图的路径和排序都不同放在一张表里用逗号分隔字段是最差的做法后续做图片删除、轮播展示都很别扭。class Category(models.Model): name models.CharField(max_length30, verbose_name分类名) parent models.ForeignKey(self, nullTrue, blankTrue, on_deletemodels.CASCADE, verbose_name父分类) sort models.IntegerField(default0, verbose_name排序) class Goods(models.Model): STATUS_CHOICES ( (on_sale, 在售), (sold, 已售), (off_sale, 已下架), ) title models.CharField(max_length100, verbose_name标题) desc models.TextField(verbose_name描述) price models.DecimalField(max_digits8, decimal_places2, verbose_name价格) original_price models.DecimalField(max_digits8, decimal_places2, default0, verbose_name原价) category models.ForeignKey(Category, on_deletemodels.PROTECT, verbose_name分类) owner models.ForeignKey(User, on_deletemodels.CASCADE, related_namegoods_list, verbose_name发布者) status models.CharField(max_length10, choicesSTATUS_CHOICES, defaulton_sale, verbose_name状态) views_count models.PositiveIntegerField(default0, verbose_name浏览量) created_at models.DateTimeField(auto_now_addTrue, verbose_name发布时间) class GoodsImage(models.Model): goods models.ForeignKey(Goods, on_deletemodels.CASCADE, related_nameimages, verbose_name商品) image models.ImageField(upload_togoods/%Y/%m/%d/, verbose_name图片) sort models.IntegerField(default0, verbose_name排序)price用DecimalField而不是FloatField这个细节答辩时经常被问到。浮点数在表示0.1这种小数时有精度问题涉及钱必须用定点数。2.2 订单表与状态流转设计订单表关联了买家、卖家和商品这里有一个关键设计订单快照。因为二手商品的标题、价格是会变化的如果订单只是外键关联到商品表卖家把商品改价之后历史订单的成交金额就对不上了。我专门在订单表里冗余了商品标题、成交价、商品图片这几个字段。class Order(models.Model): STATUS_CHOICES ( (pending, 待确认), (confirmed, 已确认), (completed, 已完成), (cancelled, 已取消), ) order_no models.CharField(max_length32, uniqueTrue, verbose_name订单号) goods models.ForeignKey(Goods, on_deletemodels.SET_NULL, nullTrue, verbose_name商品) goods_title models.CharField(max_length100, verbose_name商品标题快照) goods_image models.CharField(max_length255, verbose_name商品图片快照) goods_price models.DecimalField(max_digits8, decimal_places2, verbose_name成交价) buyer models.ForeignKey(User, on_deletemodels.CASCADE, related_namebuy_orders, verbose_name买家) seller models.ForeignKey(User, on_deletemodels.CASCADE, related_namesell_orders, verbose_name卖家) status models.CharField(max_length10, choicesSTATUS_CHOICES, defaultpending, verbose_name状态) remark models.CharField(max_length255, blankTrue, verbose_name备注) created_at models.DateTimeField(auto_now_addTrue, verbose_name下单时间)状态这块我把商品状态和订单状态分开管理。商品状态只有在售、已售、下架。订单状态有待确认、已确认、已完成、已取消。两个状态机的联动逻辑是买家下单后商品状态立即变为已售避免其他人再下单订单被取消或关闭后商品状态恢复为在售卖家确认订单后订单变为已确认等待线下交易双方确认完成订单变为已完成这个流程写清楚之后整个系统的核心业务规则就沉淀下来了后面写视图逻辑时会非常顺畅。2.3 为什么不用级联删除而用PROTECT和SET_NULL创建模型时外键的on_delete参数很多人喜欢无脑用CASCADE觉得省事。但这个项目里我特意做了区分分类被删除时如果下面还有商品用PROTECT阻止删除。因为一个二手交易平台如果允许直接删掉数码产品这个分类会导致所有数码商品失去分类这是数据灾难。用户被删除时他发布的商品用CASCADE。用户都没了商品自然没有保留意义。订单里的商品被删除时用SET_NULL加上商品标题快照兜底。因为删除商品不应当把订单删掉订单有独立保存价值。这些设计在答辩时都可以作为你考虑过数据完整性吗这个问题的回答素材。我建议你在自己的项目里也刻意做这种区分而不是全表统一用CASCADE这能明显拉开你和其他模板项目的差距。3. 核心功能拆解从注册登录到下单闭环3.1 用户认证内置User模型的正确打开方式注册登录是第一个要做的功能。Django内置了login、logout、authenticate这几个方法直接拿过来用就行。不过有几个坑要避开。第一个坑是表单提交的CSRF验证。很多初学者写注册页面时忘记在模板里加{% csrf_token %}结果表单一提交就报403。第二个坑是自定义User模型之后默认的ModelForm不能直接注册要自己写一个UserCreationForm的子类。class RegisterForm(forms.ModelForm): password forms.CharField(widgetforms.PasswordInput, label密码) password2 forms.CharField(widgetforms.PasswordInput, label确认密码) class Meta: model User fields [username, email, phone, password] def clean_password2(self): password self.cleaned_data.get(password) password2 self.cleaned_data.get(password2) if password ! password2: raise forms.ValidationError(两次密码输入不一致) return password2注册视图里用create_user而不是create来保存User对象因为create_user会自动处理密码哈希直接create会把明文密码存进数据库这是非常严重的安全漏洞答辩老师看到这个基本会追问到底。3.2 商品发布与多图上传Media文件配置全流程商品发布是这个系统里信息量最大的表单包括标题、描述、价格、原价、分类、多张图片。这里最值得展开的是图片上传这条链路。配置分三处。首先是settingsMEDIA_URL /media/ MEDIA_ROOT os.path.join(BASE_DIR, media)然后是根URL配置from django.conf import settings from django.conf.urls.static import static urlpatterns [...] if settings.DEBUG: urlpatterns static(settings.MEDIA_URL, document_rootsettings.MEDIA_ROOT)第三步是表单里要用enctypemultipart/form-data否则文件不会随表单提交。这个坑我至少见过十个人踩过页面上表单没有任何报错但后端request.FILES永远是空的。商品发布视图里我用formset处理多图上传。很多人觉得formset难其实在Django里如果你允许用户一次性固定传9张图直接在views里循环处理request.FILES.getlist(images)反而更灵活不用碰formset代码还好懂。images request.FILES.getlist(images) if len(images) 9: messages.error(request, 最多上传9张图片) return redirect(goods:publish) for idx, img in enumerate(images): GoodsImage.objects.create(goodsgoods, imageimg, sortidx)这里要注意图片格式校验我通常会在后端检查文件后缀名和大小不能只靠前端限制。前端通过的图片后端也要把一道关。3.3 商品检索与筛选ORM的Q对象组合查询商品列表页是访问量最大的页面。用户需要一个搜索关键词 分类筛选 价格区间的组合查询。我用Q对象组合条件避免多个filter叠加时出现空查询问题。def goods_list(request): goods Goods.objects.filter(statuson_sale).select_related(category, owner) keyword request.GET.get(keyword, ).strip() category_id request.GET.get(category, ) min_price request.GET.get(min_price, ) max_price request.GET.get(max_price, ) if keyword: goods goods.filter(Q(title__icontainskeyword) | Q(desc__icontainskeyword)) if category_id: goods goods.filter(category_idcategory_id) if min_price: goods goods.filter(price__gtemin_price) if max_price: goods goods.filter(price__ltemax_price) goods goods.order_by(-created_at) paginator Paginator(goods, 12) page_obj paginator.get_page(request.GET.get(page)) ...select_related在这里不是可有可无的优化。列表页要显示商品分类名和卖家用户名如果不做关联查询每个商品都会额外执行一次分类查询和一次用户查询这就是典型的N1问题。加了select_related之后Django会用JOIN一次性把关联数据查出来。这个点在技术答辩里很容易被问到答上来是非常好的加分项。3.4 下单与状态流转事务和并发下的细节下单这个操作涉及两个数据变化创建订单、把商品状态改成已售。这两个操作必须放在一个事务里否则会出现订单创建成功但商品状态没变或者反过来商品卖了但订单没了的情况。我用transaction.atomic()包住整个操作。from django.db import transaction login_required require_POST def create_order(request, goods_id): goods get_object_or_404(Goods, idgoods_id, statuson_sale) if goods.owner request.user: return JsonResponse({code: 0, msg: 不能购买自己发布的商品}) with transaction.atomic(): goods.status sold goods.save() Order.objects.create( order_nogenerate_order_no(), goodsgoods, goods_titlegoods.title, goods_pricegoods.price, goods_imagegoods.images.first().image.url if goods.images.exists() else , buyerrequest.user, sellergoods.owner, ) return JsonResponse({code: 1, msg: 下单成功})下单这里还有一个隐藏的并发问题如果两个人几乎同时点击购买理论上都应该看到商品已售。实际因为Django默认每个请求都会加锁且商品状态更新后再查就会过滤掉所以简单的判断在大多数场景下够用。但如果你想让方案更严谨可以用select_for_update()对商品行加锁再做状态判断。再者为什么要用JsonResponse而不是普通的HttpResponse重定向因为商品详情页通常是Ajax点击下单返回JSON格式数据前端处理起来更灵活能够拦截不能购买自己的商品这类提示而不打断页面浏览。订单号生成也必须考虑并发问题我用的方案是时间戳 用户ID 随机数同时保证唯一性def generate_order_no(): import time, random return time.strftime(%Y%m%d%H%M%S) str(random.randint(1000, 9999))4. 视图、URL与模板Django三层协作的实战体会4.1 FBV还是CBV我的取舍标准Django里有两种视图写法函数视图FBV和类视图CBV。很多教程在入门阶段就展示了CBV的ListView、DetailView看起来很高级但实际在二手交易系统这种业务里我大部分视图都用了FBV只有极少数纯查询的页面用了CBV。原因是二手交易系统的业务规则会不断往细节里加。比如商品详情页要判断当前用户是不是卖家、商品是不是已售、当前用户是否已经下单这些逻辑放在一个普通的函数里非常直接放到CBV的get_context_data里反而要把代码拆得七零八碎。但这不代表CBV没用。商品列表页这种读取数据列表 分页 渲染模板的典型场景ListView可以大幅减少样板代码。我的建议是有特殊情况用FBV纯列表页用CBV。答辩的时候你甚至可以主动聊这个取舍说明你不是只会照搬一种写法。4.2 URLConf设计从模块划分到命名空间项目规模不大的时候urls.py往往被塞得乱七八糟。我的习惯是按业务模块拆分每个App有自己的urls.py在主路由里用include引入并指定namespace。# 项目主urls.py urlpatterns [ path(admin/, admin.site.urls), path(, include(apps.goods.urls, namespacegoods)), path(users/, include(apps.users.urls, namespaceusers)), path(orders/, include(apps.orders.urls, namespaceorders)), ]命名空间的最大价值是模板里的{% url %}标签不再写死路径。比如商品详情页的URL如果直接写/goods/3/哪天路径结构调整了全站都要跟着改。用{% url goods:detail goods.id %}就不会有这个烦恼模板会根据路由配置自动生成正确的URL。后台管理我用的是Django自带的Admin只需要在admin.py里注册模型并简单配置列表页显示字段即可。不需要额外做后台界面这能省下大量时间而且Admin的功能已经能满足管理员对商品和用户的日常管理需要。4.3 模板继承与静态文件项目结构清爽的关键新手写模板最容易出现的问题是一个页面一个完整的HTML文件改一个通用导航栏要改十几个文件。解决之道是模板继承。我搭的模板结构是这样的templates/ ├── base.html # 基础模板包含导航栏、底部、公共CSS/JS ├── goods/ │ ├── list.html # 商品列表页 │ ├── detail.html # 商品详情页 │ └── publish.html # 发布商品页 ├── users/ │ ├── register.html │ ├── login.html │ └── profile.html └── orders/ └── order_list.htmlbase.html里定义{% block content %}和{% block title %}子模板只需要填内容块。我用Bootstrap 5搭建前端界面响应式布局在手机端也能正常展示二手交易这个场景用户很可能用手机逛这个细节在演示时很加分。CSS、JS、图片这类静态文件我统一放在static/目录并在settings里做了配置。有一个坑必须记住DEBUGFalse之后Django默认不再处理静态文件这是部署阶段最常遇到的问题。5. 从本地到公网宝塔面板部署Django项目的完整过程5.1 服务器环境准备部署我推荐用宝塔面板配CentOS操作门槛最低适合毕设演示需要。整体流程是装宝塔 - 装Python项目管理器 - 安装Python版本 - 安装MySQL - 配置uWSGI - 配置Nginx。用宝塔的Python项目管理器可以直接创建Django项目它会自动配置好uWSGI日志省掉很多手写配置文件的麻烦。但它的默认配置不一定满足所有场景比如静态文件路径需要手动改。依赖版本必须锁定。我踩过一个大坑本地开发用的是Django 4.2服务器上宝塔默认装的是Python 3.6pip install Django自动装了Django 3.x结果某个ORM语法不兼容页面全报错。正确的做法是在项目根目录生成requirements.txt在部署环境里一键恢复pip freeze requirements.txt # 服务器上执行 pip install -r requirements.txt5.2 静态文件与Media文件的Nginx配置Django项目的静态资源有两种一种是自己写的CSS、JS、图片放在static/目录另一种是用户上传的图片放在media/目录。部署时这两类都建议交给Nginx直接处理不要经过Django应用进程否则每个图片请求都会消耗一次Python进程的资源页面加载会非常慢。先执行collectstatic收集静态文件python manage.py collectstatic --noinput然后在Nginx配置里加两段locationlocation /static/ { alias /www/wwwroot/your_project/static/; } location /media/ { alias /www/wwwroot/your_project/media/; }这里有个非常隐蔽的坑如果MEDIA_URL是/media/而Nginx的alias路径末尾少写一个斜杠图片会全部404。nginx的alias和root规则不同alias是精确替换root是拼接目录。用alias时路径写法和URL地址必须严格对应细节差一个斜杠就是天壤之别。5.3 uWSGI与Nginx的socket通信uWSGI和Nginx的交互我用的是socket文件方式。uWSGI配置里指定[uwsgi] chdir /www/wwwroot/your_project module your_project.wsgi:application master true processes 2 threads 2 socket 127.0.0.1:8001 chmod-socket 664 vacuum trueNginx这里用uwsgi_pass把请求转发给uWSGIlocation / { include uwsgi_params; uwsgi_pass 127.0.0.1:8001; }用socket文件方式比HTTP方式通信效率更高。如果你看到502错误优先排查uWSGI进程是否启动、socket端口是否正确、日志里有没有具体报错。日志是救命稻草uWSGI的日志里会打出完整的Python异常栈很多部署问题在本地根本复现不了全靠看日志定位。5.4 关闭DEBUG模式的配置清单部署上线时必须把DEBUGFalse不然一旦代码报错浏览器会显示完整的错误堆栈和服务器路径这是严重的信息泄露答辩演示时也很尴尬。但DEBUGFalse会带来一系列连锁变化你需要检查这么几项ALLOWED_HOSTS必须配置不然请求会报DisallowedHost错误静态文件不再由Django处理必须用collectstatic Nginx兜底数据库连接建议改用配置化的方式账号密码不要硬编码在代码里我的settings里是这样做的DEBUG False ALLOWED_HOSTS [你的域名或IP] DATABASES { default: { ENGINE: django.db.backends.mysql, NAME: secondhand_db, USER: secondhand_user, PASSWORD: 你的密码, HOST: 127.0.0.1, PORT: 3306, } }6. 性能优化与安全细节让项目经得起追问6.1 数据库查询优化select_related与prefetch_related商品详情页通常会展示商品图片、卖家信息、卖家在售商品。这里的查询如果不加优化至少会触发6-8条SQL。我的做法是详情页视图里用select_related关联商品分类和卖家用prefetch_related预取商品图片和卖家其它在售商品。goods get_object_or_404( Goods.objects.select_related(category, owner) .prefetch_related(images), idgoods_id ) seller_other_goods Goods.objects.filter(ownergoods.owner, statuson_sale) \ .exclude(idgoods.id) \ .select_related(owner)[:6]这两个方法的区别在于select_related用于单个外键关联原理是SQL JOIN一次查询把关联数据查出来prefetch_related用于多值关联原理是先查主表再根据主表ID批量查关联表避免逐条查询。记住这个区别之后你的优化方向就会清晰很多。还有一个细节首页和列表页的浏览量views_count每次访问都执行update会影响性能但对毕设项目来说完全够用不用过度设计。如果你想让浏览量更准确至少要用F表达式原子更新不要先查出来加一再存回去否则并发访问会丢失计数。Goods.objects.filter(idgoods_id).update(views_countF(views_count) 1)6.2 安全细节上传校验、密码处理与权限控制安全性这块我觉得有三个地方必须写扎实。第一图片上传校验。只在前端限制文件类型是不够的攻击者可以绕过前端直接提交恶意文件。后端需要用Python的imghdr或文件签名方式检查不能用后缀名判断因为后缀名可以随意伪造。这个点在信息安全类答辩里几乎必问。第二密码必须哈希存储。Django的create_user默认用PBKDF2加盐哈希非常安全前提是你不要绕过去直接用create。第三权限控制。发布商品需要login_required编辑和删除商品要判断当前请求的用户是商品所有者否则就返回403。这个判断不能只在模板里用{% if user goods.owner %}隐藏按钮后端视图里必须再做一层校验因为用户可以绕过前端直接构造POST请求。login_required def edit_goods(request, goods_id): goods get_object_or_404(Goods, idgoods_id) if goods.owner ! request.user: return HttpResponseForbidden(无权操作) ...6.3 可维护性命名规范与代码注释策略毕设项目代码量不大但代码讲解环节却非常消耗精力。我的经验是尽量在写代码时就把命名规范保持一致视图函数用动词开头模型类用名词单数URL名称用模块加动作。例如goods:publish、goods:detail、orders:create。这样讲代码时不用看注释也能自解释。注释不写废话。# 遍历图片列表这种注释毫无价值。我一般只给复杂逻辑写注释解释为什么这样做而不是解释代码在做什么。比如事务那块注释就是必须原子操作否则会出现订单无商品或商品无订单的脏数据。7. 项目讲解与答辩一条主线走到底7.1 用一条用户故事串起整个项目代码写完之后最重要的事是准备讲解逻辑。我自己的经验是不需要把每个函数都讲一遍也不需要从头到尾按代码行数走而是要有一条清晰的用户故事主线。我是按这个顺序讲的用户注册登录讲Django认证机制、密码哈希、session发布商品讲Media文件上传、图片处理、字段校验浏览检索讲QuerySet查询、过滤条件组合、分页下单交易讲事务、状态流、数据库设计后台管理讲Admin的使用与权限部署上线讲Nginx uWSGI架构和静态文件分离这条主线走完整个系统的全貌就清楚了。讲解时配合系统演示先注册一个账号发布商品再换一个账号购买最后在Admin后台查看订单数据答辩老师们就能直观理解项目价值。7.2 预测高频率追问与自己的加分回答准备答辩至少要把下面几个问题提前想好答案。为什么选Django回答框架开发效率高、自带Admin后台、ORM安全防SQL注入、认证体系完善、生态成熟部署方便。再补一句项目核心是业务逻辑的完整闭环Django让我能把更多精力放在业务设计上这是个很讨巧的说法。数据库表是怎么设计的建议现场画一下用户、商品、订单的ER图并解释为什么在订单里冗余商品信息为什么分类删除用PROTECT为什么用户删除用CASCADE。如何防止SQL注入Django ORM底层用参数化查询天然防注入。你可以补充说明项目中所有数据库操作都通过ORM完成没有拼接原生SQL。遇到的最大的坑是什么这个话题你讲过真实性越强越有说服力。我的真实案例是部署阶段DEBUG关闭后静态文件全部404的问题排查过程、原因分析、解决方法都讲清楚比背模板强得多。7.3 为自己留一条清晰的扩展路线如果答辩现场被问到这个系统还有什么可以改进的地方我建议准备两三个故意留白的扩展点既表现出你有思考深度又不会给自己挖坑。我通常提三个方向接入消息通知用户对商品感兴趣时可以给卖家发私信核心是站内信通知表和未读状态管理防重复下单的弱并发优化用select_for_update配合行锁更严谨搜索升级为全文检索当前用icontains做模糊匹配数据量上来之后可以用Whoosh或Elasticsearch这三个方向每一个都够你展开聊两三分钟而且都落在Django生态内不会显得好高骛远。8. 我从这个项目裡沉淀的几点实在经验最后分享几个这套项目做完之后我个人觉得最有通用价值的经验。第一开发时先跑通最小闭环再补细节。我见过有些同学一上来就研究如何用Redis做购物车结果连最基本的发布商品页面都还没跑通。最小闭环应该是注册登录 - 发布商品 - 看到商品 - 下单。这条链路通了系统骨架就稳了后面再往里面填功能都来得及。第二虚拟环境一定要用。隔离依赖版本最大的价值不是多高级而是让你在部署时不会因为系统里乱七八糟的环境变量和依赖版本崩溃。本地一个项目建一个虚拟环境pip freeze导出依赖别偷懒。第三Git提交要小步勤快。这个习惯我在做项目时体会很深有时候改了一下午代码第二天想回退某个功能如果只有一次大提交根本不知道该回退到哪。每次改完一个功能就提交一次commit message写清楚做完了什么后期写文档和演示都能随时切换回之前的可运行版本。第四文档和代码同步更新。做这种项目的过程中说明文档和代码最后一定会分家等全写完再补文档很容易遗漏关键细节。我的做法是每写一个模块就顺手把模块对应的设计说明、核心表字段、接口路径记进文档里最后汇总时基本只做格式统一不用回溯记忆。这套系统的代码量不算大但完整覆盖了用户认证、文件上传、复杂查询、事务处理、部署上线这些Django核心技术点。做完一遍你会发现不仅手上的项目能答辩对Web开发的整体理解也会上一个台阶。如果你正在规划类似的项目希望这篇分享能帮你少走几步弯路。