1. 项目概述1.1 需求背景与核心价值先说结论积分制零食自选销售平台本质上是一个“自带激励闭环的电商系统”。它在传统零食售卖的基础上引入积分获取与消耗机制用户通过购买零食获得积分返还积分又可以兑换指定的零食或抵扣部分金额从而形成“消费—得积分—再消费”的循环。这类项目在校园创业、办公室零食角、社团运营、小型零售试点等场景非常常见。我见过不少同学或小型团队拿着类似题目做毕设或课设因为这个题目的“舒适区”很大业务模型清晰但又不至于太简单技术栈可深可浅既有商品管理、购物车、订单、支付或模拟支付这类电商常规模块又有积分规则、积分流水、兑换记录这类偏策略设计的模块。做完之后无论是自己用、拿去答辩、还是作为作品集项目说服力都很强。从技术选型看题目明确给了 Django / Flask 二选一作为后端前端用 Vue开发环境是 PyCharm。这是一个典型的 Python 后端 前端分离架构的组合。我在实际带项目时见过太多人卡在“环境搭好了前后端串不起来”这个坎上所以这篇博文会重点把技术选型的逻辑、数据模型的设计、以及最容易翻车的联调细节掰开来讲。1.2 关键词拆解与项目范围界定这个题目如果只从字面看至少包含以下几个必须搞清的概念积分制、零食自选、销售平台、前后端分离。积分制是一个业务规则层最常见的实现方式是消费得积分、积分抵现或兑换指定商品、积分过期或清零策略。这里的关键不是“要不要积分”而是积分规则如何落到数据库设计和接口逻辑里后面我会专门讲。零食自选意味着商品品类是零食为主通常还需要支持分类筛选如饼干、辣条、糖果、饮料、库存管理、轮播推荐、搜索功能。自选的体验核心是“逛得爽”所以前端首页、商品列表、购物车的交互流畅度很重要。销售平台则要求有完整的交易闭环用户注册登录、商品浏览、加入购物车、下单结算、支付实际项目往往用模拟支付或余额抵扣、订单状态管理、后台管理端的上架/下架、库存同步、订单处理。前后端分离是决定代码组织方式的关键。前端用 Vue配合 Vue Router Vuex/Pinia Axios后端用 Django REST Framework或 Flask Flask-RESTful通过 RESTful API 通信。PyCharm 作为开发工具更多承担的是后端开发和调试的角色前端工程通常用 VS Code 或 PyCharm 的 Web 插件打开都行。一句话概括项目的边界一个支持用户积分获取与消耗、具备完整商品浏览与订单交易流程、带有后台管理能力的零食销售系统。技术实现上需要同时搞定数据库建模、API 设计、前端页面、权限控制、前后端联调五个层面任何一层偷懒都会在后期付出代价。2. 整体设计与技术选型2.1 前端框架Vue 2 还是 Vue 3这是初学者问得最多的一个问题我的建议很明确新项目直接用 Vue 3 Vite Pinia。理由不是 Vue 3 比 Vue 2 新而是 Vue 3 的组合式 API 在写业务逻辑时的组织性确实更好。比如积分明细页用setup语法可以把“拉取积分流水、筛选积分类型、分页加载”这几件事集中在一个函数里一目了然。而 Vue 2 的 Options API 在小项目里勉强够用一旦组件多了data、methods、computed 各管各的改一个联动功能要来回跳很磨人。Vite 替代 Vue CLI 也是我强烈推荐的。Vite 启动速度快到令人愉悦改完代码热更新几乎是秒级的。PyCharm 里配置 Vue 项目时只要让它识别到package.json就能提供语法提示并不存在“PyCharm 不支持 Vue 3”这种问题只是前端代码我通常还是习惯用 VS Code 写两个工具各司其职。Pinia 比 Vuex 的另一个优势是 TypeScript 支持更友好即使你不写 TSPinia 的 store 定义方式也更简单没有那么多 mutation、getters 的概念负担。简单说Vuex 是在给你立规矩Pinia 是在帮你省事。2.2 后端选型Django 还是 Flask题目把两个都写上其实是最容易纠结的地方。我的建议是如果是毕设或课设无脑选 Django如果是想快速做一个内部 Demo 且后援较少选 Flask 也完全可以。Django 的优势在于“全家桶”。用户认证、Admin 后台、ORM、数据库迁移、表单校验、安全防护这些全都是内置的。尤其 Admin 后台这个功能对管理端开发简直是降维打击零食上架、库存修改、订单查看这些后台功能你完全可以在 Django Admin 里先做一版然后再开发自定义管理页相当于买一送一。配合 Django REST FrameworkDRF写 API 的效率非常高Serializer 自动处理数据校验与序列化ViewSet Router 能省掉一大半路由和视图代码。Flask 的优势在于“轻”和“自由”。如果项目规模不大Flask 用 Flask-SQLAlchemy Flask-Migrate Flask-RESTful 也能拼出一套完整后端。而且 Flask 的代码逻辑更直白想怎么组织就怎么组织对有些人来说反而更容易看懂。但它需要你手动集成的组件更多安全防护也要自己做到后期反而容易踩坑。用表格做个对比维度Django DRFFlask Flask-RESTful学习曲线初期较陡组件多平缓易上手用户认证内置 User 模型与 session/token需自行实现或集成包后台管理自带 Admin可快速搭建需自行开发或使用 third-partyAPI 开发效率DRF 序列化视图集效率极高Flask-RESTful 较轻量需手动多数配置数据库迁移内置 migrations需配合 Flask-Migrate适合场景课程设计、毕设、完整商业项目小型项目、快速原型如果你已经会 Flask 且项目不大用 Flask 没有任何问题。但如果是从零开始我更推荐 Django因为它的“约束”反而能帮你少犯错误。2.3 积分制设计的核心逻辑积分制是整个平台区别于普通电商的点也是最容易在设计阶段被忽略的部分。基本积分规则一般包含三类获取积分用户下单且订单完成后按订单实付金额比例获取积分比如消费 1 元得 1 积分或者消费 10 元得 1 积分。这个比例根据你的利润空间定我见过多数项目用 1:1也就是花 1 块钱得 1 积分。消耗积分积分可以兑换指定商品也可以按比例抵扣订单金额。常见的设计是“100 积分 1 元”作为抵扣或者设置一个“积分专区”只能通过积分兑换。积分成熟/过期很多系统会给积分设置有效期比如“积分自获取日起一年内有效”到期自动清零。这个策略会增加实现复杂度如果需要做务必在数据库里加过期时间字段并设计定时任务处理。数据建模这里有一个非常重要的点积分数值不能只存在 User 表的字段里。必须设计一张积分流水表PointRecord也叫积分变动记录表每一笔增加或扣减都写一条流水并且通过事务保证“积分余额变动”和“流水记录”的一致性。这样做的好处是用户可以查看自己的积分明细管理员可以查账将来如果出现积分异常也方便定位。后续第 3 章我会给出具体的表结构设计和接口实现细节。2.4 技术栈组合与目录结构规划一个清晰的项目结构能避免很多后期混乱。我推荐按“后端工程 前端工程”双目录组织snack_platform/ ├── backend/ # Django 项目根目录 │ ├── manage.py │ ├── requirements.txt │ ├── config/ # settings/urls/wsgi 等 │ └── apps/ │ ├── users/ # 用户、认证、积分账户 │ ├── goods/ # 商品、分类、库存 │ ├── orders/ # 购物车、订单、支付记录 │ └── points/ # 积分规则、积分流水 ├── frontend/ # Vue 项目根目录 │ ├── package.json │ ├── vite.config.js │ ├── index.html │ └── src/ │ ├── api/ # 所有 axios 请求封装 │ ├── router/ │ ├── store/ # Pinia stores │ ├── views/ # 页面组件 │ └── components/ # 通用组件 └── docs/ # 设计文档、接口文档这里解释两点第一Django 的 app 按业务模块拆分而不是按“前端”“后端”拆这样每个 app 的 model、view、serializer 高内聚写完一个模块再写下一个模块时思路不会乱。第二前端 api 目录是重中之重所有请求统一封装方便统一处理 token 注入、错误提示、loading 状态。这套结构的好处是后端可以独立测试用 Postman 或 DRF 自带的可视化调试页面前端可以 mock 数据开发互不阻塞。等到联调阶段配好代理即可左右互搏的打法在多人协作和单人开发场景下都很好用。3. 数据库设计与积分规则落地3.1 数据表结构设计数据库设计讲究“先画表再写代码”。根据业务需求我至少会拆出以下八张核心表每张表的字段都有明确的业务含义用户表UserDjango 自带 AbstractUser 可以直接继承扩展增加phone手机号、avatar头像 URL、points_balance当前积分数注册时默认积分为 0。商品分类表Categoryname、sort_order排序、status是否启用。零食分类可预置一组数据饼干蛋糕、辣条膨化、糖果巧克力、坚果蜜饯、饮料冲调、速食食品。商品表Goods核心字段包括category外键、name、subtitle副标题、cover_image封面图、price价格Decimal 类型千万别用 Float、stock库存数量、sales_count销量、status上架/下架、is_points_exchange_only是否仅积分兑换、points_price所需积分数。这个is_points_exchange_only字段很关键它能让积分兑换商品和普通商品共用一张表不用单独建积分商城。购物车表CartItemuser外键、goods外键、quantity、selected是否勾选、created_at。购物车表设计成“每个用户每件商品一条记录数量累计”这样更新数量时逻辑更简单。订单表Orderorder_no唯一订单号、user、total_amount订单总金额、discount_amount优惠抵扣金额、pay_amount实付金额、points_used使用的积分数、points_earned可获得积分数、status待付款/已付款/待发货/已完成/已取消、created_at、pay_time等。订单明细表OrderItemorder外键、goods外键、goods_name下单时的商品名快照、price下单单价快照、quantity。为什么要做“快照”因为商品名称和价格随时可能被后台修改而订单作为交易凭证必须保留下单那一刻的信息不能用外键去实时查否则会出大问题。积分流水表PointRecorduser、change_type增加/扣减、change_value变动值正负、source_type关联业务类型订单返积分、积分兑换、积分抵扣、后台调整、source_id关联业务记录 ID、balance_after变动后余额、remark备注、created_at。这个表是整个积分系统的账本设计好了后面查账、对账、积分明细页全都靠它。3.2 积分双向变动的事务设计与防超卖积分系统的核心难点在于“不能只改余额”。在没有并发问题的理想世界里用户下单 - 订单完成 -user.points_balance earned就完事了。但在真实环境里用户可能在两个设备上同时下单或者同时用积分兑换多个商品如果只是简单的读取-计算-写入就会出现积分被重复使用、库存超卖的问题。解决办法就是用数据库事务 行级锁。Django 中可以用select_for_update()锁定用户积分账户的行确保同一个用户在同一时刻只有一个积分操作在执行from django.db import transaction from django.db.models import F def deduct_points(user, amount, source_type, source_id, remark): with transaction.atomic(): user User.objects.select_for_update().get(pkuser.pk) if user.points_balance amount: raise ValueError(积分不足) user.points_balance - amount user.save(update_fields[points_balance]) PointRecord.objects.create( useruser, change_type-1, change_valueamount, source_typesource_type, source_idsource_id, balance_afteruser.points_balance, remarkremark, )同理商品库存扣减也可以用select_for_update锁定库存行或者用F()表达式做原子的减法操作from django.db.models import F result Goods.objects.filter(pkgoods_id, stock__gtequantity).update( stockF(stock) - quantity, sales_countF(sales_count) quantity ) if result 0: raise ValueError(库存不足)这里的逻辑是先filter带条件更新利用数据库的原子UPDATE保证仅当库存充足时才扣减。返回受影响行数为 0 就说明库存不够避免了先查询再更新的“竞态窗口”。3.3 积分的获取规则与结算时机积分获取不能在下单时直接加因为用户可能取消订单或退款。更稳妥的做法是订单状态变为“已完成”时才给用户返积分。也就是说积分发放的触发点是订单状态流转事件而不是下单动作。订单状态机的流转可以这么设计待付款 - 用户取消 - 已取消待付款 - 用户支付 - 已付款已付款 - 商家发货 - 待收货如果简化流程可省略发货步骤待收货 - 用户确认收货 - 已完成已完成 - 执行返积分操作返积分操作要保证幂等如果订单已经被处理过一次就不能重复发。最简单的做法是在 Order 表里增加一个points_granted字段每次返积分前判断一下再用事务包住“更新订单状态 发放积分 写流水”保证要么全成要么全不成。3.4 数据库设计的避坑经验有几点是实际开发中容易踩的坑我单独列出来金额一律用 DecimalField不要用 FloatField。Float 在计算机中是浮点表示0.1 0.2 可能等于 0.30000000000000004涉及钱就是事故。Django 里DecimalField(max_digits10, decimal_places2)是标准做法。订单号生成。不要用自增 ID 直接当订单号太容易被人猜到业务量。可以拼规则时间戳 随机数 用户ID后几位比如2025031214352208123456。记得加唯一索引。软删除 vs 硬删除。商品删除建议用is_active或status字段标记不要物理删除否则历史订单里的关联关系会断掉。数据库索引。usercreated_at的组合索引在积分流水表和订单表上很有必要不然用户查看积分明细时会越来越慢。4. 实操过程与前后端实现4.1 开发环境准备环境准备这一步看似简单实际上我见过太多人卡在这里。推荐一套稳妥的组合Python 3.10不要用 3.12 以下太老的版本Django 新版本需要 Python 3.10 支持Django 4.2 LTS 或 5.xLTS 版本更稳插件兼容更好djangorestframework、djangorestframework-simplejwt做 JWT 登录django-cors-headers解决跨域问题mysqlclient 或 pymysql如果使用 MySQL 8推荐 mysqlclientSQLite 开发阶段也够用前端Node.js 18Vite 创建 Vue 3 项目创建项目基本命令# 后端 python -m venv venv source venv/bin/activate # Windows 是 venv\Scripts\activate pip install django djangorestframework djangorestframework-simplejwt django-cors-headers django-admin startproject config . python manage.py startapp users python manage.py startapp goods python manage.py startapp orders python manage.py startapp points # 前端 npm create vitelatest frontend -- --template vue cd frontend npm install npm install vue-router4 pinia axios注意Django 项目结构里我特意用了config作为配置目录名而不是默认的snack_platform这样更清晰避免和项目根目录重名混淆。4.2 后端核心实现用户认证模块。使用 Djangorestframework-simplejwt 做 JWT 认证。用户注册接口只需要序列化器里带username、password、confirm_password、phone密码用make_password加密保存。登录接口用 Django 自带的authenticate校验成功后返回 access 和 refresh token。一个关键配置是SIMPLE_JWT的设置from datetime import timedelta SIMPLE_JWT { ACCESS_TOKEN_LIFETIME: timedelta(days1), REFRESH_TOKEN_LIFETIME: timedelta(days7), AUTH_HEADER_TYPES: (Bearer,), }商品接口。商品列表接口需要支持分类筛选、关键词搜索、分页、排序。DRF 的过滤器django_filters可以省不少代码但如果只想用 DRF 自带功能手动在get_queryset里加条件也不复杂。注意积分兑换商品需要额外返回points_price和is_points_exchange_only字段前端商品卡片上要能区分“¥”和“积分”两种标识。购物车接口。增删改查各一个接口数量变更时校验库存上限。一个容易忽视的问题添加购物车时如果该项目已经禁售或库存为 0要返回明确错误信息而不是静默失败。订单创建。这是业务逻辑最重的接口。下单时传入一个商品 ID 与数量的数组后端要做以下事项校验所有商品存在且在售校验库存是否充足计算总金额校验用户是否使用积分抵扣如果使用调用扣积分逻辑创建订单主表和订单明细表使用外层事务包起来返回订单号和前端需要继续支付的参数。支付逻辑。实际场景中接入第三方支付需要商户资质毕设项目里一般用“模拟支付”就好。用户点击“模拟支付”后端把订单状态从待付款改为已付款并记录支付时间。如果要更真实一点可以做一个简单的余额支付或虚拟钱包用户先充值然后下单时用余额支付。这也能顺带做一个“钱包充值”模块扩展性更好。积分流水接口。返回当前用户的所有积分变动记录按时间倒序分页返回。流水查询时要注意不要把balance_after字段暴露成可写字段。4.3 前端核心实现项目初始化与路由设计。前端页面至少需要这些路由/首页展示轮播图、推荐零食、分类导航/goods商品列表页支持分类筛选与搜索/goods/:id商品详情页含加入购物车按钮/cart购物车页支持勾选、数量修改、删除/checkout结算页支持积分抵扣选项展示实付金额/orders订单列表页按状态分 tab/points积分明细页/login和/register登录注册页/admin后台管理页或独立管理端Axios 请求封装。把带 token 的请求统一封到一个request.js里利用 axios 拦截器// request.js import axios from axios; import { useUserStore } from /store/user; const request axios.create({ baseURL: import.meta.env.VITE_API_BASE_URL || /api, timeout: 15000, }); request.interceptors.request.use((config) { const userStore useUserStore(); if (userStore.token) { config.headers.Authorization Bearer ${userStore.token}; } return config; }); request.interceptors.response.use( (response) response.data, (error) { if (error.response error.response.status 401) { // token 失效跳转登录页 const userStore useUserStore(); userStore.logout(); window.location.href /login; } return Promise.reject(error); } ); export default request;baseURL用环境变量配置开发时通过 Vite 的代理转发/api到后端地址这样既避免跨域问题上线时也只要改环境变量就行。积分条展示与购物车联动。积分条可以用 store 里的全局状态管理用户登录后加载一次购物车结算页再拉一次最新值。用户选择“使用积分抵扣”时前端要实时计算“可抵扣上限”和“实付金额”。计算逻辑要注意后端校验是最终一刀前端只是用户体验。4.4 前后端联调与大版本发布联调阶段最典型的模式是后端用 Django 默认的开发服务器跑在 8000 端口前端 Vite 跑在 5173 端口。Vite 配置代理让前端请求直接打到后端// vite.config.js import { defineConfig } from vite; import vue from vitejs/plugin-vue; export default defineConfig({ plugins: [vue()], server: { port: 5173, proxy: { /api: { target: http://localhost:8000, changeOrigin: true, rewrite: (path) path.replace(/^\/api/, ), }, }, }, });这样一个页面流程就串起来了前端发请求到/api/goods- Vite 代理转发到http://localhost:8000/goods- Django 处理并返回 JSON。开发过程中无非是改一处看一处很有节奏感。4.5 测试用例与上线前的自查清单很多同学到最后交付时才发现前后端接口对不上、字段名不一致这是联调阶段最普遍的痛苦来源。建议在联调前先做一次“接口契约检查”把后端每个接口的返回值字段列成一张表前端开发照着这个表来写页面数据绑定。字段对不上的问题在写表这步就能暴露大半。测试用例至少覆盖以下场景注册、重复用户名注册、登录成功/失败商品列表、分类筛选、搜索无结果加入购物车、修改数量、删除商品下单、库存不足、积分不足、未登录下单积分获取、积分消费、流水记录准确性重复提交订单订单号唯一5. 常见问题与部署经验5.1 联调阶段的高频问题速查表问题现象排查方向解决方案前端请求 404代理路径或 URL 不匹配确认 Vite 代理里/api是否自动去掉了前缀对照后端urls.py实际路由前端请求报错 403CSRF 或权限不足DRF 需在REST_FRAMEWORK中配置默认认证类CSRF 在 token 认证下通常不再生效前端能打开页面但拿不到数据CORS 或网络层问题后端安装 django-cors-headers在 settings 配置CORS_ALLOW_ALL_ORIGINS True开发阶段图片上传后无法访问媒体文件路由未配置在urls.py中添加static和media的服务路由积分结算金额对不上Decimal 精度问题全部金额用DecimalField代码中避免float()转换计算用Decimal运算用户退出登录后还能访问订单接口token 过期策略未生效确认前端 axios 请求拦截器里每次都带上了最新 token且接口权限设置为IsAuthenticatedVue 修改数据后页面不更新响应式对象未正确使用Vue 3 中如果使用reactive替换整个对象时请用Object.assign或直接改属性别直接整体赋值5.2 常见业务逻辑坑积分抵扣与优惠的边界。如果订单同时支持满减和积分抵扣系统需要定义“哪个先扣”。推荐规则是先算满减再算积分抵扣最后算实付金额。且积分抵扣金额不能超过实付金额。这个规则在前端和后端必须一致不然会出现“前端显示实付 0 元后端算出负数”的奇葩问题。购物车商品失效。用户加入购物车的商品可能过几天被下架了或者改价了库存变了。购物车接口每次拉数据时要联动查询商品当前状态对失效商品给出明确标识“已失效”不允许继续结算。订单状态复盘。做项目演示时最怕“状态错乱”。我建议 demo 前提前跑几遍完整流程注册 - 逛商品 - 加购 - 下单 - 模拟支付 - 确认收货 - 查看积分。有条件的把DEBUGTrue开着遇到错误能直接看到堆栈信息。5.3 部署上线的简单方案对于毕设答辩或小范围试运营部署不需要搞得很复杂。一台 2核4G 的服务器配置 MySQL Nginx uWSGI 前端静态文件即可。后端用 uWSGI 跑 Djangopip install uwsgi uwsgi --http :8000 --module config.wsgi --processes 2 --threads 2Nginx 配置两个 server 块一个端口转发到 uWSGI另一个端口托管 Vue 构建后的静态文件并用location /api/代理到后端。server { listen 80; server_name your-domain.com; root /var/www/frontend/dist; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8000; # 后端去掉 /api 前缀 proxy_set_header Host $host; } }注意Vite 构建时如果使用了createWebHistory路由务必在 Nginx 里配置try_files回退到index.html否则刷新页面会 404。这也是部署阶段最容易出的问题。部署后要做一次外网环境回归测试因为本地开发用的是 SQLite线上用了 MySQL表结构虽然一致但字段行为可能略有差异比如大小写敏感、事务隔离级别尽早发现问题比线上暴露强。6. 后续扩展与个人实践心得我实际做过类似项目之后最深的体会是整个系统最难的部分不是某个单独技术点而是“积分规则”和“订单状态机”这两条业务逻辑线的交织。代码本身不复杂但逻辑分支特别多稍一疏忽就会出现“积分发了但订单没完成”或者“订单退款但积分没扣回”这种账实不符的尴尬。说几个我个人认为值得融入项目里的加分项积分明细页加一个“来源/去向”图标用户能清楚看到每一笔积分是买东西返的还是兑换商品花的。这个事情在数据库层面只要source_type和source_id查一下就能显示但对用户体验的提升却很直接。后台加分一个“积分规则配置”页面让管理员可以在后台直接修改返积分比例、最低兑换门槛等参数而不是改代码。这个需求只要新增一张配置表然后在返积分逻辑中读取配置即可工作量不大但显得系统很完整。如果想更进一步可以在订单完成后自动生成一张 PDF 电子小票或者做一个“零食热度榜”的推荐位。这些功能不会破坏核心流程但会让演示效果明显上一个档次。对于正在做毕设或者新入行的朋友我给的建议是先跑通最核心的闭环商品 - 购物车 - 订单 - 积分再往周边拓展能力。千万别一上来就铺开做权限管理、多角色、消息通知这些锦上添花的功能否则很容易在主干还没走通时先被枝枝叶叶耗尽心力。前后端分离的项目联调沟通成本本来就高如果把每一步都留出“验证接口返回数据是否正确”的时间最后整合阶段会顺畅很多。
1. 项目概述1.1 需求背景与核心价值先说结论积分制零食自选销售平台本质上是一个“自带激励闭环的电商系统”。它在传统零食售卖的基础上引入积分获取与消耗机制用户通过购买零食获得积分返还积分又可以兑换指定的零食或抵扣部分金额从而形成“消费—得积分—再消费”的循环。这类项目在校园创业、办公室零食角、社团运营、小型零售试点等场景非常常见。我见过不少同学或小型团队拿着类似题目做毕设或课设因为这个题目的“舒适区”很大业务模型清晰但又不至于太简单技术栈可深可浅既有商品管理、购物车、订单、支付或模拟支付这类电商常规模块又有积分规则、积分流水、兑换记录这类偏策略设计的模块。做完之后无论是自己用、拿去答辩、还是作为作品集项目说服力都很强。从技术选型看题目明确给了 Django / Flask 二选一作为后端前端用 Vue开发环境是 PyCharm。这是一个典型的 Python 后端 前端分离架构的组合。我在实际带项目时见过太多人卡在“环境搭好了前后端串不起来”这个坎上所以这篇博文会重点把技术选型的逻辑、数据模型的设计、以及最容易翻车的联调细节掰开来讲。1.2 关键词拆解与项目范围界定这个题目如果只从字面看至少包含以下几个必须搞清的概念积分制、零食自选、销售平台、前后端分离。积分制是一个业务规则层最常见的实现方式是消费得积分、积分抵现或兑换指定商品、积分过期或清零策略。这里的关键不是“要不要积分”而是积分规则如何落到数据库设计和接口逻辑里后面我会专门讲。零食自选意味着商品品类是零食为主通常还需要支持分类筛选如饼干、辣条、糖果、饮料、库存管理、轮播推荐、搜索功能。自选的体验核心是“逛得爽”所以前端首页、商品列表、购物车的交互流畅度很重要。销售平台则要求有完整的交易闭环用户注册登录、商品浏览、加入购物车、下单结算、支付实际项目往往用模拟支付或余额抵扣、订单状态管理、后台管理端的上架/下架、库存同步、订单处理。前后端分离是决定代码组织方式的关键。前端用 Vue配合 Vue Router Vuex/Pinia Axios后端用 Django REST Framework或 Flask Flask-RESTful通过 RESTful API 通信。PyCharm 作为开发工具更多承担的是后端开发和调试的角色前端工程通常用 VS Code 或 PyCharm 的 Web 插件打开都行。一句话概括项目的边界一个支持用户积分获取与消耗、具备完整商品浏览与订单交易流程、带有后台管理能力的零食销售系统。技术实现上需要同时搞定数据库建模、API 设计、前端页面、权限控制、前后端联调五个层面任何一层偷懒都会在后期付出代价。2. 整体设计与技术选型2.1 前端框架Vue 2 还是 Vue 3这是初学者问得最多的一个问题我的建议很明确新项目直接用 Vue 3 Vite Pinia。理由不是 Vue 3 比 Vue 2 新而是 Vue 3 的组合式 API 在写业务逻辑时的组织性确实更好。比如积分明细页用setup语法可以把“拉取积分流水、筛选积分类型、分页加载”这几件事集中在一个函数里一目了然。而 Vue 2 的 Options API 在小项目里勉强够用一旦组件多了data、methods、computed 各管各的改一个联动功能要来回跳很磨人。Vite 替代 Vue CLI 也是我强烈推荐的。Vite 启动速度快到令人愉悦改完代码热更新几乎是秒级的。PyCharm 里配置 Vue 项目时只要让它识别到package.json就能提供语法提示并不存在“PyCharm 不支持 Vue 3”这种问题只是前端代码我通常还是习惯用 VS Code 写两个工具各司其职。Pinia 比 Vuex 的另一个优势是 TypeScript 支持更友好即使你不写 TSPinia 的 store 定义方式也更简单没有那么多 mutation、getters 的概念负担。简单说Vuex 是在给你立规矩Pinia 是在帮你省事。2.2 后端选型Django 还是 Flask题目把两个都写上其实是最容易纠结的地方。我的建议是如果是毕设或课设无脑选 Django如果是想快速做一个内部 Demo 且后援较少选 Flask 也完全可以。Django 的优势在于“全家桶”。用户认证、Admin 后台、ORM、数据库迁移、表单校验、安全防护这些全都是内置的。尤其 Admin 后台这个功能对管理端开发简直是降维打击零食上架、库存修改、订单查看这些后台功能你完全可以在 Django Admin 里先做一版然后再开发自定义管理页相当于买一送一。配合 Django REST FrameworkDRF写 API 的效率非常高Serializer 自动处理数据校验与序列化ViewSet Router 能省掉一大半路由和视图代码。Flask 的优势在于“轻”和“自由”。如果项目规模不大Flask 用 Flask-SQLAlchemy Flask-Migrate Flask-RESTful 也能拼出一套完整后端。而且 Flask 的代码逻辑更直白想怎么组织就怎么组织对有些人来说反而更容易看懂。但它需要你手动集成的组件更多安全防护也要自己做到后期反而容易踩坑。用表格做个对比维度Django DRFFlask Flask-RESTful学习曲线初期较陡组件多平缓易上手用户认证内置 User 模型与 session/token需自行实现或集成包后台管理自带 Admin可快速搭建需自行开发或使用 third-partyAPI 开发效率DRF 序列化视图集效率极高Flask-RESTful 较轻量需手动多数配置数据库迁移内置 migrations需配合 Flask-Migrate适合场景课程设计、毕设、完整商业项目小型项目、快速原型如果你已经会 Flask 且项目不大用 Flask 没有任何问题。但如果是从零开始我更推荐 Django因为它的“约束”反而能帮你少犯错误。2.3 积分制设计的核心逻辑积分制是整个平台区别于普通电商的点也是最容易在设计阶段被忽略的部分。基本积分规则一般包含三类获取积分用户下单且订单完成后按订单实付金额比例获取积分比如消费 1 元得 1 积分或者消费 10 元得 1 积分。这个比例根据你的利润空间定我见过多数项目用 1:1也就是花 1 块钱得 1 积分。消耗积分积分可以兑换指定商品也可以按比例抵扣订单金额。常见的设计是“100 积分 1 元”作为抵扣或者设置一个“积分专区”只能通过积分兑换。积分成熟/过期很多系统会给积分设置有效期比如“积分自获取日起一年内有效”到期自动清零。这个策略会增加实现复杂度如果需要做务必在数据库里加过期时间字段并设计定时任务处理。数据建模这里有一个非常重要的点积分数值不能只存在 User 表的字段里。必须设计一张积分流水表PointRecord也叫积分变动记录表每一笔增加或扣减都写一条流水并且通过事务保证“积分余额变动”和“流水记录”的一致性。这样做的好处是用户可以查看自己的积分明细管理员可以查账将来如果出现积分异常也方便定位。后续第 3 章我会给出具体的表结构设计和接口实现细节。2.4 技术栈组合与目录结构规划一个清晰的项目结构能避免很多后期混乱。我推荐按“后端工程 前端工程”双目录组织snack_platform/ ├── backend/ # Django 项目根目录 │ ├── manage.py │ ├── requirements.txt │ ├── config/ # settings/urls/wsgi 等 │ └── apps/ │ ├── users/ # 用户、认证、积分账户 │ ├── goods/ # 商品、分类、库存 │ ├── orders/ # 购物车、订单、支付记录 │ └── points/ # 积分规则、积分流水 ├── frontend/ # Vue 项目根目录 │ ├── package.json │ ├── vite.config.js │ ├── index.html │ └── src/ │ ├── api/ # 所有 axios 请求封装 │ ├── router/ │ ├── store/ # Pinia stores │ ├── views/ # 页面组件 │ └── components/ # 通用组件 └── docs/ # 设计文档、接口文档这里解释两点第一Django 的 app 按业务模块拆分而不是按“前端”“后端”拆这样每个 app 的 model、view、serializer 高内聚写完一个模块再写下一个模块时思路不会乱。第二前端 api 目录是重中之重所有请求统一封装方便统一处理 token 注入、错误提示、loading 状态。这套结构的好处是后端可以独立测试用 Postman 或 DRF 自带的可视化调试页面前端可以 mock 数据开发互不阻塞。等到联调阶段配好代理即可左右互搏的打法在多人协作和单人开发场景下都很好用。3. 数据库设计与积分规则落地3.1 数据表结构设计数据库设计讲究“先画表再写代码”。根据业务需求我至少会拆出以下八张核心表每张表的字段都有明确的业务含义用户表UserDjango 自带 AbstractUser 可以直接继承扩展增加phone手机号、avatar头像 URL、points_balance当前积分数注册时默认积分为 0。商品分类表Categoryname、sort_order排序、status是否启用。零食分类可预置一组数据饼干蛋糕、辣条膨化、糖果巧克力、坚果蜜饯、饮料冲调、速食食品。商品表Goods核心字段包括category外键、name、subtitle副标题、cover_image封面图、price价格Decimal 类型千万别用 Float、stock库存数量、sales_count销量、status上架/下架、is_points_exchange_only是否仅积分兑换、points_price所需积分数。这个is_points_exchange_only字段很关键它能让积分兑换商品和普通商品共用一张表不用单独建积分商城。购物车表CartItemuser外键、goods外键、quantity、selected是否勾选、created_at。购物车表设计成“每个用户每件商品一条记录数量累计”这样更新数量时逻辑更简单。订单表Orderorder_no唯一订单号、user、total_amount订单总金额、discount_amount优惠抵扣金额、pay_amount实付金额、points_used使用的积分数、points_earned可获得积分数、status待付款/已付款/待发货/已完成/已取消、created_at、pay_time等。订单明细表OrderItemorder外键、goods外键、goods_name下单时的商品名快照、price下单单价快照、quantity。为什么要做“快照”因为商品名称和价格随时可能被后台修改而订单作为交易凭证必须保留下单那一刻的信息不能用外键去实时查否则会出大问题。积分流水表PointRecorduser、change_type增加/扣减、change_value变动值正负、source_type关联业务类型订单返积分、积分兑换、积分抵扣、后台调整、source_id关联业务记录 ID、balance_after变动后余额、remark备注、created_at。这个表是整个积分系统的账本设计好了后面查账、对账、积分明细页全都靠它。3.2 积分双向变动的事务设计与防超卖积分系统的核心难点在于“不能只改余额”。在没有并发问题的理想世界里用户下单 - 订单完成 -user.points_balance earned就完事了。但在真实环境里用户可能在两个设备上同时下单或者同时用积分兑换多个商品如果只是简单的读取-计算-写入就会出现积分被重复使用、库存超卖的问题。解决办法就是用数据库事务 行级锁。Django 中可以用select_for_update()锁定用户积分账户的行确保同一个用户在同一时刻只有一个积分操作在执行from django.db import transaction from django.db.models import F def deduct_points(user, amount, source_type, source_id, remark): with transaction.atomic(): user User.objects.select_for_update().get(pkuser.pk) if user.points_balance amount: raise ValueError(积分不足) user.points_balance - amount user.save(update_fields[points_balance]) PointRecord.objects.create( useruser, change_type-1, change_valueamount, source_typesource_type, source_idsource_id, balance_afteruser.points_balance, remarkremark, )同理商品库存扣减也可以用select_for_update锁定库存行或者用F()表达式做原子的减法操作from django.db.models import F result Goods.objects.filter(pkgoods_id, stock__gtequantity).update( stockF(stock) - quantity, sales_countF(sales_count) quantity ) if result 0: raise ValueError(库存不足)这里的逻辑是先filter带条件更新利用数据库的原子UPDATE保证仅当库存充足时才扣减。返回受影响行数为 0 就说明库存不够避免了先查询再更新的“竞态窗口”。3.3 积分的获取规则与结算时机积分获取不能在下单时直接加因为用户可能取消订单或退款。更稳妥的做法是订单状态变为“已完成”时才给用户返积分。也就是说积分发放的触发点是订单状态流转事件而不是下单动作。订单状态机的流转可以这么设计待付款 - 用户取消 - 已取消待付款 - 用户支付 - 已付款已付款 - 商家发货 - 待收货如果简化流程可省略发货步骤待收货 - 用户确认收货 - 已完成已完成 - 执行返积分操作返积分操作要保证幂等如果订单已经被处理过一次就不能重复发。最简单的做法是在 Order 表里增加一个points_granted字段每次返积分前判断一下再用事务包住“更新订单状态 发放积分 写流水”保证要么全成要么全不成。3.4 数据库设计的避坑经验有几点是实际开发中容易踩的坑我单独列出来金额一律用 DecimalField不要用 FloatField。Float 在计算机中是浮点表示0.1 0.2 可能等于 0.30000000000000004涉及钱就是事故。Django 里DecimalField(max_digits10, decimal_places2)是标准做法。订单号生成。不要用自增 ID 直接当订单号太容易被人猜到业务量。可以拼规则时间戳 随机数 用户ID后几位比如2025031214352208123456。记得加唯一索引。软删除 vs 硬删除。商品删除建议用is_active或status字段标记不要物理删除否则历史订单里的关联关系会断掉。数据库索引。usercreated_at的组合索引在积分流水表和订单表上很有必要不然用户查看积分明细时会越来越慢。4. 实操过程与前后端实现4.1 开发环境准备环境准备这一步看似简单实际上我见过太多人卡在这里。推荐一套稳妥的组合Python 3.10不要用 3.12 以下太老的版本Django 新版本需要 Python 3.10 支持Django 4.2 LTS 或 5.xLTS 版本更稳插件兼容更好djangorestframework、djangorestframework-simplejwt做 JWT 登录django-cors-headers解决跨域问题mysqlclient 或 pymysql如果使用 MySQL 8推荐 mysqlclientSQLite 开发阶段也够用前端Node.js 18Vite 创建 Vue 3 项目创建项目基本命令# 后端 python -m venv venv source venv/bin/activate # Windows 是 venv\Scripts\activate pip install django djangorestframework djangorestframework-simplejwt django-cors-headers django-admin startproject config . python manage.py startapp users python manage.py startapp goods python manage.py startapp orders python manage.py startapp points # 前端 npm create vitelatest frontend -- --template vue cd frontend npm install npm install vue-router4 pinia axios注意Django 项目结构里我特意用了config作为配置目录名而不是默认的snack_platform这样更清晰避免和项目根目录重名混淆。4.2 后端核心实现用户认证模块。使用 Djangorestframework-simplejwt 做 JWT 认证。用户注册接口只需要序列化器里带username、password、confirm_password、phone密码用make_password加密保存。登录接口用 Django 自带的authenticate校验成功后返回 access 和 refresh token。一个关键配置是SIMPLE_JWT的设置from datetime import timedelta SIMPLE_JWT { ACCESS_TOKEN_LIFETIME: timedelta(days1), REFRESH_TOKEN_LIFETIME: timedelta(days7), AUTH_HEADER_TYPES: (Bearer,), }商品接口。商品列表接口需要支持分类筛选、关键词搜索、分页、排序。DRF 的过滤器django_filters可以省不少代码但如果只想用 DRF 自带功能手动在get_queryset里加条件也不复杂。注意积分兑换商品需要额外返回points_price和is_points_exchange_only字段前端商品卡片上要能区分“¥”和“积分”两种标识。购物车接口。增删改查各一个接口数量变更时校验库存上限。一个容易忽视的问题添加购物车时如果该项目已经禁售或库存为 0要返回明确错误信息而不是静默失败。订单创建。这是业务逻辑最重的接口。下单时传入一个商品 ID 与数量的数组后端要做以下事项校验所有商品存在且在售校验库存是否充足计算总金额校验用户是否使用积分抵扣如果使用调用扣积分逻辑创建订单主表和订单明细表使用外层事务包起来返回订单号和前端需要继续支付的参数。支付逻辑。实际场景中接入第三方支付需要商户资质毕设项目里一般用“模拟支付”就好。用户点击“模拟支付”后端把订单状态从待付款改为已付款并记录支付时间。如果要更真实一点可以做一个简单的余额支付或虚拟钱包用户先充值然后下单时用余额支付。这也能顺带做一个“钱包充值”模块扩展性更好。积分流水接口。返回当前用户的所有积分变动记录按时间倒序分页返回。流水查询时要注意不要把balance_after字段暴露成可写字段。4.3 前端核心实现项目初始化与路由设计。前端页面至少需要这些路由/首页展示轮播图、推荐零食、分类导航/goods商品列表页支持分类筛选与搜索/goods/:id商品详情页含加入购物车按钮/cart购物车页支持勾选、数量修改、删除/checkout结算页支持积分抵扣选项展示实付金额/orders订单列表页按状态分 tab/points积分明细页/login和/register登录注册页/admin后台管理页或独立管理端Axios 请求封装。把带 token 的请求统一封到一个request.js里利用 axios 拦截器// request.js import axios from axios; import { useUserStore } from /store/user; const request axios.create({ baseURL: import.meta.env.VITE_API_BASE_URL || /api, timeout: 15000, }); request.interceptors.request.use((config) { const userStore useUserStore(); if (userStore.token) { config.headers.Authorization Bearer ${userStore.token}; } return config; }); request.interceptors.response.use( (response) response.data, (error) { if (error.response error.response.status 401) { // token 失效跳转登录页 const userStore useUserStore(); userStore.logout(); window.location.href /login; } return Promise.reject(error); } ); export default request;baseURL用环境变量配置开发时通过 Vite 的代理转发/api到后端地址这样既避免跨域问题上线时也只要改环境变量就行。积分条展示与购物车联动。积分条可以用 store 里的全局状态管理用户登录后加载一次购物车结算页再拉一次最新值。用户选择“使用积分抵扣”时前端要实时计算“可抵扣上限”和“实付金额”。计算逻辑要注意后端校验是最终一刀前端只是用户体验。4.4 前后端联调与大版本发布联调阶段最典型的模式是后端用 Django 默认的开发服务器跑在 8000 端口前端 Vite 跑在 5173 端口。Vite 配置代理让前端请求直接打到后端// vite.config.js import { defineConfig } from vite; import vue from vitejs/plugin-vue; export default defineConfig({ plugins: [vue()], server: { port: 5173, proxy: { /api: { target: http://localhost:8000, changeOrigin: true, rewrite: (path) path.replace(/^\/api/, ), }, }, }, });这样一个页面流程就串起来了前端发请求到/api/goods- Vite 代理转发到http://localhost:8000/goods- Django 处理并返回 JSON。开发过程中无非是改一处看一处很有节奏感。4.5 测试用例与上线前的自查清单很多同学到最后交付时才发现前后端接口对不上、字段名不一致这是联调阶段最普遍的痛苦来源。建议在联调前先做一次“接口契约检查”把后端每个接口的返回值字段列成一张表前端开发照着这个表来写页面数据绑定。字段对不上的问题在写表这步就能暴露大半。测试用例至少覆盖以下场景注册、重复用户名注册、登录成功/失败商品列表、分类筛选、搜索无结果加入购物车、修改数量、删除商品下单、库存不足、积分不足、未登录下单积分获取、积分消费、流水记录准确性重复提交订单订单号唯一5. 常见问题与部署经验5.1 联调阶段的高频问题速查表问题现象排查方向解决方案前端请求 404代理路径或 URL 不匹配确认 Vite 代理里/api是否自动去掉了前缀对照后端urls.py实际路由前端请求报错 403CSRF 或权限不足DRF 需在REST_FRAMEWORK中配置默认认证类CSRF 在 token 认证下通常不再生效前端能打开页面但拿不到数据CORS 或网络层问题后端安装 django-cors-headers在 settings 配置CORS_ALLOW_ALL_ORIGINS True开发阶段图片上传后无法访问媒体文件路由未配置在urls.py中添加static和media的服务路由积分结算金额对不上Decimal 精度问题全部金额用DecimalField代码中避免float()转换计算用Decimal运算用户退出登录后还能访问订单接口token 过期策略未生效确认前端 axios 请求拦截器里每次都带上了最新 token且接口权限设置为IsAuthenticatedVue 修改数据后页面不更新响应式对象未正确使用Vue 3 中如果使用reactive替换整个对象时请用Object.assign或直接改属性别直接整体赋值5.2 常见业务逻辑坑积分抵扣与优惠的边界。如果订单同时支持满减和积分抵扣系统需要定义“哪个先扣”。推荐规则是先算满减再算积分抵扣最后算实付金额。且积分抵扣金额不能超过实付金额。这个规则在前端和后端必须一致不然会出现“前端显示实付 0 元后端算出负数”的奇葩问题。购物车商品失效。用户加入购物车的商品可能过几天被下架了或者改价了库存变了。购物车接口每次拉数据时要联动查询商品当前状态对失效商品给出明确标识“已失效”不允许继续结算。订单状态复盘。做项目演示时最怕“状态错乱”。我建议 demo 前提前跑几遍完整流程注册 - 逛商品 - 加购 - 下单 - 模拟支付 - 确认收货 - 查看积分。有条件的把DEBUGTrue开着遇到错误能直接看到堆栈信息。5.3 部署上线的简单方案对于毕设答辩或小范围试运营部署不需要搞得很复杂。一台 2核4G 的服务器配置 MySQL Nginx uWSGI 前端静态文件即可。后端用 uWSGI 跑 Djangopip install uwsgi uwsgi --http :8000 --module config.wsgi --processes 2 --threads 2Nginx 配置两个 server 块一个端口转发到 uWSGI另一个端口托管 Vue 构建后的静态文件并用location /api/代理到后端。server { listen 80; server_name your-domain.com; root /var/www/frontend/dist; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8000; # 后端去掉 /api 前缀 proxy_set_header Host $host; } }注意Vite 构建时如果使用了createWebHistory路由务必在 Nginx 里配置try_files回退到index.html否则刷新页面会 404。这也是部署阶段最容易出的问题。部署后要做一次外网环境回归测试因为本地开发用的是 SQLite线上用了 MySQL表结构虽然一致但字段行为可能略有差异比如大小写敏感、事务隔离级别尽早发现问题比线上暴露强。6. 后续扩展与个人实践心得我实际做过类似项目之后最深的体会是整个系统最难的部分不是某个单独技术点而是“积分规则”和“订单状态机”这两条业务逻辑线的交织。代码本身不复杂但逻辑分支特别多稍一疏忽就会出现“积分发了但订单没完成”或者“订单退款但积分没扣回”这种账实不符的尴尬。说几个我个人认为值得融入项目里的加分项积分明细页加一个“来源/去向”图标用户能清楚看到每一笔积分是买东西返的还是兑换商品花的。这个事情在数据库层面只要source_type和source_id查一下就能显示但对用户体验的提升却很直接。后台加分一个“积分规则配置”页面让管理员可以在后台直接修改返积分比例、最低兑换门槛等参数而不是改代码。这个需求只要新增一张配置表然后在返积分逻辑中读取配置即可工作量不大但显得系统很完整。如果想更进一步可以在订单完成后自动生成一张 PDF 电子小票或者做一个“零食热度榜”的推荐位。这些功能不会破坏核心流程但会让演示效果明显上一个档次。对于正在做毕设或者新入行的朋友我给的建议是先跑通最核心的闭环商品 - 购物车 - 订单 - 积分再往周边拓展能力。千万别一上来就铺开做权限管理、多角色、消息通知这些锦上添花的功能否则很容易在主干还没走通时先被枝枝叶叶耗尽心力。前后端分离的项目联调沟通成本本来就高如果把每一步都留出“验证接口返回数据是否正确”的时间最后整合阶段会顺畅很多。
知识建站
内容驱动
阅读友好版式
SEO 精细化
线索转化