基于 FastAPI 与 Vue 3 的校园食堂点餐推荐系统技术研究

校园食堂是高校生活中非常典型的高频场景。每天中午和晚上，学生集中到食堂就餐，常常会遇到排队时间长、菜品信息不透明、窗口选择困难、热门菜品售罄后才发现、以及学生不知道吃什么等问题。

从食堂管理方的角度看，也存在另一个问题：窗口很难及时了解学生的真实偏好。哪些菜品更受欢迎？哪些分类更容易被收藏？哪些时间段订单更集中？如果缺少系统化的数据记录，这些问题往往只能依靠人工经验判断。

因此，本项目以“校园食堂点餐与推荐系统”为研究对象，尝试使用 Python 全栈技术实现一个可运行的原型系统。系统支持学生注册登录、浏览菜品、搜索筛选、收藏菜品、加入购物车、提交订单，并根据历史订单与收藏偏好生成个性化推荐结果。

这个项目并不是单纯展示页面，而是围绕一个真实业务场景，完整串联了后端接口、数据库建模、认证鉴权、订单逻辑、推荐策略、前后端通信和页面交互等核心环节。对于学习 Python 全栈开发、FastAPI 接口设计、Vue 前端开发，以及课程设计类项目，都具有较强的参考价值。

一、项目研究背景

传统校园食堂的信息展示方式通常比较分散。学生需要到现场查看窗口菜单，或者通过群消息、公告牌、图片等方式了解当天菜品。这样的方式存在几个明显问题。

第一，信息更新不及时。菜品是否售罄、价格是否变化、窗口是否还在营业，学生往往无法提前获知。

第二，选择成本较高。学生每天都要面对“吃什么”的问题，如果没有搜索、分类和推荐功能，只能凭记忆或现场排队情况做选择。

第三，用户偏好无法沉淀。学生经常点什么、收藏什么、偏好哪类菜品，这些数据如果没有被记录，就无法进一步用于推荐或食堂运营分析。

第四，食堂窗口缺少反馈机制。哪些菜品受欢迎，哪些菜品复购率高，哪些窗口下单量大，都需要通过系统数据来支撑。

基于这些问题，本项目设计了一个校园食堂点餐与推荐系统。它既可以看作一个校园信息化应用，也可以看作一个小型电商系统的简化版本。系统中包含用户、菜品、收藏、购物车、订单、推荐、统计等模块，具备较完整的业务闭环。

二、整体技术方案

本项目采用前后端分离架构。

后端使用 FastAPI 构建 REST API。FastAPI 具有接口开发效率高、性能较好、自动生成接口文档等特点，适合快速开发课程设计、原型系统和中小型 Web 服务。

数据库使用 SQLite。SQLite 是轻量级本地数据库，不需要单独部署数据库服务，适合学习项目、单机应用和教学演示场景。通过 SQLite，可以保存用户信息、菜品信息、订单信息、订单明细和收藏记录。

ORM 层使用 SQLAlchemy。SQLAlchemy 负责将数据库表映射为 Python 对象，使开发者可以通过对象操作数据库，而不需要在业务代码中频繁编写原始 SQL。

数据校验使用 Pydantic。它主要用于定义请求体和响应结构，保证前后端传输的数据格式清晰、稳定，也方便后续维护接口文档。

认证鉴权部分使用 Passlib 和 PyJWT。Passlib 用于密码哈希，避免明文密码直接存入数据库；PyJWT 用于生成登录 token，使前端可以在后续请求中携带身份凭证，访问需要登录的接口。

前端使用 Vue 3 和 Vite。Vue 3 负责组件化页面开发，Vite 提供快速开发和热更新能力。前端通过 Fetch API 与后端进行 JSON 数据交互。

整体来看，这套技术栈比较轻量，但功能完整，适合学生项目、课程设计、毕业设计原型，以及中小型后台系统的入门实践。

三、系统架构设计

系统整体可以分为浏览器前端、后端 API 服务和数据库三层。

用户在浏览器中访问 Vue 3 页面。页面负责展示登录注册界面、菜品列表、推荐菜品、购物车、订单记录和统计信息。当用户进行登录、搜索、收藏、下单等操作时，前端会通过 HTTP 请求访问后端接口。

后端 FastAPI 服务负责处理业务逻辑。它接收前端传来的请求，完成参数校验、权限校验、数据库查询、订单创建、库存扣减、推荐结果生成等操作，并将结果以 JSON 格式返回给前端。

数据库 SQLite 用于持久化保存数据。用户信息、菜品数据、收藏记录、订单主表和订单明细都会存储在数据库中。系统启动时可以自动创建数据表，并初始化示例菜品，方便快速体验完整流程。

在后端代码组织上，可以将不同职责拆分到多个文件中。例如，认证相关逻辑放在 security 模块中，数据模型放在 models 模块中，请求和响应结构放在 schemas 模块中，业务逻辑放在 crud 模块中，接口入口放在 main 模块中。这样的拆分方式可以降低代码耦合度，也方便后续继续扩展功能。

系统中除注册、登录和健康检查接口外，大部分核心接口都需要登录后才能访问。前端登录成功后会保存 token，后续请求自动带上认证信息。后端解析 token 后确认用户身份，再决定是否允许访问对应资源。

四、核心功能模块分析

从业务角度看，系统主要由七类功能模块组成。

第一类是用户模块。用户可以注册账号、登录系统、获取当前用户信息，也可以退出登录。用户身份是后续下单、收藏和推荐的基础。

第二类是认证模块。用户注册或登录后，系统会生成一个 token。前端请求受保护接口时，需要携带这个 token。后端通过解析 token 判断当前请求属于哪个用户。密码不会以明文形式保存，而是经过哈希处理后写入数据库，这也是实际系统中必须重视的安全设计。

第三类是菜品模块。学生可以查看菜品列表，并按照关键词或分类进行搜索筛选。菜品信息包括名称、窗口、分类、标签、价格、库存、评分等。这个模块对应真实食堂中的菜单展示功能。

第四类是收藏模块。学生可以收藏自己感兴趣的菜品，也可以取消收藏。收藏行为不仅是用户体验功能，也可以作为推荐系统的数据来源。比如用户经常收藏轻食类菜品，系统就可以推断该用户可能偏好低脂、健康类菜品。

第五类是购物车与订单模块。用户可以把菜品加入购物车，确认数量和总价后提交订单。提交订单时，后端需要校验菜品是否存在、是否上架、库存是否充足。校验通过后，系统扣减库存并生成订单记录。订单采用主从表结构，一个订单可以包含多个菜品明细，这样更接近真实电商系统或点餐系统的设计。

第六类是推荐模块。推荐逻辑主要基于用户的历史订单和收藏记录。系统会统计用户常点或常收藏的菜品分类，然后优先推荐该分类下评分较高的菜品。如果是新用户，系统可以推荐全站评分较高的菜品。虽然这个推荐策略比较简单，但已经具备了个性化推荐的基本思想。

第七类是统计模块。系统可以展示菜品数量、订单数量、收藏数量、累计消费金额等数据。这些数据既可以用于学生个人中心，也可以扩展为食堂运营后台的数据看板。

五、数据库模型设计思路

本项目的数据库设计围绕点餐业务展开，核心数据包括用户、菜品、订单、订单明细和收藏。

用户表用于保存账号信息，包括用户名、邮箱、加密后的密码、角色和创建时间。角色字段可以为后续扩展管理员、食堂窗口工作人员等身份预留空间。

菜品表用于保存食堂菜品信息，包括菜品名称、所在窗口、分类、标签、价格、库存、评分和是否上架等。分类可以用于搜索筛选，也可以用于推荐策略。标签则可以描述菜品特点，例如清淡、麻辣、低脂、高蛋白等。

订单主表用于保存一次下单行为的整体信息，包括下单用户、取餐时间、订单状态和订单总金额。订单状态可以继续扩展为待取餐、已完成、已取消等。

订单明细表用于保存订单中的具体菜品。一个订单可以包含多个菜品，每个明细记录对应一个菜品、数量和下单时单价。之所以需要订单明细表，是因为订单和菜品之间是典型的一对多关系，不能简单地把所有菜品信息塞进订单主表中。

收藏表用于记录用户和菜品之间的收藏关系。一个用户可以收藏多个菜品，一个菜品也可以被多个用户收藏，因此收藏表本质上是用户和菜品之间的关联表。

这种数据库设计虽然不复杂，但已经覆盖了 Web 应用中常见的数据建模方式，包括用户表、业务主表、业务明细表和关联表。对于学习数据库设计非常有代表性。

六、后端接口设计研究

后端接口设计遵循 REST API 思路，通过不同地址和请求方法表达不同业务操作。

健康检查接口用于确认服务是否正常运行。注册接口用于创建用户并返回登录凭证。登录接口用于校验账号密码，并签发 token。当前用户接口用于获取登录用户信息。

菜品接口用于获取菜品列表，支持搜索和分类筛选。管理员新增菜品接口可以作为后续后台管理功能的基础。推荐接口用于根据用户行为返回推荐菜品。订单接口用于创建订单和查询个人历史订单。收藏接口用于收藏或取消收藏指定菜品。首页统计接口用于返回菜品、订单、收藏和消费等汇总数据。

在接口权限设计上，注册、登录和健康检查不需要登录，因为它们是系统入口。菜品查询、推荐、收藏、下单、订单查询和统计等接口都需要登录，因为这些操作与具体用户身份相关。

后端在处理受保护接口时，会先解析前端传来的 Bearer token，从 token 中获取用户名，再到数据库中查询用户是否存在。如果用户不存在或 token 无效，接口会返回未授权错误。通过这种方式，可以避免未登录用户直接访问个人数据或创建订单。

七、前端页面交互设计

前端页面采用 Vue 3 单文件组件组织。整体交互可以分为登录前和登录后两种状态。

未登录时，页面主要展示登录和注册卡片。用户可以输入用户名、邮箱和密码完成注册，也可以使用已有账号登录。登录成功后，前端保存 token，并切换到系统主界面。

登录后，顶部用户栏会展示当前用户名和退出按钮。用户可以在主界面查看统计卡片，包括菜品数量、订单数量、收藏数量和累计消费金额。

智能推荐区用于展示系统推荐的菜品，并说明推荐原因。例如，系统可能提示“根据你常点的轻食分类推荐”。这种推荐说明能够增强用户对系统逻辑的理解，也比单纯展示菜品列表更有体验感。

菜品列表区是系统的核心操作区域。用户可以输入关键词搜索菜品，也可以按分类筛选。每个菜品可以加入购物车，也可以收藏或取消收藏。

购物车区展示已选菜品、数量、总价和提交订单按钮。用户加入同一道菜时，系统会自动合并数量，而不是重复生成多条记录。总价会根据购物车内容实时计算。

我的订单区用于查看历史订单，包括订单状态、取餐时间、总金额和菜品明细。这个功能可以帮助用户确认自己的点餐记录，也为后续推荐策略提供数据基础。

前端还封装了统一的请求方法。每次请求后端接口时，系统会自动添加 JSON 请求头，并在存在 token 的情况下携带认证信息。这样可以避免在每个接口调用处重复编写认证逻辑。

八、核心业务逻辑分析

在整个系统中，有几个业务逻辑值得重点关注。

首先是密码安全。系统不会直接保存用户输入的原始密码，而是对密码进行哈希处理后再存入数据库。登录时，系统会将用户输入的密码与数据库中的哈希值进行校验。这样即使数据库泄露，也能降低明文密码暴露的风险。

其次是 token 认证。用户登录成功后，系统生成 JWT token。前端保存 token，后续请求通过请求头携带 token。后端根据 token 判断用户身份。这种方式适合前后端分离项目，也是很多 Web 系统中常见的认证方案。

第三是下单逻辑。下单并不是简单写入一条订单记录，而是需要完成多步校验。系统需要确认菜品存在、菜品处于上架状态、库存数量足够。如果库存不足，就不能创建订单。校验通过后，系统扣减库存，计算订单总价，生成订单主表和订单明细。这个流程体现了业务一致性的重要性。

第四是推荐策略。系统会优先分析用户历史订单和收藏记录中的菜品分类。如果用户经常购买或收藏某一类菜品，系统就认为该分类是用户偏好，并推荐该分类下评分较高的菜品。对于没有历史行为的新用户，则推荐全站评分较高的菜品。虽然该策略还不是复杂的机器学习推荐算法，但已经能够体现“基于用户行为的个性化推荐”思想。

第五是前端购物车状态管理。购物车保存在前端响应式数据中。用户点击加入购物车时，如果该菜品已经存在，就增加数量；如果不存在，就新增一条购物车记录。总价通过计算属性自动生成。这个设计体现了 Vue 响应式系统在交互页面中的优势。

九、项目运行与体验流程

从运行流程看，系统可以分为后端启动、前端启动和用户体验三个阶段。

后端启动后，会创建数据库表，并初始化示例菜品。开发环境下，后端服务通常运行在本地 8000 端口，同时可以通过自动生成的接口文档查看和测试接口。

前端启动后，浏览器访问前端页面。前端默认会请求后端接口，如果后端地址发生变化，可以通过环境变量进行配置。

用户体验流程比较清晰。首先注册一个学生账号，然后登录系统。登录后浏览菜品列表，可以通过关键词搜索或分类筛选菜品。遇到感兴趣的菜品，可以点击收藏。准备点餐时，将菜品加入购物车，确认数量和价格后提交订单。完成订单后，再刷新推荐区域，可以观察推荐原因是否因为历史订单和收藏行为发生变化。

这个体验流程覆盖了从账号注册到数据沉淀，再到推荐反馈的完整闭环。

十、项目价值与扩展方向

这个校园食堂点餐与推荐系统的价值在于，它不是一个孤立的功能演示，而是将多个真实业务模块组合成了一个完整应用。

从后端角度看，项目覆盖了接口设计、数据库建模、认证鉴权、业务校验、订单处理和推荐逻辑。

从前端角度看，项目覆盖了登录状态管理、接口封装、条件渲染、搜索筛选、购物车交互、订单展示和推荐展示。

从业务角度看，项目模拟了一个校园场景中的真实需求，包括学生点餐、菜品展示、偏好记录、订单生成和数据统计。

与普通 CRUD 项目相比，它增加了订单明细、库存扣减、收藏偏好和推荐策略，因此更贴近真实系统开发。对于学习全栈开发的人来说，这类项目比单纯的增删改查更有训练价值。

后续可以继续扩展多个方向。

例如，可以增加管理员菜品管理后台，让食堂管理员维护菜品、价格、库存和上下架状态。

可以增加食堂窗口接单端，让窗口工作人员查看订单、确认备餐、修改订单状态。

可以增加在线支付功能，模拟完整交易流程。

可以增加排队号和取餐码，减少线下拥堵。

可以增加营养分析模块，根据菜品热量、蛋白质、脂肪、碳水等信息，为学生提供饮食建议。

可以继续升级推荐算法，从简单的分类推荐扩展到协同过滤、相似用户推荐、热门趋势推荐等。

还可以增加订单评价和消息通知功能，让系统形成更完整的反馈闭环。

十一、总结

校园食堂点餐与推荐系统是一个非常适合技术研究和课程实践的全栈项目。它的业务场景真实，功能边界清晰，技术栈轻量，开发成本可控，同时又能覆盖 Web 系统开发中的关键知识点。

通过这个项目，可以系统理解 FastAPI 如何构建后端接口，SQLite 和 SQLAlchemy 如何完成数据持久化，Pydantic 如何进行数据校验，JWT 如何完成登录鉴权，Vue 3 如何构建交互式前端页面，以及前后端如何通过 JSON 接口协同工作。

更重要的是，这个项目体现了从“功能实现”到“业务闭环”的思维转变。一个好的全栈项目，不只是把页面做出来、把接口调通，而是要围绕真实问题建立数据流、业务流和用户体验流。

从这个角度看，校园食堂点餐与推荐系统虽然规模不大，但具备完整应用的雏形。它既可以作为 Python 全栈学习项目，也可以作为毕业设计、课程设计或校园信息化系统原型继续深化。