尧图网页设计 
毕业设计季又是各种“基于XX系统”扎堆的时候。如果你正在纠结“基于Django校园二手闲置物品买卖网上商城”这个题目那这篇文章你应该早点看到。前后帮人改过不少这类项目从数据表设计到论文排版从答辩PPT到现场演示踩过的坑和捷径都在这。这篇内容主要面向准备做商城类Django项目的同学也适合想系统梳理Django开发流程的初学者目标是让你从“只会跑通代码”变成“能讲清楚设计思路、扛得住答辩追问”。1. 项目定位与整体设计思路1.1 为什么选择Django做二手交易商城选Django来做校园二手交易平台不是因为它最潮而是它最适合毕业设计这个场景。第一Django自带Admin后台你不需要额外开发管理端商品管理、用户管理、订单管理直接复用后台就能搞定这能帮你省下至少三分之一的开发时间。第二Django的ORM对象关系映射把数据库操作封装得很干净写模型类就能自动建表不用手写SQL这对非科班或者数据库基础薄弱的同学特别友好。第三Django自带用户认证体系登录、注册、Session管理、密码加密都是现成的你只需要扩展Profile模型来存校园相关信息。这里要澄清一个常见误区很多人觉得“基于Django的商城”就是套一个现成的电商模板把商品列表和购物车做出来就完事。实际上毕业设计的核心是“设计”两个字你的论文里要有需求分析、可行性分析、功能模块划分、数据库设计、系统测试这些环节。技术选型只是第一步更重要的是你能讲清楚每个模块为什么这么设计。比如为什么用MySQL而不是SQLite为什么商品图片要单独处理而不直接塞数据库这些才是答辩老师真正会追问的点。1.2 核心业务模块拆解按照软件工程的思路我把整个系统拆成前台和后台两大块。前台面向普通用户学生后台面向管理员。前台核心模块包括用户注册登录、商品浏览与分类筛选、商品搜索、商品详情、购物车、订单提交与支付模拟、个人中心发布商品、我卖出的、我买到的、收藏列表。后台核心模块包括商品审核因为二手物品可能存在违规信息发布后需管理员审核或自动审核、用户管理、分类管理、订单管理、系统公告。模块拆解时要特别注意“二手交易”和“普通电商”的差异点。二手平台有大量非标准商品价格可以议价、商品新旧程度需要描述、商品图片可能比较随意、卖家是个人而不是商家。这些特点直接影响设计。比如商品表中必须有一个字段记录“成色”或“使用时长”搜索筛选时要支持“价格区间”“成色筛选”而不是只有分类筛选。另外二手交易天然需要“站内信”或“留言”功能买家和卖家要沟通。很多毕设把论坛或留言板砍掉了我觉得这是个失误——它不仅是功能亮点还能让论文的功能模块图更饱满。1.3 功能优先级与边界控制毕设项目最怕的是功能铺太开最后什么都做但什么都做不深。我给这个项目定了三个优先级等级。P0是核心闭环功能缺一个整个流程就跑不通用户注册登录、商品发布、商品列表与详情、加入购物车、提交订单、订单状态流转、个人中心订单管理、Admin后台商品管理。P1是体验增强功能商品搜索与筛选、收藏功能、站内留言、图片上传优化、分页。P2是加分拓展功能模拟支付或接入支付宝沙箱、数据统计如商品浏览量、热门分类、导出订单Excel、验证码登录、第三方登录如微信登录或GitHub登录。我强烈建议你按这个优先级来安排开发节奏。先把P0完成你就有了一套完整可演示的系统哪怕后面的功能没做完答辩时也能讲出一个完整故事。很多同学卡在项目中间的常见原因就是在P2功能上花费太多时间比如折腾微信登录的AppID审核或者接入真实支付接口结果核心流程的代码质量反而不高。记住毕设拼的是体系完整性和答辩表现不是一个花哨功能。2. 数据模型设计与核心业务逻辑2.1 用户模型与扩展Django自带的User模型包含用户名、密码、邮箱、姓名等基础字段但校园二手平台还需要学号、学院、专业、联系电话、宿舍地址这些信息。正确的做法是用OneToOneField扩展一个Profile模型而不是直接改系统的User表。from django.contrib.auth.models import User class Profile(models.Model): user models.OneToOneField(User, on_deletemodels.CASCADE, related_nameprofile) student_id models.CharField(学号, max_length20, uniqueTrue) college models.CharField(学院, max_length100) major models.CharField(专业, max_length100) phone models.CharField(手机号, max_length11) campus models.CharField(校区, max_length50, blankTrue) avatar models.ImageField(头像, upload_toavatars/%Y/%m/, blankTrue, nullTrue) credits models.IntegerField(信誉分, default100) created_at models.DateTimeField(auto_now_addTrue) def __str__(self): return f{self.user.username} - {self.student_id}这里有个细节值得注意uniqueTrue加在学号上保证了数据库层面不会出现重复学号注册这个在设计文档里要当作一个“数据完整性约束”来写。还有信用分字段虽然它不参与核心交易逻辑但它是二手平台特色的体现可以在论文里作为“平台信任机制”的一部分来阐述答辩时老师会觉得你有思考。2.2 商品模型与图片处理商品模型是整个系统的核心。二手商品有几个关键属性标题、描述、价格、原价、成色、交易方式、所在校区、发布者、状态、浏览量。状态字段用整数加choices来实现是个好习惯方便后续扩展。class Goods(models.Model): STATUS_CHOICES ( (0, 待审核), (1, 在售), (2, 已下架), (3, 已售出), (4, 审核失败), ) CONDITION_CHOICES ( (全新, 全新), (几乎全新, 几乎全新), (轻微使用痕迹, 轻微使用痕迹), (明显使用痕迹, 明显使用痕迹), (有瑕疵, 有瑕疵), ) seller models.ForeignKey(User, on_deletemodels.CASCADE, related_namegoods_list, verbose_name卖家) title models.CharField(标题, max_length100) desc models.TextField(描述) price models.DecimalField(价格, max_digits8, decimal_places2) original_price models.DecimalField(原价, max_digits8, decimal_places2, blankTrue, nullTrue) condition models.CharField(成色, max_length20, choicesCONDITION_CHOICES, default几乎全新) category models.ForeignKey(Category, on_deletemodels.SET_NULL, nullTrue, verbose_name分类) campus models.CharField(校区, max_length50) trade_method models.CharField(交易方式, max_length50, default面交) status models.IntegerField(状态, choicesSTATUS_CHOICES, default0) views models.IntegerField(浏览量, default0) created_at models.DateTimeField(auto_now_addTrue) updated_at models.DateTimeField(auto_nowTrue) class Meta: ordering [-created_at]图片处理这块是容易出问题的地方。Django的ImageField需要配合Pillow库使用还需要在settings.py里配置MEDIA_URL和MEDIA_ROOT。很多同学图片上传后前端不显示基本都是静态文件服务没配好。图片建议单独建一张GoodsImage表一个商品对应多张图而不是在Goods表里放三五个图片字段。这样更灵活代码也优雅——前端可以判断图片数量决定是否显示相册的左右切换按钮。class GoodsImage(models.Model): goods models.ForeignKey(Goods, on_deletemodels.CASCADE, related_nameimages) image models.ImageField(商品图, upload_togoods/%Y/%m/) sort models.IntegerField(排序, default0)上传目录按%Y/%m/按月归档是很实用的习惯不然一年下来media目录里的文件会非常难管理。2.3 订单状态机设计订单表是另一个核心模型。商城系统的订单状态必须设计成状态机从“待付款”到“已付款待发货”到“已发货”或“已完成”再到“已取消”每个状态之间必须有明确流转规则。因为二手交易通常不涉及复杂物流我把流程简化成待付款 - 待收货卖家确认已交付 - 已完成 - 已关闭外加一个“退款/纠纷”状态作为拓展点。class Order(models.Model): STATUS_CHOICES ( (0, 待付款), (1, 待交付), (2, 已完成), (3, 已取消), (4, 退款中), ) order_no models.CharField(订单号, max_length32, uniqueTrue) buyer models.ForeignKey(User, on_deletemodels.CASCADE, related_namebuy_orders, verbose_name买家) seller models.ForeignKey(User, on_deletemodels.CASCADE, related_namesell_orders, verbose_name卖家) goods models.ForeignKey(Goods, on_deletemodels.CASCADE, verbose_name商品) price models.DecimalField(成交价, max_digits8, decimal_places2) status models.IntegerField(状态, choicesSTATUS_CHOICES, default0) remark models.CharField(备注, max_length255, blankTrue) created_at models.DateTimeField(auto_now_addTrue) pay_at models.DateTimeField(付款时间, nullTrue, blankTrue) finish_at models.DateTimeField(完成时间, nullTrue, blankTrue)订单号手动生成而不是依赖数据库自增ID原因有两个第一自增ID会暴露平台的订单量属于信息泄露第二订单号通常需要包含时间信息方便后续按时间查单。我一般用time.strftime(%Y%m%d%H%M%S)加随机数的组合方式生成订单号在views.py或者模型的save方法里完成。2.4 交易流程中的关键约束二手交易有个特殊情况一个商品被下单时必须防止其他人同时下单。这一功能在并发量不高的毕设里可以用一个笨办法实现——在创建订单时先查询商品状态如果是在售那么将商品状态改成已下架然后再创建订单。这个操作的完整代码逻辑如下from django.db import transaction transaction.atomic def create_order(request, goods_id): goods Goods.objects.select_for_update().get(pkgoods_id) if goods.status ! 1: return JsonResponse({code: 1, msg: 商品已不能购买}) # 生成订单 order_no generate_order_no() order Order.objects.create( order_noorder_no, buyerrequest.user, sellergoods.seller, goodsgoods, pricegoods.price, status0 ) # 商品改为已下架防止二次下单 goods.status 2 goods.save() return JsonResponse({code: 0, msg: 下单成功, order_no: order_no})这里用了select_for_update()对商品行加锁通过事务保证在并发场景下只有一个请求能成功创建订单。这段代码是答辩时的高质量素材你要能讲清楚“悲观锁”和“事务”这两个词说明你考虑过数据一致性问题——这比“把购物车删除功能做得很炫”更让老师认可。3. 关键功能实操详解3.1 注册登录流程与验证码方案Django自带的认证视图能快速实现登录登出但毕业设计如果想玩出花样可以自己重写用户注册和登录接口。注册时做三件事用户名唯一性校验、手机号格式校验、密码二次确认校验。这里提一个增强方案手机号验证码登录——发送短信到学生手机输入验证码即可登录或注册。虽然自己在本地无法真的发短信但可以用django-aliyun-sms配合阿里云短信服务来搞或者更取巧地用阿里云短信的测试签名。如果不想折腾短信服务可以让管理员在后台手动给用户重置密码但这样演示体验会比较弱。登录验证码图形验证码建议加上毕设答辩现场经常有老师会看登录页面。使用captcha库可以快速集成两行代码就能在页面里显示验证码INSTALLED_APPS [ # ... captcha, ] # urls.py path(captcha/, include(captcha.urls)),模板里加一行索引验证码img src{% url captcha-image %} altcaptcha /。配合Django的验证码Session机制表单提交时检查captcha字段是否匹配即可。这个功能看似小但能体现“防止恶意刷接口”的安全意识属于低投入高回报的功能点。3.2 商品检索与筛选的QuerySet写法商品列表页看起来简单但深挖下去有很多细节。基础的搜索用icontains做模糊查询即可但一个完整的筛选逻辑往往包含关键词搜索、分类筛选、价格区间、成色筛选、校区筛选还要支持排序最新发布、价格升序、价格降序、浏览量最高。def goods_list(request): goods_list Goods.objects.filter(status1) keyword request.GET.get(keyword, ).strip() if keyword: goods_list goods_list.filter( Q(title__icontainskeyword) | Q(desc__icontainskeyword) ) category_id request.GET.get(category, ) if category_id.isdigit(): goods_list goods_list.filter(category_idcategory_id) min_price request.GET.get(min_price, ) max_price request.GET.get(max_price, ) if min_price.isdigit(): goods_list goods_list.filter(price__gtemin_price) if max_price.isdigit(): goods_list goods_list.filter(price__ltemax_price) condition request.GET.get(condition, ) if condition: goods_list goods_list.filter(conditioncondition) sort_by request.GET.get(sort, -created_at) sort_map { latest: -created_at, price_asc: price, price_desc: -price, hot: -views, } goods_list goods_list.order_by(sort_map.get(sort_by, -created_at)) paginator Paginator(goods_list, 12) page_number request.GET.get(page) page_obj paginator.get_page(page_number) # ...注意这里Q对象的用法它用来组合OR条件比写两个filter再合并结果要优雅得多。这里有个容易踩的坑filter(status1)如果放在所有条件之前后续的.filter都是在它基础上叠加AND条件这个不会出问题但如果你用链式多个.filter()传参的方式要小心参数为空字符串时可能把所有记录都过滤掉。明白这一点的办法是先在Python shell里跑一遍QuerySet观察生成的SQL语句。分页用的是Django内置的Paginator模板里渲染页面导航时要注意参数拼接问题——分页链接要保留当前已有的查询参数。正确做法是在模板里循环所有GET参数再追加page{% for key, value in request.GET.items %} {% if key ! page %} input typehidden name{{ key }} value{{ value }} {% endif %} {% endfor %}这个细节很容易被忽视但实际影响使用体验。我见过很多毕设的分页一点第二页就丢掉了搜索关键词这个体验问题在演示时很减分。3.3 购物车与订单结算的会话处理购物车有两种实现方案基于Session和基于数据库。数据库购物车的优势是可以跨设备同步但需要额外的Cart表和CartItem表基于Session的购物车简单易实现适合毕设。我的建议是做数据库版因为代码量差别其实不大而且答辩时能多讲一个实体和一张数据表。核心模型class Cart(models.Model): user models.OneToOneField(User, on_deletemodels.CASCADE, related_namecart) created_at models.DateTimeField(auto_now_addTrue) class CartItem(models.Model): cart models.ForeignKey(Cart, on_deletemodels.CASCADE, related_nameitems) goods models.ForeignKey(Goods, on_deletemodels.CASCADE) added_at models.DateTimeField(auto_now_addTrue)注意购物车条目里的商品应该是“引用”而不是“快照”。这与订单里的商品不同——订单提交后商品的价格、标题、图片应该“冻结”下来以快照形式存储或至少订单明细表冗余一份商品标题和价格因为卖家可能修改商品信息。这个设计点如果你能在论文里写出来代表你真懂电商系统的核心逻辑。下单的时候从购物车读取商品创建订单明细然后清空购物车。这条链路看起来简单实际操作时要注意事务处理避免用户购物车有商品下单失败了购物车还被清空。把清空购物车的操作放在事务提交之后执行这算是一条重要的实操经验。3.4 模拟支付与订单超时关闭毕设项目接真实支付接口大概率会碰壁——个人开发者难以申请到支付商户号而且涉及资金安全问题也复杂。推荐方案是用“模拟支付”加“支付宝沙箱”两种思路。模拟支付就是在提交订单后生成一个虚拟支付页面用户点击“确认支付”后直接改变订单状态为待交付页面显示“已支付”流程简短且效果直观。如果想要“接入支付宝”这样的亮点可以用支付宝开放平台的沙箱环境把APPID、密钥配置好用python-alipay-sdk来完成接口调用。沙箱环境不需要真实企业资质流程和真实支付完全一致。这个功能如果你做好了完全可以作为论文里的一个重点特色功能来写。支付回调页的验证签名逻辑讲起来老师也会很感兴趣。不过说实话考虑到时间成本我建议大多数同学用模拟支付就够了——把时间花在把系统整体打磨得更完整上性价比更高。订单超时关闭是一个很典型的业务规则。写到RedisCelery是加分项但本地跑Celery又麻烦又容易出错我自己实践下来最快的办法是用Django的manage.py shell配合定时脚本或者安装APScheduler在AppConfig.ready()里启动一个后台调度器# utils/scheduler.py from apscheduler.schedulers.background import BackgroundScheduler from django_apscheduler.jobstores import DjangoJobStore def start_job(): scheduler BackgroundScheduler(timezoneAsia/Shanghai) scheduler.add_jobstore(DjangoJobStore(), default) scheduler.add_job(close_expired_orders, interval, minutes5, idclose_expired_orders, replace_existingTrue) scheduler.start()在apps.py里调用start_job()。这个方案不会像Celery那样需要额外开worker进程部署也简单对于毕设完全够用。这个逻辑要对所有状态为“待付款”且创建时间超过30分钟的订单改状态为“已取消”并把商品还原为“在售”。商品还原的逻辑很容易漏你可以想想原因——如果订单超时了但商品依然是已下架状态那其他用户就永远买不到了。写完代码后自测时一定要验这条链路下单不付款等超时任务跑完再查商品状态。3.5 模板与前端交互的东西取舍Django里有两种渲染方式传统服务端渲染模板Django Template Language和前后端分离Django REST framework Vue/小程序。我先给个明确的测算结论不做小程序、不做App的前提下传统服务端渲染是最适合毕设的。原因有三一是代码量少不用处理跨域问题二是可以直接复制BootCDN上的Bootstrap模板快速做出一个美观的后台三是论文里写“基于Django模板的MVC架构”这种表述更顺理成章。如果你非要做前后端分离建议用Django REST Framework配Vue或UniApp。这个方案漂亮是漂亮但你要付出额外代价用户认证要切换成JWT或者Token认证、异步数据要自己处理Loading状态、跨域要配置CORS、部署时要操心两个服务API和前端打包静态文件。对于毕业设计来说这些都增加了不可控的变量。之前辅导过一个同学做小程序版商城光微信登录授权就调了两天。选择服务端渲染不等于不注意交互优化。商品列表页使用卡片式布局图片懒加载用lazyload库商品详情页用lightbox插件做图片放大预览Toast反馈用bootstrap-toast组件发布商品时用Select2做分类下拉框的搜索增强。这些都是开箱即用的东西能显著提升演示时的观感。4. 常见问题与排查技巧实录4.1 静态文件和媒体文件404这是Django入门最经典的坑。开发环境里模板能渲染但图片和CSS全是404十有八九是没配置静态文件服务。Debug模式下Django的静态文件由django.contrib.staticfiles自动处理你只需要在settings.py里确认三项STATIC_URL /static/ STATICFILES_DIRS [BASE_DIR / static] # 开发时的静态文件目录 # 媒体文件 MEDIA_URL /media/ MEDIA_ROOT BASE_DIR / media然后项目根目录的urls.py添加媒体文件路由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)常见的错误做法是把STATICFILES_DIRS配成指向/static的绝对路径或者忘记BASE_DIR拼接导致路径不对。建议在开发初期就在首页放一张图片测试静态服务是否正常而不是到最后一晚部署时才面对一堆404的绝望。另外还有一个隐蔽的坑模板里引用图片有人习惯写死/media/goods/xxx.jpg而正确写法是{{ goods.images.first.image.url }}ImageField的.url属性会自动拼上MEDIA_URL。4.2 数据库迁移冲突与重置makemigrations和migrate是高频操作但很多同学模型改了又改最后迁移文件堆积如山一旦删除某个字段就会出现“table already exists”或者“column does not exist”的诡异报错。遇到这种问题我的建议是果断重置迁移历史——毕设项目没有上线数据重置代价为零。操作步骤先备份db.sqlite3如果是SQLite的话然后删除migrations目录下除__init__.py外的所有文件删除数据库文件重新migrate。这一步做完再跑makemigrations生成一份干净的初始迁移文件。如果你用MySQL要先把django_migrations表里的记录清掉再重新迁移。需要注意的是如果模型里有外键和ManyToManyField重置后重新生成迁移不会丢字段但你的Admin后台可能仍然显示旧的列表页缓存——刷新浏览器缓存一般能解决。另外命令行执行python manage.py migrate --run-syncdb在某些情况下可以跳过迁移直接建表但这是危险操作不建议乱用。4.3 用户上传图片不显示很多人把图片上传后的文件路径存在数据库里但实际文件压根没有保存成功。排查步骤从简到难检查MEDIA_ROOT目录是否有生成以日期命名的子目录目录内是否有文件检查数据库里图片字段的值是文件名还是完整URL路径检查前端模板渲染时是否用了.url属性。如果都不行刷一遍Django日志看有没有MultiValueDictKeyError或者PIL.UnidentifiedImageError。后者表示上传的是假图片——把不是图的后缀改成.jpg骗过了浏览器但Pillow库在读取时炸了。解决方法是给ImageField增加上传校验from django.core.validators import FileExtensionValidator avatar models.ImageField( upload_toavatars/%Y/%m/, validators[FileExtensionValidator([jpg, jpeg, png, gif, webp])] )不过扩展名校验只能防君子真正稳妥的是在form或serializer里用Pillow打开文件并检查格式。4.4 部署到服务器的关键坑毕设答辩前通常要部署到服务器上演示我整理一张问题速查表给你这些都是真实踩过坑的同学反馈回来的。症状原因解决方案Admin后台样式丢失STATIC_ROOT未配置collectstatic未执行python manage.py collectstatic并且检查Nginx静态文件路径上传的图片在刷新后消失文件写入了临时存储或路径不对检查MEDIA_ROOT对应Nginx的location /media/配置500错误但本地正常ALLOWED_HOSTS没配置服务器IP在settings.py中加入域名或IP或用*临时通配数据库连接失败用了MySQL但没装客户端库pip install pymysql并在__init__.py中添加pymysql.install_as_MySQLdb()访问速度极慢DebugTrue关闭DEBUG False并配置好静态文件的Nginx托管部署本身不是毕设论文的重点但演示环境直接决定答辩效果。我见过有同学现场打开网页结果是浏览器缓存里的旧页面这让老师非常怀疑项目真实性。建议答辩前三天在干净浏览器或隐身模式下完整走一遍流程注册新用户、发布商品、浏览、下单、支付、卖家发货、买家确认、评价。把这段流程录个屏即使现场网络崩了也能放视频兜底。4.5 核心功能的自测清单写代码很容易但“跑通”和“能答辩”之间还差一层系统测试。这里给出一个自测清单每条都对应论文的测试章节素材。功能测试要覆盖用户注册的三种异常情况用户名重复、手机号格式错、密码太短商品发布的权限控制未登录用户不能发布商品购买流程的权限控制不能购买自己的商品订单状态的每一步流转是否符合预期搜索乱码或特殊字符百分号、引号是否会报错图片上传超大文件是否会崩溃。安全测试覆盖未登录直接访问后台URL是否被拦截修改URL中的订单ID能否查询到别人的订单通过POST工具伪造支付成功请求能否改变订单状态。这些测试做一遍你能发现自己代码里原来有这么多漏洞。把测试过程和截图整理到论文的大章节中比泛泛写“本系统通过了系统测试”要真实得多老师一眼就能看出你是不是真做了。5. 论文结构设计与答辩准备5.1 论文怎么写才能看起来有水平论文的结构遵循软件工程标准格式绪论研究背景、意义、国内外现状、相关技术介绍、系统需求分析、系统设计架构设计、功能设计、数据库设计、系统实现各模块代码讲解和截图、系统测试、总结展望。这套框架是最标准的照这个写不会出大错。但要让论文看起来有深度有三个加分技巧。第一可行性分析要结合项目实际不要泛泛抄模板。技术可行性要写清楚为什么用Django开发效率高、自带Admin、生态成熟经济可行性写所用技术全免费、服务器可以用校园网或本地部署操作可行性写界面友好、学生容易上手。第二数据库设计这一章不能只贴表结构要画E-R图实体关系图讲述从需求到实体的映射过程。手画或用数据库设计工具都行但别在网上找别人的图硬塞——老师一眼能看出风格不一致。第三系统实现章节要有“核心代码文字说明运行截图”三段式代码要有注释不是复制大段代码上去了事而是要挑3-4段真正核心的代码讲清楚比如订单状态机、商品锁定逻辑。5.2 答辩高频问题整理答辩老师不会问你“这个系统用了什么技术”他们会从项目核心逻辑和你的描述里挑破绽。我归纳了几个高频问题系统有什么创新点相比普通商城系统二手交易平台的特殊处理是什么数据库中有哪些表它们之间的关系分页是怎么实现的为什么用MySQL而不是SQLite搜索功能是怎么实现的如何防止一个商品被重复购买订单状态是怎么流转的支付接口是真实的吗测试用例覆盖了哪些场景这些都是系统实体问题每个都对应你代码里的一个模块。你必须做到对任意一个细节追问都能流畅回答建议答辩前把这些问题和自己写的代码逐一对照练习。有一个高概率问题“如果你部署到公网需要考虑哪些安全问题”老师并不期望你给出完美答案而是想看你有没有安全思维。能说出CSRF防护Django默认开启、XSS过滤模板自动转义、SQL注入防护ORM参数化查询、权限控制装饰器限制访问、敏感信息加密密码哈希存储这几点就已经超过大多数毕设水平了。5.3 演示环境和话术设计演示环节设计非常重要。开场白不要从功能列表开始而要讲一个场景“假设我是大四学生毕业前有一台只用了一年的台灯想卖掉”——然后顺着这个场景走完发布、浏览、购买、订单处理整个流程。这样讲比“这是登录页面这是注册页面”要生动得多。演示前先把环境起好浏览器打开到登录页数据库里有3-5条有真实感的数据比如“高等数学教材 8成新 15元”“九成新山地自行车 校园骑行 200元”。商品图片也要真实不要用明显的网络示例图哪怕是手机拍的书桌一角也比官方图库有说服力。如果系统里加了留言功能提前在商品下留一条模拟对话“同学这书还有笔记吗”“有的字迹清晰不影响阅读”这个细节能让老师感受到你真的考虑了二手交易的真实使用场景。另外准备一份“手动异常演示”也会加分——让用户输入错误密码、重复提交订单展示系统有处理异常的逻辑——这很体现工程素养。最后分享一点个人经验做毕业设计这一年不少同学干到后面就变成“代码搬运工”了。我要提醒的是不要光盯着“实现”更要关注“设计”——你在论文里讲清楚每一个为什么比main代码炫技重要得多。Django这个框架能让你快速搭出项目骨架但真正拉开差距的是订单状态机有没有设计清楚、并发购买有没有考虑锁、测试用有没有覆盖核心流程。这些地方花心思你的答辩状态是完全不一样的。再有就是代码写完后哪怕不部署也一定要把环境打包好写一份清晰的README——你永远不会知道毕业设计验收那天会不会从你的电脑切换到一台不知名服务器上演示。 基于Django的校园二手商城毕设实战指南
毕业设计季又是各种“基于XX系统”扎堆的时候。如果你正在纠结“基于Django校园二手闲置物品买卖网上商城”这个题目那这篇文章你应该早点看到。前后帮人改过不少这类项目从数据表设计到论文排版从答辩PPT到现场演示踩过的坑和捷径都在这。这篇内容主要面向准备做商城类Django项目的同学也适合想系统梳理Django开发流程的初学者目标是让你从“只会跑通代码”变成“能讲清楚设计思路、扛得住答辩追问”。1. 项目定位与整体设计思路1.1 为什么选择Django做二手交易商城选Django来做校园二手交易平台不是因为它最潮而是它最适合毕业设计这个场景。第一Django自带Admin后台你不需要额外开发管理端商品管理、用户管理、订单管理直接复用后台就能搞定这能帮你省下至少三分之一的开发时间。第二Django的ORM对象关系映射把数据库操作封装得很干净写模型类就能自动建表不用手写SQL这对非科班或者数据库基础薄弱的同学特别友好。第三Django自带用户认证体系登录、注册、Session管理、密码加密都是现成的你只需要扩展Profile模型来存校园相关信息。这里要澄清一个常见误区很多人觉得“基于Django的商城”就是套一个现成的电商模板把商品列表和购物车做出来就完事。实际上毕业设计的核心是“设计”两个字你的论文里要有需求分析、可行性分析、功能模块划分、数据库设计、系统测试这些环节。技术选型只是第一步更重要的是你能讲清楚每个模块为什么这么设计。比如为什么用MySQL而不是SQLite为什么商品图片要单独处理而不直接塞数据库这些才是答辩老师真正会追问的点。1.2 核心业务模块拆解按照软件工程的思路我把整个系统拆成前台和后台两大块。前台面向普通用户学生后台面向管理员。前台核心模块包括用户注册登录、商品浏览与分类筛选、商品搜索、商品详情、购物车、订单提交与支付模拟、个人中心发布商品、我卖出的、我买到的、收藏列表。后台核心模块包括商品审核因为二手物品可能存在违规信息发布后需管理员审核或自动审核、用户管理、分类管理、订单管理、系统公告。模块拆解时要特别注意“二手交易”和“普通电商”的差异点。二手平台有大量非标准商品价格可以议价、商品新旧程度需要描述、商品图片可能比较随意、卖家是个人而不是商家。这些特点直接影响设计。比如商品表中必须有一个字段记录“成色”或“使用时长”搜索筛选时要支持“价格区间”“成色筛选”而不是只有分类筛选。另外二手交易天然需要“站内信”或“留言”功能买家和卖家要沟通。很多毕设把论坛或留言板砍掉了我觉得这是个失误——它不仅是功能亮点还能让论文的功能模块图更饱满。1.3 功能优先级与边界控制毕设项目最怕的是功能铺太开最后什么都做但什么都做不深。我给这个项目定了三个优先级等级。P0是核心闭环功能缺一个整个流程就跑不通用户注册登录、商品发布、商品列表与详情、加入购物车、提交订单、订单状态流转、个人中心订单管理、Admin后台商品管理。P1是体验增强功能商品搜索与筛选、收藏功能、站内留言、图片上传优化、分页。P2是加分拓展功能模拟支付或接入支付宝沙箱、数据统计如商品浏览量、热门分类、导出订单Excel、验证码登录、第三方登录如微信登录或GitHub登录。我强烈建议你按这个优先级来安排开发节奏。先把P0完成你就有了一套完整可演示的系统哪怕后面的功能没做完答辩时也能讲出一个完整故事。很多同学卡在项目中间的常见原因就是在P2功能上花费太多时间比如折腾微信登录的AppID审核或者接入真实支付接口结果核心流程的代码质量反而不高。记住毕设拼的是体系完整性和答辩表现不是一个花哨功能。2. 数据模型设计与核心业务逻辑2.1 用户模型与扩展Django自带的User模型包含用户名、密码、邮箱、姓名等基础字段但校园二手平台还需要学号、学院、专业、联系电话、宿舍地址这些信息。正确的做法是用OneToOneField扩展一个Profile模型而不是直接改系统的User表。from django.contrib.auth.models import User class Profile(models.Model): user models.OneToOneField(User, on_deletemodels.CASCADE, related_nameprofile) student_id models.CharField(学号, max_length20, uniqueTrue) college models.CharField(学院, max_length100) major models.CharField(专业, max_length100) phone models.CharField(手机号, max_length11) campus models.CharField(校区, max_length50, blankTrue) avatar models.ImageField(头像, upload_toavatars/%Y/%m/, blankTrue, nullTrue) credits models.IntegerField(信誉分, default100) created_at models.DateTimeField(auto_now_addTrue) def __str__(self): return f{self.user.username} - {self.student_id}这里有个细节值得注意uniqueTrue加在学号上保证了数据库层面不会出现重复学号注册这个在设计文档里要当作一个“数据完整性约束”来写。还有信用分字段虽然它不参与核心交易逻辑但它是二手平台特色的体现可以在论文里作为“平台信任机制”的一部分来阐述答辩时老师会觉得你有思考。2.2 商品模型与图片处理商品模型是整个系统的核心。二手商品有几个关键属性标题、描述、价格、原价、成色、交易方式、所在校区、发布者、状态、浏览量。状态字段用整数加choices来实现是个好习惯方便后续扩展。class Goods(models.Model): STATUS_CHOICES ( (0, 待审核), (1, 在售), (2, 已下架), (3, 已售出), (4, 审核失败), ) CONDITION_CHOICES ( (全新, 全新), (几乎全新, 几乎全新), (轻微使用痕迹, 轻微使用痕迹), (明显使用痕迹, 明显使用痕迹), (有瑕疵, 有瑕疵), ) seller models.ForeignKey(User, on_deletemodels.CASCADE, related_namegoods_list, verbose_name卖家) title models.CharField(标题, max_length100) desc models.TextField(描述) price models.DecimalField(价格, max_digits8, decimal_places2) original_price models.DecimalField(原价, max_digits8, decimal_places2, blankTrue, nullTrue) condition models.CharField(成色, max_length20, choicesCONDITION_CHOICES, default几乎全新) category models.ForeignKey(Category, on_deletemodels.SET_NULL, nullTrue, verbose_name分类) campus models.CharField(校区, max_length50) trade_method models.CharField(交易方式, max_length50, default面交) status models.IntegerField(状态, choicesSTATUS_CHOICES, default0) views models.IntegerField(浏览量, default0) created_at models.DateTimeField(auto_now_addTrue) updated_at models.DateTimeField(auto_nowTrue) class Meta: ordering [-created_at]图片处理这块是容易出问题的地方。Django的ImageField需要配合Pillow库使用还需要在settings.py里配置MEDIA_URL和MEDIA_ROOT。很多同学图片上传后前端不显示基本都是静态文件服务没配好。图片建议单独建一张GoodsImage表一个商品对应多张图而不是在Goods表里放三五个图片字段。这样更灵活代码也优雅——前端可以判断图片数量决定是否显示相册的左右切换按钮。class GoodsImage(models.Model): goods models.ForeignKey(Goods, on_deletemodels.CASCADE, related_nameimages) image models.ImageField(商品图, upload_togoods/%Y/%m/) sort models.IntegerField(排序, default0)上传目录按%Y/%m/按月归档是很实用的习惯不然一年下来media目录里的文件会非常难管理。2.3 订单状态机设计订单表是另一个核心模型。商城系统的订单状态必须设计成状态机从“待付款”到“已付款待发货”到“已发货”或“已完成”再到“已取消”每个状态之间必须有明确流转规则。因为二手交易通常不涉及复杂物流我把流程简化成待付款 - 待收货卖家确认已交付 - 已完成 - 已关闭外加一个“退款/纠纷”状态作为拓展点。class Order(models.Model): STATUS_CHOICES ( (0, 待付款), (1, 待交付), (2, 已完成), (3, 已取消), (4, 退款中), ) order_no models.CharField(订单号, max_length32, uniqueTrue) buyer models.ForeignKey(User, on_deletemodels.CASCADE, related_namebuy_orders, verbose_name买家) seller models.ForeignKey(User, on_deletemodels.CASCADE, related_namesell_orders, verbose_name卖家) goods models.ForeignKey(Goods, on_deletemodels.CASCADE, verbose_name商品) price models.DecimalField(成交价, max_digits8, decimal_places2) status models.IntegerField(状态, choicesSTATUS_CHOICES, default0) remark models.CharField(备注, max_length255, blankTrue) created_at models.DateTimeField(auto_now_addTrue) pay_at models.DateTimeField(付款时间, nullTrue, blankTrue) finish_at models.DateTimeField(完成时间, nullTrue, blankTrue)订单号手动生成而不是依赖数据库自增ID原因有两个第一自增ID会暴露平台的订单量属于信息泄露第二订单号通常需要包含时间信息方便后续按时间查单。我一般用time.strftime(%Y%m%d%H%M%S)加随机数的组合方式生成订单号在views.py或者模型的save方法里完成。2.4 交易流程中的关键约束二手交易有个特殊情况一个商品被下单时必须防止其他人同时下单。这一功能在并发量不高的毕设里可以用一个笨办法实现——在创建订单时先查询商品状态如果是在售那么将商品状态改成已下架然后再创建订单。这个操作的完整代码逻辑如下from django.db import transaction transaction.atomic def create_order(request, goods_id): goods Goods.objects.select_for_update().get(pkgoods_id) if goods.status ! 1: return JsonResponse({code: 1, msg: 商品已不能购买}) # 生成订单 order_no generate_order_no() order Order.objects.create( order_noorder_no, buyerrequest.user, sellergoods.seller, goodsgoods, pricegoods.price, status0 ) # 商品改为已下架防止二次下单 goods.status 2 goods.save() return JsonResponse({code: 0, msg: 下单成功, order_no: order_no})这里用了select_for_update()对商品行加锁通过事务保证在并发场景下只有一个请求能成功创建订单。这段代码是答辩时的高质量素材你要能讲清楚“悲观锁”和“事务”这两个词说明你考虑过数据一致性问题——这比“把购物车删除功能做得很炫”更让老师认可。3. 关键功能实操详解3.1 注册登录流程与验证码方案Django自带的认证视图能快速实现登录登出但毕业设计如果想玩出花样可以自己重写用户注册和登录接口。注册时做三件事用户名唯一性校验、手机号格式校验、密码二次确认校验。这里提一个增强方案手机号验证码登录——发送短信到学生手机输入验证码即可登录或注册。虽然自己在本地无法真的发短信但可以用django-aliyun-sms配合阿里云短信服务来搞或者更取巧地用阿里云短信的测试签名。如果不想折腾短信服务可以让管理员在后台手动给用户重置密码但这样演示体验会比较弱。登录验证码图形验证码建议加上毕设答辩现场经常有老师会看登录页面。使用captcha库可以快速集成两行代码就能在页面里显示验证码INSTALLED_APPS [ # ... captcha, ] # urls.py path(captcha/, include(captcha.urls)),模板里加一行索引验证码img src{% url captcha-image %} altcaptcha /。配合Django的验证码Session机制表单提交时检查captcha字段是否匹配即可。这个功能看似小但能体现“防止恶意刷接口”的安全意识属于低投入高回报的功能点。3.2 商品检索与筛选的QuerySet写法商品列表页看起来简单但深挖下去有很多细节。基础的搜索用icontains做模糊查询即可但一个完整的筛选逻辑往往包含关键词搜索、分类筛选、价格区间、成色筛选、校区筛选还要支持排序最新发布、价格升序、价格降序、浏览量最高。def goods_list(request): goods_list Goods.objects.filter(status1) keyword request.GET.get(keyword, ).strip() if keyword: goods_list goods_list.filter( Q(title__icontainskeyword) | Q(desc__icontainskeyword) ) category_id request.GET.get(category, ) if category_id.isdigit(): goods_list goods_list.filter(category_idcategory_id) min_price request.GET.get(min_price, ) max_price request.GET.get(max_price, ) if min_price.isdigit(): goods_list goods_list.filter(price__gtemin_price) if max_price.isdigit(): goods_list goods_list.filter(price__ltemax_price) condition request.GET.get(condition, ) if condition: goods_list goods_list.filter(conditioncondition) sort_by request.GET.get(sort, -created_at) sort_map { latest: -created_at, price_asc: price, price_desc: -price, hot: -views, } goods_list goods_list.order_by(sort_map.get(sort_by, -created_at)) paginator Paginator(goods_list, 12) page_number request.GET.get(page) page_obj paginator.get_page(page_number) # ...注意这里Q对象的用法它用来组合OR条件比写两个filter再合并结果要优雅得多。这里有个容易踩的坑filter(status1)如果放在所有条件之前后续的.filter都是在它基础上叠加AND条件这个不会出问题但如果你用链式多个.filter()传参的方式要小心参数为空字符串时可能把所有记录都过滤掉。明白这一点的办法是先在Python shell里跑一遍QuerySet观察生成的SQL语句。分页用的是Django内置的Paginator模板里渲染页面导航时要注意参数拼接问题——分页链接要保留当前已有的查询参数。正确做法是在模板里循环所有GET参数再追加page{% for key, value in request.GET.items %} {% if key ! page %} input typehidden name{{ key }} value{{ value }} {% endif %} {% endfor %}这个细节很容易被忽视但实际影响使用体验。我见过很多毕设的分页一点第二页就丢掉了搜索关键词这个体验问题在演示时很减分。3.3 购物车与订单结算的会话处理购物车有两种实现方案基于Session和基于数据库。数据库购物车的优势是可以跨设备同步但需要额外的Cart表和CartItem表基于Session的购物车简单易实现适合毕设。我的建议是做数据库版因为代码量差别其实不大而且答辩时能多讲一个实体和一张数据表。核心模型class Cart(models.Model): user models.OneToOneField(User, on_deletemodels.CASCADE, related_namecart) created_at models.DateTimeField(auto_now_addTrue) class CartItem(models.Model): cart models.ForeignKey(Cart, on_deletemodels.CASCADE, related_nameitems) goods models.ForeignKey(Goods, on_deletemodels.CASCADE) added_at models.DateTimeField(auto_now_addTrue)注意购物车条目里的商品应该是“引用”而不是“快照”。这与订单里的商品不同——订单提交后商品的价格、标题、图片应该“冻结”下来以快照形式存储或至少订单明细表冗余一份商品标题和价格因为卖家可能修改商品信息。这个设计点如果你能在论文里写出来代表你真懂电商系统的核心逻辑。下单的时候从购物车读取商品创建订单明细然后清空购物车。这条链路看起来简单实际操作时要注意事务处理避免用户购物车有商品下单失败了购物车还被清空。把清空购物车的操作放在事务提交之后执行这算是一条重要的实操经验。3.4 模拟支付与订单超时关闭毕设项目接真实支付接口大概率会碰壁——个人开发者难以申请到支付商户号而且涉及资金安全问题也复杂。推荐方案是用“模拟支付”加“支付宝沙箱”两种思路。模拟支付就是在提交订单后生成一个虚拟支付页面用户点击“确认支付”后直接改变订单状态为待交付页面显示“已支付”流程简短且效果直观。如果想要“接入支付宝”这样的亮点可以用支付宝开放平台的沙箱环境把APPID、密钥配置好用python-alipay-sdk来完成接口调用。沙箱环境不需要真实企业资质流程和真实支付完全一致。这个功能如果你做好了完全可以作为论文里的一个重点特色功能来写。支付回调页的验证签名逻辑讲起来老师也会很感兴趣。不过说实话考虑到时间成本我建议大多数同学用模拟支付就够了——把时间花在把系统整体打磨得更完整上性价比更高。订单超时关闭是一个很典型的业务规则。写到RedisCelery是加分项但本地跑Celery又麻烦又容易出错我自己实践下来最快的办法是用Django的manage.py shell配合定时脚本或者安装APScheduler在AppConfig.ready()里启动一个后台调度器# utils/scheduler.py from apscheduler.schedulers.background import BackgroundScheduler from django_apscheduler.jobstores import DjangoJobStore def start_job(): scheduler BackgroundScheduler(timezoneAsia/Shanghai) scheduler.add_jobstore(DjangoJobStore(), default) scheduler.add_job(close_expired_orders, interval, minutes5, idclose_expired_orders, replace_existingTrue) scheduler.start()在apps.py里调用start_job()。这个方案不会像Celery那样需要额外开worker进程部署也简单对于毕设完全够用。这个逻辑要对所有状态为“待付款”且创建时间超过30分钟的订单改状态为“已取消”并把商品还原为“在售”。商品还原的逻辑很容易漏你可以想想原因——如果订单超时了但商品依然是已下架状态那其他用户就永远买不到了。写完代码后自测时一定要验这条链路下单不付款等超时任务跑完再查商品状态。3.5 模板与前端交互的东西取舍Django里有两种渲染方式传统服务端渲染模板Django Template Language和前后端分离Django REST framework Vue/小程序。我先给个明确的测算结论不做小程序、不做App的前提下传统服务端渲染是最适合毕设的。原因有三一是代码量少不用处理跨域问题二是可以直接复制BootCDN上的Bootstrap模板快速做出一个美观的后台三是论文里写“基于Django模板的MVC架构”这种表述更顺理成章。如果你非要做前后端分离建议用Django REST Framework配Vue或UniApp。这个方案漂亮是漂亮但你要付出额外代价用户认证要切换成JWT或者Token认证、异步数据要自己处理Loading状态、跨域要配置CORS、部署时要操心两个服务API和前端打包静态文件。对于毕业设计来说这些都增加了不可控的变量。之前辅导过一个同学做小程序版商城光微信登录授权就调了两天。选择服务端渲染不等于不注意交互优化。商品列表页使用卡片式布局图片懒加载用lazyload库商品详情页用lightbox插件做图片放大预览Toast反馈用bootstrap-toast组件发布商品时用Select2做分类下拉框的搜索增强。这些都是开箱即用的东西能显著提升演示时的观感。4. 常见问题与排查技巧实录4.1 静态文件和媒体文件404这是Django入门最经典的坑。开发环境里模板能渲染但图片和CSS全是404十有八九是没配置静态文件服务。Debug模式下Django的静态文件由django.contrib.staticfiles自动处理你只需要在settings.py里确认三项STATIC_URL /static/ STATICFILES_DIRS [BASE_DIR / static] # 开发时的静态文件目录 # 媒体文件 MEDIA_URL /media/ MEDIA_ROOT BASE_DIR / media然后项目根目录的urls.py添加媒体文件路由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)常见的错误做法是把STATICFILES_DIRS配成指向/static的绝对路径或者忘记BASE_DIR拼接导致路径不对。建议在开发初期就在首页放一张图片测试静态服务是否正常而不是到最后一晚部署时才面对一堆404的绝望。另外还有一个隐蔽的坑模板里引用图片有人习惯写死/media/goods/xxx.jpg而正确写法是{{ goods.images.first.image.url }}ImageField的.url属性会自动拼上MEDIA_URL。4.2 数据库迁移冲突与重置makemigrations和migrate是高频操作但很多同学模型改了又改最后迁移文件堆积如山一旦删除某个字段就会出现“table already exists”或者“column does not exist”的诡异报错。遇到这种问题我的建议是果断重置迁移历史——毕设项目没有上线数据重置代价为零。操作步骤先备份db.sqlite3如果是SQLite的话然后删除migrations目录下除__init__.py外的所有文件删除数据库文件重新migrate。这一步做完再跑makemigrations生成一份干净的初始迁移文件。如果你用MySQL要先把django_migrations表里的记录清掉再重新迁移。需要注意的是如果模型里有外键和ManyToManyField重置后重新生成迁移不会丢字段但你的Admin后台可能仍然显示旧的列表页缓存——刷新浏览器缓存一般能解决。另外命令行执行python manage.py migrate --run-syncdb在某些情况下可以跳过迁移直接建表但这是危险操作不建议乱用。4.3 用户上传图片不显示很多人把图片上传后的文件路径存在数据库里但实际文件压根没有保存成功。排查步骤从简到难检查MEDIA_ROOT目录是否有生成以日期命名的子目录目录内是否有文件检查数据库里图片字段的值是文件名还是完整URL路径检查前端模板渲染时是否用了.url属性。如果都不行刷一遍Django日志看有没有MultiValueDictKeyError或者PIL.UnidentifiedImageError。后者表示上传的是假图片——把不是图的后缀改成.jpg骗过了浏览器但Pillow库在读取时炸了。解决方法是给ImageField增加上传校验from django.core.validators import FileExtensionValidator avatar models.ImageField( upload_toavatars/%Y/%m/, validators[FileExtensionValidator([jpg, jpeg, png, gif, webp])] )不过扩展名校验只能防君子真正稳妥的是在form或serializer里用Pillow打开文件并检查格式。4.4 部署到服务器的关键坑毕设答辩前通常要部署到服务器上演示我整理一张问题速查表给你这些都是真实踩过坑的同学反馈回来的。症状原因解决方案Admin后台样式丢失STATIC_ROOT未配置collectstatic未执行python manage.py collectstatic并且检查Nginx静态文件路径上传的图片在刷新后消失文件写入了临时存储或路径不对检查MEDIA_ROOT对应Nginx的location /media/配置500错误但本地正常ALLOWED_HOSTS没配置服务器IP在settings.py中加入域名或IP或用*临时通配数据库连接失败用了MySQL但没装客户端库pip install pymysql并在__init__.py中添加pymysql.install_as_MySQLdb()访问速度极慢DebugTrue关闭DEBUG False并配置好静态文件的Nginx托管部署本身不是毕设论文的重点但演示环境直接决定答辩效果。我见过有同学现场打开网页结果是浏览器缓存里的旧页面这让老师非常怀疑项目真实性。建议答辩前三天在干净浏览器或隐身模式下完整走一遍流程注册新用户、发布商品、浏览、下单、支付、卖家发货、买家确认、评价。把这段流程录个屏即使现场网络崩了也能放视频兜底。4.5 核心功能的自测清单写代码很容易但“跑通”和“能答辩”之间还差一层系统测试。这里给出一个自测清单每条都对应论文的测试章节素材。功能测试要覆盖用户注册的三种异常情况用户名重复、手机号格式错、密码太短商品发布的权限控制未登录用户不能发布商品购买流程的权限控制不能购买自己的商品订单状态的每一步流转是否符合预期搜索乱码或特殊字符百分号、引号是否会报错图片上传超大文件是否会崩溃。安全测试覆盖未登录直接访问后台URL是否被拦截修改URL中的订单ID能否查询到别人的订单通过POST工具伪造支付成功请求能否改变订单状态。这些测试做一遍你能发现自己代码里原来有这么多漏洞。把测试过程和截图整理到论文的大章节中比泛泛写“本系统通过了系统测试”要真实得多老师一眼就能看出你是不是真做了。5. 论文结构设计与答辩准备5.1 论文怎么写才能看起来有水平论文的结构遵循软件工程标准格式绪论研究背景、意义、国内外现状、相关技术介绍、系统需求分析、系统设计架构设计、功能设计、数据库设计、系统实现各模块代码讲解和截图、系统测试、总结展望。这套框架是最标准的照这个写不会出大错。但要让论文看起来有深度有三个加分技巧。第一可行性分析要结合项目实际不要泛泛抄模板。技术可行性要写清楚为什么用Django开发效率高、自带Admin、生态成熟经济可行性写所用技术全免费、服务器可以用校园网或本地部署操作可行性写界面友好、学生容易上手。第二数据库设计这一章不能只贴表结构要画E-R图实体关系图讲述从需求到实体的映射过程。手画或用数据库设计工具都行但别在网上找别人的图硬塞——老师一眼能看出风格不一致。第三系统实现章节要有“核心代码文字说明运行截图”三段式代码要有注释不是复制大段代码上去了事而是要挑3-4段真正核心的代码讲清楚比如订单状态机、商品锁定逻辑。5.2 答辩高频问题整理答辩老师不会问你“这个系统用了什么技术”他们会从项目核心逻辑和你的描述里挑破绽。我归纳了几个高频问题系统有什么创新点相比普通商城系统二手交易平台的特殊处理是什么数据库中有哪些表它们之间的关系分页是怎么实现的为什么用MySQL而不是SQLite搜索功能是怎么实现的如何防止一个商品被重复购买订单状态是怎么流转的支付接口是真实的吗测试用例覆盖了哪些场景这些都是系统实体问题每个都对应你代码里的一个模块。你必须做到对任意一个细节追问都能流畅回答建议答辩前把这些问题和自己写的代码逐一对照练习。有一个高概率问题“如果你部署到公网需要考虑哪些安全问题”老师并不期望你给出完美答案而是想看你有没有安全思维。能说出CSRF防护Django默认开启、XSS过滤模板自动转义、SQL注入防护ORM参数化查询、权限控制装饰器限制访问、敏感信息加密密码哈希存储这几点就已经超过大多数毕设水平了。5.3 演示环境和话术设计演示环节设计非常重要。开场白不要从功能列表开始而要讲一个场景“假设我是大四学生毕业前有一台只用了一年的台灯想卖掉”——然后顺着这个场景走完发布、浏览、购买、订单处理整个流程。这样讲比“这是登录页面这是注册页面”要生动得多。演示前先把环境起好浏览器打开到登录页数据库里有3-5条有真实感的数据比如“高等数学教材 8成新 15元”“九成新山地自行车 校园骑行 200元”。商品图片也要真实不要用明显的网络示例图哪怕是手机拍的书桌一角也比官方图库有说服力。如果系统里加了留言功能提前在商品下留一条模拟对话“同学这书还有笔记吗”“有的字迹清晰不影响阅读”这个细节能让老师感受到你真的考虑了二手交易的真实使用场景。另外准备一份“手动异常演示”也会加分——让用户输入错误密码、重复提交订单展示系统有处理异常的逻辑——这很体现工程素养。最后分享一点个人经验做毕业设计这一年不少同学干到后面就变成“代码搬运工”了。我要提醒的是不要光盯着“实现”更要关注“设计”——你在论文里讲清楚每一个为什么比main代码炫技重要得多。Django这个框架能让你快速搭出项目骨架但真正拉开差距的是订单状态机有没有设计清楚、并发购买有没有考虑锁、测试用有没有覆盖核心流程。这些地方花心思你的答辩状态是完全不一样的。再有就是代码写完后哪怕不部署也一定要把环境打包好写一份清晰的README——你永远不会知道毕业设计验收那天会不会从你的电脑切换到一台不知名服务器上演示。