微信小程序+Django校园店铺商城毕设：从数据库到支付部署全解析

最近帮一个学弟把他的毕设项目从“能跑”梳理到“能演示完还能讲清楚答辩”，项目正是“python_django基于微信小程序的校园店铺商城电子商务系统”。说实话，这类题目在计算机毕业设计里属于高频常客，但正因为高频，很多人的实现只是搭了个 Demo：能登录、能加购物车、能下单就觉得自己做完了，可一旦答辩老师追问几个为什么：
你为什么要用小程序的 web-view？缓存做了没有？
订单状态是怎么流转的？超时未支付怎么处理？
商家端为什么复用了 Django admin 而不是单独做一套？
大部分人就答不上来。

这篇内容我尽量不端着讲话，就用实际做这个项目时的思路来讲。从需求分析、数据库设计、前后端联调、微信支付接入到最终部署上线的完整链路，把容易踩坑的点、值得在答辩里讲的亮点、以及能体现工作量的小细节都拆开揉碎讲一遍。适合正在做类似校园商城、二手交易、便利店小程序毕设的同学参考，也适合想快速了解小程序 + Django 这套组合到底怎么落地的开发者。

1. 为什么是“校园店铺商城”这个场景：需求定位与技术选型思路

1.1 校园场景下的真实痛点是什么

很多同学拿到这种题目后，第一件事就是去看模板商城：用户端有首页轮播图、分类列表、商品详情、购物车、订单列表，后端有商品 CRUD 和订单管理，然后套上漂亮的 UI 就觉得功能齐全。

但校园店铺商城和普通电商平台有一个本质区别：它是一个“多店铺、小范围、高复购、强信任”的场景。学生需要的是快速找到教学楼附近的店铺，比如打印店、奶茶店、水果店、二手书店；店铺需要的是低成本地把自己的商品上架，让方圆两公里内的学生直接下单。

所以我在设计时把系统定位成三个角色：

• 学生买家：浏览店铺、搜索商品、下单、在线支付、查看订单状态。
• 店铺商家：维护自家店铺、上架下架商品、修改库存、处理接单和完成订单。
• 系统管理员：负责平台运营，审核店铺入驻，处理违规内容，维护全局分类。

这跟普通商城单角色模型比，多出了“店铺维度”和“商家自运营”的概念，数据模型和接口设计都会跟着复杂起来，也更好写。

1.2 为什么选微信小程序而不是 App 或 H5

校园场景有一个特点：用户不愿意为点一杯奶茶专门去装一个 App，而且安卓、iOS 两套平台如果都要覆盖，开发成本直接翻倍。微信小程序用完即走，正好契合这个场景。

我自己的理解是微信小程序给校园电商带来了三层价值：

1. 身份获取便捷：wx.login 可以直接拿微信身份，不需要用户填手机号注册，比传统 Web 端的账号密码体系省掉一长串交互。
2. 传播成本低：同学之间把小程序卡片转发到群里就可以完成一次拉新，这是校园商家最需要的。
3. 微信支付闭环：用户支付不需要跳出当前应用，前端调用 wx.requestPayment 拉起支付，支付结果直接回调到后端，整个体验非常顺。

1.3 后端为什么是 Django 而不是别的框架

Django 在国内高校实验室和毕设中的存在感一直很强，理由非常现实：

• 自带 Admin 后台，商家管理和平台运营可以少写很多页面。项目里我做的是一个轻量级商家后台，但平台侧的超管功能直接用了 Django Admin 做二次开发，省下的时间用来打磨小程序端体验。
• ORM 写起来快，Django 的模型迁移机制很适合“设计稿边写边改”的开发节奏。
• 自带认证体系和权限框架，虽然实际项目里我对接的是微信小程序登录，但 Django 的 auth 体系可以帮我管理后台管理员和店长账号。
• Python 的生态在数据分析方向有延伸，如果后续想加销量分析、热销商品推荐，直接写脚本就能跑。

在技术选型上，最终的方案是：

这套组合最大的好处是每一层都有现成的轮子，不会在“非核心功能”上浪费太多搭建时间。

2. 数据库设计：从用户到订单，把一张订单表拆明白

2.1 角色模型与字段设计中的取舍

数据库设计是一个电商系统最值得花时间的地方，也是答辩时最容易加分的部分。我的做法是先画清楚实体关系，再落到 Django Model。

这里有几个实体的划分是经过权衡的：

用户模型

因为小程序登录的用户与后台管理员是两个体系，我一开始直接继承了 Django 自带的 User 做了一对一扩展。核心字段包括：

• user：关联 Django 内置用户表，存储用户名和密码
• identity：用户身份标记，用一个 IntegerField 区分，0 是普通买家，1 是店长
• student_id：学生学号，校园场景可以加身份证认证
• phone：电话
• avatar_url / nickname：微信头像昵称
• balance：余额，后来设计了钱包逻辑，用于线下自提和退款

店铺模型

有两个细节需要注意：

• owner 字段必须关联到 User，这样才能通过已登录用户查询“他管的店铺”。
• 店铺不能直接上架，需要管理员后台审核。所以加一个 status 字段，0 待审核，1 正常营业，2 已关闭。

这个“审核”机制是我故意留的，实现成本很低，但是能让系统看起来像一个真正的平台，而不是人人都可以随便开店。

商品模型

商品字段中最容易漏掉的是销量字段 sales_count。这是一个典型的用时间换查询复杂度的做法：排行榜页面直接按 sales_count 倒序，而不是去统计订单详情表，否则每打开一次首页就要联表做聚合查询。

商品必须归属某个店铺，所以外键指向店铺而不是店铺的 owner。这里有同学会搞混：外键是指向 Shop 还是指向 User？如果只指向 User，意味着一个人开多个店的时候商品归属就乱了。这个问题我在给学弟 review 的时候专门纠正过。

2.2 订单与订单详情：为什么一定要拆成两张表

订单表是这个系统的核心，我的设计分成主订单表和订单商品明细表。

主订单表字段包括：

• order_no：订单编号，我用“年月日时分秒 + 6 位随机数”生成，这是前端展示和用户沟通的操作号。
• user：下单用户外键
• shop：对应的店铺，如果平台有多店铺，这一条特别重要，商家登录后按这个字段过滤他收到的订单。
• total_amount：总金额，单位用“分”存储。
• status：订单状态，用 IntegerField 而不是 CharField。

订单状态是整个系统最容易被问崩的地方。我定义的状态如下：

python复制ORDER_STATUS = [
    (0, "待付款"),
    (1, "待发货/待接单"),
    (2, "待收货/待自提"),
    (3, "已完成"),