企业官网建设流程全解析

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 支持更友好，即使你不写 TS，Pinia 的 store 定义方式也更简单，没有那么多 mutation、getters 的概念负担。简单说，Vuex 是在给你立规矩，Pinia 是在帮你省事。

2.2 后端选型：Django 还是 Flask？

题目把两个都写上，其实是最容易纠结的地方。我的建议是：如果是毕设或课设，无脑选 Django；如果是想快速做一个内部 Demo 且后援较少，选 Flask 也完全可以。

Django 的优势在于“全家桶”。用户认证、Admin 后台、ORM、数据库迁移、表单校验、安全防护这些全都是内置的。尤其 Admin 后台这个功能，对管理端开发简直是降维打击，零食上架、库存修改、订单查看这些后台功能，你完全可以在 Django Admin 里先做一版，然后再开发自定义管理页，相当于买一送一。配合 Django REST Framework（DRF），写 API 的效率非常高：Serializer 自动处理数据校验与序列化，ViewSet + Router 能省掉一大半路由和视图代码。

Flask 的优势在于“轻”和“自由”。如果项目规模不大，Flask 用 Flask-SQLAlchemy + Flask-Migrate + Flask-RESTful 也能拼出一套完整后端。而且 Flask 的代码逻辑更直白，想怎么组织就怎么组织，对有些人来说反而更容易看懂。但它需要你手动集成的组件更多，安全防护也要自己做，到后期反而容易踩坑。

用表格做个对比：

如果你已经会 Flask 且项目不大，用 Flask 没有任何问题。但如果是从零开始，我更推荐 Django，因为它的“约束”反而能帮你少犯错误。

2.3 积分制设计的核心逻辑

积分制是整个平台区别于普通电商的点，也是最容易在设计阶段被忽略的部分。

基本积分规则一般包含三类：

1. 获取积分：用户下单且订单完成后，按订单实付金额比例获取积分，比如消费 1 元得 1 积分，或者消费 10 元得 1 积分。这个比例根据你的利润空间定，我见过多数项目用 1:1，也就是花 1 块钱得 1 积分。
2. 消耗积分：积分可以兑换指定商品，也可以按比例抵扣订单金额。常见的设计是“100 积分 = 1 元”作为抵扣，或者设置一个“积分专区”只能通过积分兑换。
3. 积分成熟/过期：很多系统会给积分设置有效期，比如“积分自获取日起一年内有效”，到期自动清零。这个策略会增加实现复杂度，如果需要做，务必在数据库里加过期时间字段，并设计定时任务处理。

数据建模这里有一个非常重要的点：积分数值不能只存在 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 数据表结构设计

数据库设计讲究“先画表，再写代码”。根据业务需求，我至少会拆出以下八张核心表，每张表的字段都有明确的业务含义：

用户表（User）：Django 自带 AbstractUser 可以直接继承扩展，增加phone（手机号）、avatar（头像 URL）、points_balance（当前积分数），注册时默认积分为 0。

商品分类表（Category）：name、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字段很关键，它能让积分兑换商品和普通商品共用一张表，不用单独建积分商城。

购物车表（CartItem）：user外键、goods外键、quantity、selected（是否勾选）、created_at。购物车表设计成“每个用户每件商品一条记录，数量累计”，这样更新数量时逻辑更简单。

订单表（Order）：order_no（唯一订单号）、user、total_amount（订单总金额）、discount_amount（优惠抵扣金额）、pay_amount（实付金额）、points_used（使用的积分数）、points_earned（可获得积分数）、status（待付款/已付款/待发货/已完成/已取消）、created_at、pay_time等。

订单明细表（OrderItem）：order外键、goods外键、goods_name（下单时的商品名快照）、price（下单单价快照）、quantity。为什么要做“快照”？因为商品名称和价格随时可能被后台修改，而订单作为交易凭证，必须保留下单那一刻的信息，不能用外键去实时查，否则会出大问题。

积分流水表（PointRecord）：user、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(pk=user.pk) if user.points_balance < amount: raise ValueError("积分不足") user.points_balance -= amount user.save(update_fields=["points_balance"]) PointRecord.objects.create( user=user, change_type=-1, change_value=amount, source_type=source_type, source_id=source_id, balance_after=user.points_balance, remark=remark, )

同理，商品库存扣减也可以用select_for_update锁定库存行，或者用F()表达式做原子的减法操作：

from django.db.models import F result = Goods.objects.filter(pk=goods_id, stock__gte=quantity).update( stock=F("stock") - quantity, sales_count=F("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_digits=10, decimal_places=2)是标准做法。
• 订单号生成。不要用自增 ID 直接当订单号，太容易被人猜到业务量。可以拼规则：时间戳 + 随机数 + 用户ID后几位，比如2025031214352208123456。记得加唯一索引。
• 软删除 vs 硬删除。商品删除建议用is_active或status字段标记，不要物理删除，否则历史订单里的关联关系会断掉。
• 数据库索引。user+created_at的组合索引在积分流水表和订单表上很有必要，不然用户查看积分明细时会越来越慢。

4. 实操过程与前后端实现

4.1 开发环境准备

环境准备这一步看似简单，实际上我见过太多人卡在这里。推荐一套稳妥的组合：

• Python 3.10+（不要用 3.12 以下太老的版本，Django 新版本需要 Python 3.10+ 支持）
• Django 4.2 LTS 或 5.x（LTS 版本更稳，插件兼容更好）
• djangorestframework、djangorestframework-simplejwt（做 JWT 登录）
• django-cors-headers（解决跨域问题）
• mysqlclient 或 pymysql（如果使用 MySQL 8，推荐 mysqlclient；SQLite 开发阶段也够用）
• 前端：Node.js 18+，Vite 创建 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 vite@latest frontend -- --template vue cd frontend npm install npm install vue-router@4 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(days=1), "REFRESH_TOKEN_LIFETIME": timedelta(days=7), "AUTH_HEADER_TYPES": ("Bearer",), }

商品接口。商品列表接口需要支持分类筛选、关键词搜索、分页、排序。DRF 的过滤器django_filters可以省不少代码，但如果只想用 DRF 自带功能，手动在get_queryset里加条件也不复杂。注意积分兑换商品需要额外返回points_price和is_points_exchange_only字段，前端商品卡片上要能区分“¥”和“积分”两种标识。

购物车接口。增删改查各一个接口，数量变更时校验库存上限。一个容易忽视的问题：添加购物车时，如果该项目已经禁售或库存为 0，要返回明确错误信息，而不是静默失败。

订单创建。这是业务逻辑最重的接口。下单时传入一个商品 ID 与数量的数组，后端要做以下事项：

1. 校验所有商品存在且在售；
2. 校验库存是否充足；
3. 计算总金额；
4. 校验用户是否使用积分抵扣，如果使用，调用扣积分逻辑；
5. 创建订单主表和订单明细表，使用外层事务包起来；
6. 返回订单号和前端需要继续支付的参数。

支付逻辑。实际场景中接入第三方支付需要商户资质，毕设项目里一般用“模拟支付”就好。用户点击“模拟支付”，后端把订单状态从待付款改为已付款，并记录支付时间。如果要更真实一点，可以做一个简单的余额支付或虚拟钱包，用户先充值，然后下单时用余额支付。这也能顺带做一个“钱包充值”模块，扩展性更好。

积分流水接口。返回当前用户的所有积分变动记录，按时间倒序，分页返回。流水查询时要注意不要把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 联调阶段的高频问题速查表

5.2 常见业务逻辑坑

积分抵扣与优惠的边界。如果订单同时支持满减和积分抵扣，系统需要定义“哪个先扣”。推荐规则是：先算满减，再算积分抵扣，最后算实付金额。且积分抵扣金额不能超过实付金额。这个规则在前端和后端必须一致，不然会出现“前端显示实付 0 元，后端算出负数”的奇葩问题。

购物车商品失效。用户加入购物车的商品，可能过几天被下架了，或者改价了，库存变了。购物车接口每次拉数据时，要联动查询商品当前状态，对失效商品给出明确标识“已失效”，不允许继续结算。

订单状态复盘。做项目演示时，最怕“状态错乱”。我建议 demo 前提前跑几遍完整流程：注册 -> 逛商品 -> 加购 -> 下单 -> 模拟支付 -> 确认收货 -> 查看积分。有条件的把DEBUG=True开着，遇到错误能直接看到堆栈信息。

5.3 部署上线的简单方案

对于毕设答辩或小范围试运营，部署不需要搞得很复杂。一台 2核4G 的服务器，配置 MySQL + Nginx + uWSGI + 前端静态文件即可。

后端用 uWSGI 跑 Django：

pip install uwsgi uwsgi --http :8000 --module config.wsgi --processes 2 --threads 2

Nginx 配置两个 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 电子小票，或者做一个“零食热度榜”的推荐位。这些功能不会破坏核心流程，但会让演示效果明显上一个档次。

对于正在做毕设或者新入行的朋友，我给的建议是：先跑通最核心的闭环（商品 -> 购物车 -> 订单 -> 积分），再往周边拓展能力。千万别一上来就铺开做权限管理、多角色、消息通知这些锦上添花的功能，否则很容易在主干还没走通时，先被枝枝叶叶耗尽心力。前后端分离的项目，联调沟通成本本来就高，如果把每一步都留出“验证接口返回数据是否正确”的时间，最后整合阶段会顺畅很多。