第一章 绪论
1.1 研究背景与意义
1.1.1 研究背景
全民健康意识不断被唤醒，数字技术也深入到人们的生活中，正在改变着人们管理个人健康的途径。国家相继出台过《全民健身计划》、《健康中国2030规划纲要》等政策文件，把全民健身和营养健康纳入国家战略体系之中，又加强了社会对于运动管理和饮食干预服务的需求1。传统的健康管理模式依靠纸质记录或者分散的单一功能应用，用户要到各个平台之间来回切换，运动数据和饮食数据没有关联分析，营养评估也很难根据个人健康状况来实现定制化的输出，整体管理效率低2。移动互联网的普及使用户对于实时性的、个性化的健康管理服务的期望值不断上升，市场上现有的健身类或者饮食类应用大多只关注单一维度，很少有系统可以把运动记录、饮食追踪、营养配餐、健康报告以及社交互动整合到同一个平台上一起运行。JavaWeb技术栈成熟发展，尤其是Spring Boot框架在企业级应用开发中表现出的高效、稳定特性，给创建功能齐全的综合健康管理系统打下了良好的技术根基3。在此情况下，设计出一个可以打通运动和饮食两个主要方面，支持多角色协同操作的全民健身与饮食健康管理系统，有现实的必要性以及紧迫性。
1.1.2 研究意义
全民健身和饮食健康管理系统的建立，可以使分散在各个渠道里的运动数据、饮食记录、营养分析等信息汇聚到同一个平台上，有效地减轻用户的管理成本以及操作负担。系统把用户的营养配餐、健康报告等历史行为数据转化成可以参考的健康建议，从而实质性地提高了个人健康决策的科学性。社交互动模块加入之后，就打破了传统健康管理应用的封闭状态，用户之间互相交流、彼此鼓励产生持久的健康行为驱动力。健康商城模块把健康服务延伸到商品消费场景，完善平台商业闭环的同时也给用户提供更加便捷的健康产品获取途径。从行业角度来说，本系统的设计思想和技术实现方式对于同类综合健康管理平台的创建有着一定的借鉴意义，有利于推进全民健身数字化服务系统更加完善。
1.2 国内外研究现状
1.2.1 国内现状
国内健身和饮食健康管理类系统研究开始得比较早，是从单一的功能管理工具发展为综合性平台的过程。早期系统主要集中在会员信息登记或者简单的运动课程排期上，数据孤岛现象比较严重；近些年来由于微服务架构的推广以及前后端分离开发模式的成熟，国内有关系统的功能整合度和技术架构方面都有了明显的改善。
朱敏等2024年利用Spring Boot结合SSM框架构建了健身管理平台，包含教练员管理、会员管理、健身课程体系管理等功能模块，采用微服务架构使得各个模块之间的耦合度大大降低，模块化拆分思路给本系统多角色功能分区设计提供直接借鉴4。毕岚岚等人在2019年以微服务架构为基础完善了健身管理平台的整体设计，使用Spring Cloud技术加强了服务之间的协作能力，各个微服务功能模块可以稳定地协同工作，他们的业务建模方法给本系统业务建模提供了很好的借鉴5。张新宇在2023年研究开发了基于知识图谱的健康饮食推荐系统。该研究针对以往单纯考虑饮食偏好而忽略个人健康信息的问题，提出将包含丰富知识的健康饮食领域知识图谱与用户个人的实际情况进行有效结合。这种将专业健康知识与用户动态数据相融合的思路，为本系统中营养配餐模块的个性化与科学化设计提供了有益的理论借鉴6。
1.2.2 国外现状
国外有关健身和饮食健康管理方面的研究大体上是数据驱动的、智能化的、多终端的。可穿戴设备和移动应用的深度融合使用户生理数据的采集粒度越来越细，研究者也越来越重视怎样把大量的用户行为数据转化为个性化的健康干预方案。
2025年Sara Sweidan等人提出了一种基于机器学习技术的混合健康饮食推荐系统，使用SVR、LR、DTR等回归模型对用户的生理测量数据进行分析，可以得到高精度的卡路里需求估计值，把机器学习应用到饮食规划建模上，给本系统营养配餐模块的设计提供了一个思路7。2024年，Tingting Zhao提出基于梯度概率自动推荐系统的体能测试数据分析与训练计划推荐方法，把机器学习和个性化健身方案生成结合起来，训练数据采集和推荐逻辑设计为本系统运动记录和健康报告的联动机制提供了一些思路8。2023年Haoran Sun等人的研究工作主要围绕Android平台展开，他们创建了智能健身系统，并且使用了SVM算法以及BP神经网络来对健身动作加以识别和计数，系统的测试结果表明移动端传感器的数据可以被用作健身动作识别的依据，该系统的交互方式给本系统运动记录模块的交互设计提供了一定的参考9。2023年Dhanasekaran Seshathiri等人提出一种促进体力活动数据采集与分析的方案协议，研究活动追踪器、情境感知推送等技术对于健康行为改变的影响，用户动机及技术接受度研究给本系统社交互动模块设计逻辑提供理论支持10。
国外的研究在算法智能化以及数据科学的应用上已经比较成熟，但是大多数的研究都只注重某个技术方向上的深入研究，缺少对于运动、饮食、社交、商城等各个方面的业务场景进行系统的整合。本系统在借鉴国外研究的数据驱动、个性化服务理念的基础上，把功能重心放在了多角色业务协同和全流程健康管理闭环的工程实现上，更符合我国用户实际使用场景。
1.3 主要研究内容
本文的主要工作就是用Spring Boot框架设计出一个面向全民健身和饮食健康管理的综合性JavaWeb系统。研究工作从需求分析阶段开始，对普通用户和管理员两种角色的业务行为进行梳理，确定系统在社交互动、饮食记录、运动管理、营养配餐、健康报告、健康商城等各个方面的功能边界以及数据交互规则。在需求明确之后，研究进入到架构设计阶段，主要针对前后端分离模式来规划系统的架构技术分层结构，确定Spring Boot做接口服务、Vue做前端渲染、MySQL做业务数据存储的总体技术路线，并且对各个核心业务模块的功能结构进行拆解，同时对数据库逻辑进行建模。模块实现阶段包含用户侧的所有主要功能页面和管理员侧的后台管理功能，有食物信息的维护、运动信息的管理、营养配餐方案的AI辅助生成以及订单物流的追踪。数据库设计层面完成概念模型的E-R建模和逻辑模型的表结构细化，保证数据关系的完整性、一致性。测试阶段采用功能测试用例来检验各个模块的业务逻辑是否正确。本研究主要进行系统的工程化设计和完整的实现，算法层面的智能优化不在本次研究范围内，最终交付成果为可以运行的系统原型以及配套的设计文档，整个研究过程按照软件工程的标准开发流程来进行。
第二章 相关技术介绍
2.1 Spring Boot框架
Spring Boot是Pivotal团队基于Spring框架开发出来的快速应用构建工具，它的主要设计理念就是采用约定优于配置的方式，把繁杂的XML配置工作变成自动装配机制，从而让开发者只需要很少的配置代码就可以启动一个具备生产能力的Web服务。框架自带的嵌入式Servlet容器使应用无需依赖于外部的服务器即可独立运行，从而很大程度上简化了部署环境11。
本系统中Spring Boot作为后端服务层的主要角色，用RESTful接口向前端Vue应用发送结构化的数据响应。框架给出的依赖注入机制把业务逻辑层和数据访问层之间的协作关系有效解耦，各个功能模块的Service组件在容器管理下独立运行，互不影响。Spring Boot集成数据访问层抽象可以减少系统与MySQL数据库之间的交互，使系统在处理频繁出现的饮食记录、订单管理和运动数据等高频率业务请求时，依然可以保持稳定的响应速度12。
2.2 Vue前端框架
Vue.js是用于构建用户界面的渐进式JavaScript框架，它的主要特点就是数据驱动的视图更新机制以及组件化的开发方式。框架用虚拟DOM技术来优化页面渲染过程，在数据状态发生变化的时候只对差异部分进行局部重绘，从而使界面响应速度保持在一个较高的水平上。Vue单文件组件规范把模板、逻辑、样式封装在同一个文件中，使代码的可维护性、复用性得到了很大的提高13。
本系统前端全部使用Vue构建，用户界面层的社交互动页面、饮食记录操作界面、健康商城展示页面都是用Vue组件来组织的。系统利用Vue Router来完成单页应用内路由跳转，用户在不同的功能模块之间切换的时候不需要重新加载整个页面，交互的流畅性得到了明显的提高。前端利用Axios给Spring Boot后端发出HTTP请求，从而达成前后端间的数据来回流通，构建起前后端相互配合的链条14。
2.3 MySQL数据库
MySQL是目前使用最广泛的开源的关系型数据库管理系统之一，用结构化查询语言来定义、操作和控制数据。它所支持的事务处理机制可以保证多步业务操作的原子性，在订单创建、库存扣减、支付状态更新等需要多表写入的情况中，数据的一致性得到了可靠的保证15。MySQL的索引机制对于大量的查询请求来说可以大大减少数据检索的路径，满足系统对于高频读写场景的需求。
本系统数据持久化层用MySQL来存储所有的用户账户表、饮食记录表、运动记录表、营养配餐表、商品信息表、订单表、物流配送表等核心业务表。数据库的外键约束和规范化设计保证了各个业务实体之间的关联关系是完整的，给上层业务逻辑的正确运行提供数据支持。系统对于营养配餐查询、健康报告生成等需要进行多表关联的复杂操作，在使用MySQL的联合查询时，可以较快地得到数据聚合结果。
2.4 B/S结构模式
B/S架构就是浏览器/服务器架构模式，它的主要特点是把系统的业务逻辑处理和数据存储功能集中到服务器端，客户端只需要使用标准的浏览器就可以访问系统。这样就极大地减少了系统部署以及后期的维护费用，用户可以使用不同的操作系统终端来访问系统，不需要在这些终端上安装客户端软件。
B/S架构一般采用展示层、业务逻辑层和数据存储层分层的方式，各层之间的职责界线很明确，大大提高了系统的可扩展性和安全性。本全民健身和饮食健康管理系统使用B/S架构，用户通过浏览器就可以方便地进行饮食记录、运动数据录入和健康商城购物，不需要考虑客户端版本更新以及环境适配问题。程煌认为B/S架构可以提高系统的开发效率以及可维护性，特别适合于业务流程繁杂、用户角色众多的企业级应用16。
第三章 系统分析
3.1 可行性分析
3.1.1 技术可行性
本系统使用Spring Boot作为后端框架，Vue作为前端渲染技术，MySQL作为数据持久化技术，三者都是目前业界成熟度高、社区支持好的主流技术。前后端分离架构下各个层的职责边界明确，接口标准统一，技术组合之间兼容性经过大量的工程实践得到充分的验证。开发环境搭建成本低、文档资源丰富，系统所涉及的功能模块都可以在现有的技术框架中稳定实现，整个技术路线具有较高的可行性。
3.1.2 操作可行性
本系统面向普通用户和管理员两种类型，界面交互流程用模块化的方式进行设计，各个功能入口层次分明，操作路径一目了然。普通用户进行饮食记录录入、运动数据提交、订单管理等日常操作的时候，认知负担小，不需要专业技术背景就可以使用。管理员后台界面采用统一的列表、表单操作范式，功能分区清楚，对计算机基础操作有基本了解的管理人员经过短暂熟悉就可以独立完成日常维护工作，系统操作可行性较好。
3.1.3 经济可行性
本系统所用到的Spring Boot、Vue、MySQL都是开源的技术，不需要支付商业授权费用，可以大大减少软件方面的初期投入。系统部署在本地服务器上，运行维护所要求的硬件资源处在正常范围内。就人员投入而言，系统功能模块边界清楚，开发任务可以拆解分工，总体开发周期和人力成本都在可控制范围内。系统建成之后日常维护工作量小，长期运行成本低，总体上建设经济合理。
3.2 功能需求分析
3.2.1 普通用户角色功能需求
普通用户是本系统的重点服务对象，可以完成社交互动、健康资讯浏览、健康商城购物、个人健康数据管理等所有的场景操作。社交模块可以进行内容发布、关键词搜索、点赞、收藏、评论回复等操作；健康资讯模块可以对筛选、检索、浏览商品；商城模块可以浏览商品、购物车管理、地址维护、多种支付方式；个人中心可以对饮食记录、运动记录的增删改查和详情查阅，也可以获取营养配餐推荐方案和健康报告，物流配送状态也可以在个人中心中查询跟踪。普通用户用例图如下图3-1所示。
图3-1普通用户用例图
3.2.2 管理员角色功能需求
管理员对系统后台的数据进行维护和业务管理工作，具有对运动信息、食物信息、饮食记录、营养配餐方案、运动记录的全面管理权限，可以进行增删改查以及图片和文件的上传。营养配餐管理模块把AI配餐生成功能集成进来，管理员可以一键启动智能配餐方案的生成流程。商城管理模块包含商品信息上架下架控制、订单发货操作以及配送详情录入等功能，保证平台商业流程的闭环运转。管理员用例图如图3-2所示。
图3-2管理员用例图
第四章 系统设计
4.1 系统架构设计
本系统采用经典的前后端分离三层架构体系，将用户界面层、应用服务层、数据持久层在职责上清晰分隔。用户界面层由Vue框架构建，负责页面渲染与用户交互响应，通过HTTP协议与后端进行数据通信。应用服务层基于Spring Boot框架运行，内部按照Controller、Service、Mapper的分层结构组织业务逻辑，各层之间通过依赖注入进行协作。数据持久层以MySQL数据库为核心，存储系统全部业务实体数据，并通过MyBatis持久化框架与服务层建立映射关系。系统支持层提供基础运行环境支撑，包括JDK运行环境与本地化的数据库服务配置。各层之间的边界清晰，任一层内部的变更不会直接影响其他层的运行逻辑，整体架构具备较好的可维护性与可扩展性。系统架构图如图4-1所示。
图4-1系统架构图
4.2 系统结构功能设计
本系统围绕全民健身与饮食健康管理的核心业务场景，按照角色划分功能模块。系统服务普通用户与管理员两类角色：普通用户侧功能涵盖社交互动、健康资讯、健康商城、商城管理、个人中心五大模块；管理员侧功能涵盖运动信息管理、食物信息管理、饮食记录管理、营养配餐管理、运动记录管理、商城管理六大模块。各功能模块相互独立，通过统一的后端接口层进行数据交换，共同构成覆盖用户健康生活全周期的综合服务平台。该系统功能结构如图4-2所示。
图4-2系统功能结构图
4.3 业务流程设计
4.3.1 饮食记录添加流程设计
用户进入个人中心的饮食记录模块后，填写食物名称、摄入数量、记录日期等核心信息，系统对填写内容进行完整性校验。校验不通过时，系统提示用户补充必填字段；校验通过后，系统计算摄入热量并将记录写入数据库，最终向用户返回添加成功的反馈。饮食记录添加流程图如图4-3所示。
图4-3饮食记录添加流程图
4.3.2 营养配餐生成流程设计
管理员在营养配餐管理模块触发AI配餐生成操作，系统读取用户的健康状况、饮食习惯、过敏食物、健身目标等个人健康档案信息，并判断档案数据是否完整。档案不完整时返回提示；档案完整时将数据提交至AI配餐生成接口，接口返回配餐方案后系统进行格式化处理并存储至营养配餐表，最终将配餐结果展示给操作方。营养配餐生成流程图如图4-4所示。
图4-4营养配餐生成流程图
4.3.3 健康商城下单流程设计
用户在健康商城浏览商品详情后发起购买操作，系统首先校验商品库存状态。库存不足时提示用户选择其他商品；库存充足时用户选择收货地址并进入支付中心，支付完成后系统生成订单记录并更新商品库存，同时触发物流配送流程的初始化。健康商城下单流程图如图4-5所示。
图4-5健康商城下单流程图
4.3.4 运动记录提交流程设计
用户在个人中心的运动记录模块填写运动名称、运动时长、消耗热量、当前体重等信息后提交，系统对记录内容进行有效性校验。校验失败时返回字段错误提示；校验通过后记录写入数据库，系统同步判断该用户当前周期内的健康报告生成次数是否达到上限，未达到上限时自动触发健康报告生成流程，达到上限则仅保存运动记录。运动记录提交流程图如图4-6所示。
图4-6运动记录提交流程图
4.3.5 订单发货流程设计
管理员在订单管理页面筛选出待发货订单后选择配送方式，填写配送详情信息，系统校验配送信息的完整性。信息不完整时要求补填；信息完整后系统更新订单状态为已配送，同时创建物流配送记录并关联订单号，最终向买家发送配送状态变更通知。订单发货流程图如图4-7所示。
图4-7订单发货流程图
4.4 数据库设计
4.4.1 概念模型设计
数据库概念模型设计的核心任务在于将现实业务世界中的对象、属性及其相互关系抽象为信息世界中可描述、可操作的模型结构。任何业务系统的数据需求都可以被分解为若干相对独立的实体，实体之间通过一对一、一对多或多对多的联系纽带相互关联，共同构成完整的业务数据图景。这一抽象过程是从现实世界到信息世界的第一次跨越，其质量直接决定后续逻辑设计与物理实现的准确程度17。本系统的业务场景横跨健康管理、社交互动、电商购物三大领域，实体种类丰富，关联关系复杂。以实体-联系图作为可视化表达工具，能够在设计阶段直观呈现各业务对象之间的依附与引用关系，为数据库表结构的规范化设计提供清晰依据。基于以上分析，将绘制反映本系统全域数据结构的E-R图，为后续的逻辑模型设计提供依据。全局E-R模型如图4-8所示。
图4-8全局ER图
根据系统分析，系统的主要实体有：收货地址、购物车、饮食记录、食物信息、论坛、健康商城、健康报告、物流配送、运动信息、运动记录、营养配餐、订单、普通用户。
各个实体具体的属性如下图所示。
（1）收货地址实体主要包括收货地址id、地址、创建时间、默认判断、姓名、手机、邮编、更新时间、用户ID等。如图4-9所示。
图4-9收货地址实体属性图
（2）购物车实体主要包括购物车id、创建时间、描述、商品id、图片、规格、数量、单价、原价、总价、状态、标题、商品分类、更新时间、用户ID等。如图4-10所示。
图4-10购物车实体属性图
（3）饮食记录实体主要包括饮食记录id、创建用户ID、创建时间、食物热量、摄入热量、摄入数量、食物名称、普通用户、记录日期、记录备注、记录标题、记录时间、更新时间等。如图4-11所示。
图4-11饮食记录实体属性图
（4）食物信息实体主要包括食物信息id、收藏数、评论数、创建用户ID、创建时间、食物热量、食物介绍、食物图片、食物详情、点击数、食物名称、点赞数、食物类型、更新时间等。如图4-12所示。
图4-12食物信息实体属性图
）论坛实体主要包括论坛id、排序、用户ID、昵称、点赞数、访问数、标题、关键词、描述、标签、封面图、正文、创建时间、更新时间、发帖人头像、论坛分类、是否置顶等。如图4-13所示。
图4-13论坛实体属性图
（6）健康商城实体主要包括健康商城id、适用群体、标题、封面图、描述、原价、卖价、商品库存、商品分类、正文、主图1至主图5、上架状态、规格、创建时间、创建用户ID、更新时间等。如图4-14所示。
图4-14健康商城实体属性图
（7）健康报告实体主要包括健康报告id、创建用户ID、创建时间、运动时长、额外信息、消耗热量、普通用户、报告内容、报告标题、报告类型、报告时间、来源ID、来源表、来源用户、运动建议、更新时间等。如图4-15所示。
图4-15健康报告实体属性图
（8）物流配送实体主要包括物流配送id、联系人名字、配送详情、配送员ID、配送员名字、配送方式、创建时间、配送订单、配送状态、商家id、订单号、普通用户、商品名称、购买数量、收货地址、签收状态、发货日期、交易总额、更新时间等。如图4-16所示。
图4-16物流配送实体属性图
（9）运动信息实体主要包括运动信息id、运动名称、收藏数、评论数、创建用户ID、创建时间、运动时长、消耗热量、点击数、运动图片、点赞数、注意事项、强度等级、运动类型、更新时间等。如图4-17所示。
图4-17运动信息实体属性图
（10）运动记录实体主要包括运动记录id、普通用户、记录标题、记录日期、用户身高、当前体重、运动名称、消耗热量、运动时长、感受描述、生成报告限制次数、创建时间、创建用户ID、更新时间等。如图4-18所示。
图4-18运动记录实体属性图
（11）营养配餐实体主要包括营养配餐id、餐单标题、生成日期、普通用户、用户姓名、健康状况、饮食习惯、过敏食物、健身目标、能量需求、配餐情况、创建时间、创建用户ID、更新时间等。如图4-19所示。
图4-19营养配餐实体属性图
（12）订单实体主要包括订单id、收件地址、联系人邮箱、联系人姓名、联系人手机、创建时间、发货状态、描述、商品ID、商品图片、商家ID、规格、数量、订单号、邮政编码、价格、原价、总价、订单状态、商品标题、商品分类、更新时间、买家ID等。如图4-20所示。
图4-20订单实体属性图
（13）普通用户实体主要包括普通用户id、用户姓名、用户手机、健康状况、饮食习惯、过敏食物、健身目标、用户身高、用户体重、审核状态、用户ID、创建时间、创建用户ID、更新时间等。如图4-21所示。
图4-21普通用户实体属性图
4.4.2 数据库表设计
数据库逻辑设计是在概念模型的基础上，将实体-联系图转化为具体的关系模式，进而形成可在关系型数据库中物理实现的表结构体系。本系统依据第三范式对各业务实体进行规范化处理，消除数据冗余，保证各属性对主键的完全函数依赖，使数据更新操作不会引发异常。各实体之间的一对多关联关系通过外键字段在子表中显式体现，多对多关系则通过中间关联表进行分解，确保关系完整性约束在物理层面得到落实18。MySQL的规范化表结构设计与系统业务逻辑高度匹配，各表的字段类型与长度经过统一约束，避免了存储空间的浪费与数据格式不一致问题。表结构的清晰分层使上层Service层在执行复杂联合查询时能够以简洁的SQL逻辑获取所需数据，降低了业务开发的复杂度，为系统功能的稳定运行奠定了数据基础。
（1）收货地址表主要是用来存储用户的收货地址信息。主要包括收货地址id、地址、姓名、手机等字段。如表4-1所示。
表4-1收货地址表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | address_id | int | 11 | 主键 |
| 2 | address | varchar | 200 | 地址 |
| 3 | name | varchar | 100 | 姓名 |
| 4 | phone | varchar | 20 | 手机 |
| 5 | postcode | varchar | 8 | 邮编 |
| 6 | default | tinyint | 11 | 默认判断 |
| 7 | user_id | int | 11 | 用户ID |
| 8 | create_time | timestamp | - | 创建时间 |
| 9 | update_time | timestamp | - | 更新时间 |
（2）购物车表主要是用来存储用户加入购物车的商品信息。主要包括购物车id、商品id、数量、单价等字段。如表4-2所示。
表4-2购物车表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | cart_id | int | 11 | 主键 |
| 2 | goods_id | int | 11 | 商品id |
| 3 | num | int | 11 | 数量 |
| 4 | price | double | - | 单价 |
| 5 | price_ago | double | - | 原价 |
| 6 | price_count | double | - | 总价 |
| 7 | norms | varchar | 64 | 规格 |
| 8 | state | int | 11 | 状态 |
| 9 | user_id | int | 11 | 用户ID |
| 10 | create_time | timestamp | - | 创建时间 |
| 11 | update_time | timestamp | - | 更新时间 |
（3）饮食记录表主要是用来记录用户每日的饮食摄入数据。主要包括饮食记录id、食物名称、摄入热量、记录日期等字段。如表4-3所示。
表4-3饮食记录表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | diet_record_id | int | 11 | 主键 |
| 2 | name_of_food | varchar | 64 | 食物名称 |
| 3 | food_calories | varchar | 64 | 食物热量 |
| 4 | intake_of_calories | double | - | 摄入热量 |
| 5 | intake_quantity | double | - | 摄入数量 |
| 6 | record_date | date | - | 记录日期 |
| 7 | record_title | varchar | 64 | 记录标题 |
| 8 | ordinary_user | int | 11 | 普通用户 |
| 9 | create_by | int | 11 | 创建用户ID |
| 10 | create_time | datetime | - | 创建时间 |
| 11 | update_time | timestamp | - | 更新时间 |
（4）食物信息表主要是用来存储系统中维护的食物基础信息。主要包括食物信息id、食物名称、食物热量、食物类型等字段。如表4-4所示。
表4-4食物信息表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | food_information_id | int | 11 | 主键 |
| 2 | name_of_food | varchar | 64 | 食物名称 |
| 3 | food_calories | double | - | 食物热量 |
| 4 | type_of_food | varchar | 64 | 食物类型 |
| 5 | food_introduction | text | 65535 | 食物介绍 |
| 6 | food_pictures | varchar | 255 | 食物图片 |
| 7 | hits | int | 11 | 点击数 |
| 8 | praise_len | int | 11 | 点赞数 |
| 9 | create_by | int | 11 | 创建用户ID |
| 10 | create_time | datetime | - | 创建时间 |
| 11 | update_time | timestamp | - | 更新时间 |
（5）论坛表主要是用来存储用户在社交互动模块发布的帖子内容。主要包括论坛id、标题、正文、用户ID等字段。如表4-5所示。
表4-5论坛表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | forum_id | int | 11 | 主键 |
| 2 | title | varchar | 125 | 标题 |
| 3 | content | longtext | - | 正文 |
| 4 | user_id | int | 11 | 用户ID |
| 5 | nickname | varchar | 16 | 昵称 |
| 6 | type | varchar | 64 | 论坛分类 |
| 7 | hits | int | 11 | 访问数 |
| 8 | praise_len | int | 11 | 点赞数 |
| 9 | istop | int | 11 | 是否置顶 |
| 10 | create_time | timestamp | - | 创建时间 |
| 11 | update_time | timestamp | - | 更新时间 |
（6）健康商城表主要是用来存储健康商城的商品信息。主要包括健康商城id、标题、卖价、商品库存等字段。如表4-6所示。
表4-6健康商城表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | health_mall_id | int | 11 | 主键 |
| 2 | cart_title | varchar | 125 | 标题 |
| 3 | cart_price | double | - | 卖价 |
| 4 | cart_price_ago | double | - | 原价 |
| 5 | cart_inventory | int | 11 | 商品库存 |
| 6 | cart_type | varchar | 64 | 商品分类 |
| 7 | applicable_groups | varchar | 64 | 适用群体 |
| 8 | list_status | smallint | 11 | 上架状态 |
| 9 | create_by | int | 11 | 创建用户ID |
| 10 | create_time | datetime | - | 创建时间 |
| 11 | update_time | timestamp | - | 更新时间 |
（7）健康报告表主要是用来存储系统为用户生成的个人健康分析报告。主要包括健康报告id、报告标题、报告内容、报告类型等字段。如表4-7所示。
表4-7健康报告表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | health_report_id | int | 11 | 主键 |
| 2 | report_title | varchar | 64 | 报告标题 |
| 3 | report_contents | text | 65535 | 报告内容 |
| 4 | report_type | varchar | 64 | 报告类型 |
| 5 | exercise_duration | varchar | 64 | 运动时长 |
| 6 | heat_consumption | varchar | 64 | 消耗热量 |
| 7 | sports_recommendations | varchar | 255 | 运动建议 |
| 8 | ordinary_user | int | 11 | 普通用户 |
| 9 | create_by | int | 11 | 创建用户ID |
| 10 | create_time | datetime | - | 创建时间 |
| 11 | update_time | timestamp | - | 更新时间 |
（8）物流配送表主要是用来记录订单的物流配送状态与配送详情。主要包括物流配送id、订单号、配送方式、配送状态等字段。如表4-8所示。
表4-8物流配送表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | logistics_delivery_id | int | 11 | 主键 |
| 2 | order_number | varchar | 64 | 订单号 |
| 3 | courier_type | int | 11 | 配送方式 |
| 4 | delivery_status | varchar | 64 | 配送状态 |
| 5 | signing_status | varchar | 64 | 签收状态 |
| 6 | contact_name | varchar | 255 | 联系人名字 |
| 7 | shipping_address | varchar | 64 | 收货地址 |
| 8 | ordinary_users | int | 11 | 普通用户 |
| 9 | the_date_of_issuance | date | - | 发货日期 |
| 10 | total_transaction_amount | double | - | 交易总额 |
| 11 | create_time | datetime | - | 创建时间 |
| 12 | update_time | timestamp | - | 更新时间 |
（9）运动信息表主要是用来存储系统维护的各类运动项目基础信息。主要包括运动信息id、运动名称、运动类型、消耗热量等字段。如表4-9所示。
表4-9运动信息表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | motion_information_id | int | 11 | 主键 |
| 2 | campaign_name | varchar | 64 | 运动名称 |
| 3 | type_of_exercise | varchar | 64 | 运动类型 |
| 4 | heat_consumption | double | - | 消耗热量 |
| 5 | exercise_duration | double | - | 运动时长 |
| 6 | strength_grade | varchar | 64 | 强度等级 |
| 7 | motion_picture | varchar | 255 | 运动图片 |
| 8 | hits | int | 11 | 点击数 |
| 9 | praise_len | int | 11 | 点赞数 |
| 10 | create_by | int | 11 | 创建用户ID |
| 11 | create_time | datetime | - | 创建时间 |
| 12 | update_time | timestamp | - | 更新时间 |
（10）运动记录表主要是用来存储用户每次完成运动后提交的记录数据。主要包括运动记录id、运动名称、运动时长、消耗热量等字段。如表4-10所示。
表4-10运动记录表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | motion_record_id | int | 11 | 主键 |
| 2 | campaign_name | varchar | 64 | 运动名称 |
| 3 | exercise_duration | varchar | 64 | 运动时长 |
| 4 | heat_consumption | varchar | 64 | 消耗热量 |
| 5 | record_date | date | - | 记录日期 |
| 6 | record_title | varchar | 64 | 记录标题 |
| 7 | current_weight | double | - | 当前体重 |
| 8 | ordinary_user | int | 11 | 普通用户 |
| 9 | health_report_limit_times | int | 11 | 生成报告限制次数 |
| 10 | create_by | int | 11 | 创建用户ID |
| 11 | create_time | datetime | - | 创建时间 |
| 12 | update_time | timestamp | - | 更新时间 |
（11）营养配餐表主要是用来存储系统为用户生成的个性化营养配餐方案。主要包括营养配餐id、餐单标题、健康状况、健身目标等字段。如表4-11所示。
表4-11营养配餐表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | nutrition_catering_id | int | 11 | 主键 |
| 2 | meal_summary_title | varchar | 64 | 餐单标题 |
| 3 | health_status | varchar | 64 | 健康状况 |
| 4 | fitness_goals | varchar | 64 | 健身目标 |
| 5 | eating_habits | varchar | 64 | 饮食习惯 |
| 6 | allergic_food | varchar | 64 | 过敏食物 |
| 7 | energy_demand | varchar | 64 | 能量需求 |
| 8 | ordinary_user | int | 11 | 普通用户 |
| 9 | generated_date | date | - | 生成日期 |
| 10 | create_by | int | 11 | 创建用户ID |
| 11 | create_time | datetime | - | 创建时间 |
| 12 | update_time | timestamp | - | 更新时间 |
（12）订单表主要是用来存储用户在健康商城下单产生的订单数据。主要包括订单id、订单号、订单状态、总价等字段。如表4-12所示。
表4-12订单表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | order_id | int | 11 | 主键 |
| 2 | order_number | varchar | 64 | 订单号 |
| 3 | state | varchar | 16 | 订单状态 |
| 4 | price_count | double | - | 总价 |
| 5 | price | double | - | 价格 |
| 6 | num | int | 11 | 数量 |
| 7 | goods_id | int | 11 | 商品ID |
| 8 | delivery_state | varchar | 16 | 发货状态 |
| 9 | contact_name | varchar | 32 | 联系人姓名 |
| 10 | contact_address | varchar | 255 | 收件地址 |
| 11 | user_id | int | 11 | 买家ID |
| 12 | create_time | timestamp | - | 创建时间 |
| 13 | update_time | timestamp | - | 更新时间 |
（13）普通用户表主要是用来存储系统注册用户的个人健康档案信息。主要包括普通用户id、用户姓名、健康状况、健身目标等字段。如表4-13所示。
表4-13普通用户表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | ordinary_user_id | int | 11 | 主键 |
| 2 | user_name | varchar | 64 | 用户姓名 |
| 3 | users_mobile_phone | varchar | 20 | 用户手机 |
| 4 | health_status | varchar | 64 | 健康状况 |
| 5 | eating_habits | varchar | 64 | 饮食习惯 |
| 6 | allergic_food | varchar | 64 | 过敏食物 |
| 7 | fitness_goals | varchar | 64 | 健身目标 |
| 8 | user_height | double | - | 用户身高 |
| 9 | user_weight | double | - | 用户体重 |
| 10 | examine_state | varchar | 16 | 审核状态 |
| 11 | user_id | int | 11 | 用户ID |
| 12 | create_time | datetime | - | 创建时间 |
| 13 | update_time | timestamp | - | 更新时间 |
第五章 系统实现
5.1 普通用户角色功能实现
5.1.1 社交互动
社交互动模块主要是对用户在平台内的内容发布与互动行为进行管理。用户进入该模块后可通过关键词输入对已有帖子进行检索，系统依据搜索条件返回匹配内容列表。用户点击具体内容后进入详情页，可对帖子执行点赞、收藏操作，亦可发表评论或对他人评论进行回复。发布流程中，用户选择封面图、填写标签后提交，系统完成内容入库并刷新列表展示。社交互动界面如图5-1所示。
图5-1社交互动界面
5.1.2 健康资讯
健康资讯模块主要是对平台内的健康相关文章内容进行展示与检索。用户可通过关键词搜索或分类筛选定位目标资讯，系统返回符合条件的文章列表。进入资讯详情页后，用户可完整阅读文章正文，并对感兴趣的内容执行点赞、收藏或评论操作，系统实时更新对应的互动计数字段。健康资讯界面如图5-2所示。
图5-2健康资讯界面
5.1.3 健康商城
健康商城模块主要是对健康类商品的浏览、筛选与购买流程进行管理。用户可按排序规则浏览商品列表，进入商品详情页后选择购买数量，执行加入购物车或立即购买操作。购买流程中用户选择收货地址并进入支付中心，系统支持微信支付、支付宝、网银等多种支付方式，支付完成后系统生成订单记录并更新库存数据。健康商城界面如图5-3所示。
图5-3健康商城界面
5.1.4 商城管理
商城管理模块主要是对用户在购物流程中产生的订单、购物车及地址数据进行个人维护。我的订单功能支持按订单状态筛选查询，用户可查看订单详情并发起退款申请。我的购物车功能支持勾选全部商品批量删除或直接进入购买流程。我的地址功能支持新增收货地址、修改已有地址信息或删除不再使用的地址条目。商城管理界面如图5-4所示。
图5-4商城管理界面
5.1.5 个人中心
个人中心模块主要是对用户的健康业务记录进行集中管理。饮食记录功能支持新增摄入数据、修改已有条目并查看详情；运动记录功能支持运动数据的录入、编辑与历史查询；营养配餐功能展示系统生成的个性化配餐方案供用户查阅；健康报告功能提供阶段性健康分析结果；物流配送功能支持订单配送状态的实时跟踪查询。个人中心界面如图5-5所示。
图5-5个人中心界面
5.2 管理员角色功能实现
5.2.1 运动信息管理
运动信息管理模块主要是对平台内的运动项目基础数据进行维护。管理员可通过关键词搜索快速定位目标运动条目，执行添加、修改或删除操作。编辑运动页面支持上传运动图片、填写视频或文件链接，管理员完成信息填写后提交，系统将数据写入运动信息表并更新前台展示列表，确保用户侧能够获取到最新的运动参考资料。运动信息管理界面如图5-6所示。
图5-6运动信息管理界面
5.2.2 食物信息管理
食物信息管理模块主要是对系统内维护的食物基础数据进行增删改查操作。管理员可按食物名称或分类进行筛选检索，点击添加按钮进入编辑页面填写食物名称、热量、类型等信息，并上传对应的食物图片。修改操作支持对已有食物信息的字段更新，删除操作在确认后将目标记录从数据库中移除，数据变更即时反映在用户侧的饮食记录参考内容中。食物信息管理界面如图5-7所示。
图5-7食物信息管理界面
5.2.3 饮食记录管理
饮食记录管理模块主要是对用户提交的饮食摄入数据进行后台审核与管理。管理员可按用户、日期或食物名称进行条件筛选，对存在异常的记录执行修改操作，对无效或错误数据执行删除操作。系统在记录列表中展示各条目的摄入热量、记录日期等关键字段，管理员可快速识别数据异常情况，保障饮食记录数据的整体质量。饮食记录管理界面如图5-8所示。
图5-8饮食记录管理界面
5.2.4 营养配餐管理
营养配餐管理模块主要是对系统生成的个性化营养配餐方案进行全面管理。管理员可查询现有配餐方案列表，对方案内容进行修改或删除操作。模块核心功能在于AI配餐生成入口，管理员触发生成操作后，系统读取目标用户的健康档案数据，调用AI接口生成符合其健康状况与饮食习惯的配餐方案，方案生成完成后自动写入数据库并在列表中更新展示。营养配餐管理界面如图5-9所示。
图5-9营养配餐管理界面
5.2.5 运动记录管理
运动记录管理模块主要是对用户提交的运动记录数据进行后台统一维护。管理员可按用户、运动名称或日期进行条件检索，查看单条记录的详情信息，包括运动时长、消耗热量、当前体重等字段。对于数据有误的记录，管理员可执行修改操作进行更正；对于重复或无效数据，可执行删除操作将其从系统中移除，维护运动记录数据的准确性。运动记录管理界面如图5-10所示。
图5-10运动记录管理界面
5.2.6 商城管理
商城管理模块主要是对健康商城的商品信息与订单流程进行后台统一管理。商品管理功能支持商品的新增、编辑、删除操作，并提供上架与下架状态的切换控制，管理员可对商品库存、价格、分类等核心字段进行维护。订单管理功能支持按订单状态筛选查询，管理员可查看订单详情、执行发货操作，在订单配送页填写配送方式与配送详情后确认发货，系统同步更新订单状态并创建物流配送记录。商城管理界面如图5-11所示。
图5-11商城管理界面
第六章 系统测试
6.1 测试目的
系统测试的根本目标在于验证各功能模块的实际运行结果与设计规格之间的一致程度。本系统业务逻辑涵盖健康数据管理、订单交易、社交互动等多个场景，任一模块的数据处理偏差都可能影响用户的健康决策或交易安全。测试工作重点关注业务逻辑的准确性，通过系统测试19，验证饮食记录、运动记录、营养配餐、订单发货等核心流程在边界条件下的响应行为，确认系统在合法输入与异常输入场景下均能给出符合预期的数据反馈，为系统的稳定上线提供验证依据。
6.2 测试方法
本系统采用黑盒测试作为主要测试手段，以用户角色视角对各功能模块的输入输出行为进行验证，不依赖内部代码实现细节。测试人员依据功能需求文档设计测试用例，覆盖正常操作路径、边界值输入场景及异常数据输入场景三类情况，逐一记录系统实际响应结果与预期结果的吻合情况。
针对数据关联性较强的业务链路，如下单流程与库存扣减、运动记录提交与健康报告生成联动等场景，测试过程中同步验证跨模块数据的一致性，确保系统各节点的数据状态在业务操作完成后保持同步正确。
6.3 测试用例
本节对系统核心业务模块进行测试用例设计。选取饮食记录、运动记录、营养配餐、健康报告、社交互动、健康商城、订单管理七个模块展开功能验证，覆盖各模块的主要操作路径与边界异常场景，测试结果作为系统功能完整性的客观依据。
饮食记录模块的测试目标在于验证用户提交饮食摄入数据后，系统能否准确完成记录写入、热量计算及历史查询的完整业务闭环。
表6-1饮食记录测试用例表
| 测试内容 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|
| 新增饮食记录 | 填写食物名称、摄入数量、记录日期后提交 | 记录成功写入，列表刷新显示新增条目 | 符合预期 |
| 必填字段为空 | 不填写食物名称直接提交 | 系统提示必填字段不可为空 | 符合预期 |
| 查询历史记录 | 输入日期范围进行筛选 | 系统返回对应日期区间的记录列表 | 符合预期 |
| 修改饮食记录 | 选中已有记录修改摄入数量后保存 | 数据更新成功，列表显示修改后数据 | 符合预期 |
运动记录模块的测试目标在于验证用户提交运动数据后，系统能否正确存储记录并在达到触发条件时联动生成健康报告。
表6-2运动记录测试用例表
| 测试内容 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|
| 新增运动记录 | 填写运动名称、时长、消耗热量后提交 | 记录写入成功，列表更新 | 符合预期 |
| 触发健康报告生成 | 提交运动记录且未达生成次数上限 | 系统自动生成健康报告 | 符合预期 |
| 超出生成次数上限 | 提交记录时已达上限次数 | 仅保存运动记录，不生成报告 | 符合预期 |
营养配餐模块的测试目标在于验证AI配餐生成功能在不同健康档案完整度条件下的响应逻辑是否符合业务规则。
表6-3营养配餐测试用例表
| 测试内容 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|
| 档案不完整时生成 | 用户档案缺少健身目标字段，触发生成 | 系统提示档案信息不完整 | 符合预期 |
| 查询已有配餐方案 | 按日期筛选配餐列表 | 系统返回对应时间段的配餐记录 | 符合预期 |
健康报告模块的测试目标在于验证系统生成的健康报告内容能否准确关联用户的运动数据，并支持正常的查询与详情查阅操作。
表6-4健康报告测试用例表
| 测试内容 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|
| 查询健康报告列表 | 进入健康报告页面执行查询 | 系统展示用户历史报告列表 | 符合预期 |
| 查看报告详情 | 点击具体报告记录查看详情 | 详情页正确显示报告内容与运动建议 | 符合预期 |
| 报告数据关联验证 | 核对报告中的运动时长与运动记录数据 | 数据一致，来源关联正确 | 符合预期 |
社交互动模块的测试目标在于验证帖子发布、评论回复、点赞收藏等社交行为的完整处理链路是否准确运行。
表6-5社交互动测试用例表
| 测试内容 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|
| 发布帖子 | 填写标题、内容、封面图后提交 | 帖子写入成功，列表刷新 | 符合预期 |
| 发表评论 | 在帖子详情页提交评论内容 | 评论显示在详情页，评论数更新 | 符合预期 |
| 帖子点赞 | 点击点赞按钮 | 点赞数加一，状态变更正确 | 符合预期 |
健康商城模块的测试目标在于验证商品浏览、购物车操作、地址选择及支付发起等购物流程各环节的数据流转是否准确。
表6-6健康商城测试用例表
| 测试内容 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|
| 商品加入购物车 | 在商品详情页选择数量后点击加入购物车 | 商品写入购物车，数量正确 | 符合预期 |
| 库存不足时购买 | 选择库存为零的商品立即购买 | 系统提示库存不足，阻止提交 | 符合预期 |
| 支付流程发起 | 选择地址后进入支付中心完成支付 | 订单创建成功，库存相应扣减 | 符合预期 |
订单管理模块的测试目标在于验证订单从生成、发货操作到物流记录创建的完整状态流转逻辑是否与业务规则吻合。
表6-7订单管理测试用例表
| 测试内容 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|
| 订单状态筛选 | 按待发货状态筛选订单列表 | 列表仅显示待发货订单 | 符合预期 |
| 发货操作 | 填写配送方式与配送详情后确认发货 | 订单状态更新为已配送，物流记录创建 | 符合预期 |
| 配送信息不完整 | 不填写配送详情直接确认发货 | 系统提示配送信息不完整 | 符合预期 |
| 查看订单详情 | 点击订单条目查看详情 | 详情页正确展示商品、金额、地址信息 | 符合预期 |
测试结论
本文针对全民健身和饮食健康领域数据分散、服务割裂的现状，设计并实现了一个基于Spring Boot的综合性管理系统。系统使用成熟的B/S架构和前后端分离的方式，技术栈为Spring Boot后端框架、Vue前端体系和MySQL关系型数据库，保证系统具有高扩展性、稳定性。从功能实现角度来讲，系统将运动管理、饮食追踪、AI辅助营养配餐、健康报告生成、社交互动、健康商城等各个模块进行了深度融合。普通用户可以完成整个健康行为的记录和反馈，管理员在后台可以完成对食物运动基础数据、订单物流以及配餐方案的高效维护。研发过程中严格按照软件工程规范进行，经过了需求分析、E-R概念建模、逻辑表结构设计以及编码实现等一系列的过程。经过黑盒测试，系统在饮食记录热量计算、运动数据联动、商城交易闭环等主要业务链路上表现稳定，逻辑正确，能够很好地满足用户对于个性化、一体化健康服务的需求，为全民健身事业的数字化转型提供具有实践意义的参考方案。