本科毕业论文(设计)

题目：基于SpringBoot的药食同源食疗方构造系统设计

摘要

传统食疗推荐系统存在个性化与配伍方面的不足，为此，本研究开发了一套基于Spring Boot的药食同源智能食疗方系统。具体而言，该系统立足中医"药食同源"理论框架，在技术实现层面采用前后端分离的B/S架构设计。在技术选型上，后端选择Spring Boot框架整合MyBatis-Plus实现动态数据管理，前端则基于Vue.js开发了友好的用户交互界面。

本研究提出了多维度症状标签匹配模型，借助规则引擎实现症状与食材的精准映射。用户能够凭借‘身体部位→症状→方案’的三级筛选模式获取个性化食疗建议，并可集成的智能助手进行中医知识实时问答。系统分层架构和模块化开发确保了功能的可扩展性和数据安全，为中医药膳食疗数字化提供了切实可行的技术方案。

关键词： 药食同源,食疗推荐,Spring Boot框架,Vue3组件化

Abstract

Traditional Food Therapy Recommendation Systems face limitations in personalization and ingredient compatibility. To address this, this study developed an intelligent medicinal-food homology dietary system based on Spring Boot. Specifically, the system is grounded in the traditional Chinese medicine (TCM) theory of “medicinal-food homology.” Technologically, it adopts a frontend-backend separated B/S architecture. For backend implementation, the Spring Boot framework integrates MyBatis-Plus for dynamic data management, while the frontend utilizes Vue.js to deliver an intuitive user interface.

This research proposes a multi-dimensional symptom-label matching model, employing a rule engine to achieve precise mapping between symptoms and ingredients. Users can acquire personalized dietary recommendations through a three-step filtering process (“body region → symptom → formulation”) and engage with an integrated AI-powered assistant for real-time TCM knowledge queries. The system’s layered architecture and modular design ensure scalability and data security, offering a practical technical solution for digitizing TCM medicinal-food dietary therapy.

Keywords: Medicinal-Food Homology, Recipe Recommendation, Spring Boot Framework, Vue Componentization

1 引言

1.1 课题背景

1.1.1 国际现状

国外在饮食与健康研究领域成果显著。地中海饮食因预防疾病功效受广泛认可[1]，它的成分标注和食谱设计上更为细致的特点值得学习；还开发了相关的应用程序（Coolinarika），该应用提供丰富的食谱和AI助手推荐，每月吸引超70万的活跃用户。

1.1.2 国内现状

国内对中医食疗合理性的研究不断深入。研究发现，药用植物的消费与老年人全因死亡率、认知障碍呈负相关[2]；相关研究还表明，饮食干预对慢性病管理意义重大，某些食物成分能调节免疫炎症反应改善类风湿关节炎症状[3]。这都说明药食同源食材在预防疾病、促进健康方面有大潜力。

中医食疗在国内关注度很高，争议也多。主要是没有统一标准，导致有人对其效果持怀疑态度；有人却盲目跟风，甚至因不当饮食引发健康问题。故普及正确的食疗知识十分必要。

因科技发展、国民对中华民族文化认同感提升，人们更倾向于用中医食疗来改善身体状况，市场上也出现了一些中医食疗应用。但这些应用存在功能单一、更新不及时及用户参与意愿不太高等等问题。不过，国内在利用现代技术推广传统食疗理念方面仍有优势。

1.1.3 国内外的异同、国外的研究对中国的启示意义

国内外在药食同源研究上各有特点。国外的研究在成分标注、食谱设计上更为细致，国内则在传统食疗理念与现代营养科学的结合上具优势；国外应用会充分考虑当地饮食文化和习惯，国内应用也应挖掘中国饮食文化资源、提高普及度，进一步推广。

1.2 目的和意义

本课题设计开发了基于Spring Boot的药食同源食疗方构造系统，整合多学科知识，创新研究视角。该系统有助于用户管理健康，普及中医食疗，优化用户体验，增强国民对中医的认同感，推动健康管理和文化传承。

期望达到的学术价值和现实意义有：

1. 学术价值
   (1) 填补空白：构建基于Spring Boot的药食同源食疗方构造系统，推动传统中医食疗理念现代化，为相关学术研究提供新视角和方法。
   (2) 跨学科整合：融合中医食疗、营养学、计算机科学和软件工程等多学科知识，形成完整解决方案，为类似跨学科研究提供参考。
   (3) 创新视角：从现代技术角度结合传统中医食疗理念与现代软件工程，实现功能创新，为传统食疗现代化应用提供新思路。

2. 现实意义
   (1) 助力用户健康管理：实现对慢性疾病的提前预防和科学管控，进而提升用户的生活质量。
   (2) 融合现代科技与营养学：打造具有中国特色的饮食疗法，推动中医食疗普及，提高公众认知水平。
   (3) 满足用户个性化需求：借助智能手段简化系统操作流程，优化界面布局，全方位激发用户互动积极性，从而获得更高的用户满意度。
   (4) 强化民众中医认知：为中医文化的传承与发展注入新的活力。

1.3 系统设计思想

本系统分为药食同源数据后台管理（管理员端）与药食同源用户前台交互界面（用户端）采用前后端分离架构，保证模块的独立性和可扩展性。

1.3.1 用户端设计思想

系统根据中医中的“性味归经”理论，将食材的四性及五味与人体脏腑经络对应；三级筛选（身体部位→症状→方案）实现“辨证施膳”，确保推荐方案符合中医食疗的核心准则。

用户端以用户体验为核心，提供以下功能模块：

1. 健康资讯模块：用户点击抽签可查看随机一条每日养生Tips；用户可以筛选中药性质（寒、热、温等等）查看各类中药的信息。还可以查看中医要闻等信息，内容以图文形式展示。
2. 食疗方案推荐：用户选择身体部位和症状，系统就会按预设关联规则推荐食疗方案，可以按食材或功效再筛。
3. 智能助手交互：用户可与智能助手咨询中医相关问题，助手就调用外部API（KimiAI）实时解答。
4. 个人信息管理：用户查看和修改个人资料，包括用户名、昵称、地址等信息，也可以对密码进行修改。
5. 药食同源可视化面板：由地图和数据Echart图表组成，鼠标悬停触发事件。

1.3.2 管理员端设计思想

管理员端以数据管理为核心，需要提供以下功能模块：

1. 内容管理：管理员可编辑和发布养生资讯及食疗方案等内容，支持编辑和批量操作。
2. 用户信息管理：管理员可查看和管理用户信息，支持按条件筛选和导出。
3. 数据分析：管理员可查看用户行为数据和系统使用统计，图表形式来展示关键指标，辅助决策。
4. 权限管理：管理员可设置不同角色的权限（系统操作的安全性和规范性）。
5. 技术实现：Spring Boot框架开发、MyBatis-Plus实现数据持久化，确保后台管理的高效性和稳定性。

用户端会突出内容页面和智能推荐、管理员端就侧重数据管控及安全性，二者解耦，共同使系统运行。

1.3.3 系统集成设计

RESTful API联动前后端进行数据、前端Vue.js组件用Axios发起HTTP请求、后端Spring Boot接收请求并调用Service层处理业务逻辑，返回json数据。

以下是系统集成设计：

(1) 用户端交互流程：用户点击"抽签获取养生Tips"时，前端调用接口；后端就从MySQL随机抽取数据并返回；前端动态渲染它调用出的部分至页面；

(2) 管理员数据同步：管理员发布新食疗方案后，后端接口写入数据库，前端轮询接口获取更新，实现无刷新展示；

(3) 智能助手逻辑：用户提问时，前端将问题文本经WebSocket推送至后端，后端调用KimiAI API获取回答，再透传给前端展示，全程加密传输（HTTPS+JWT鉴权）。

1.4 系统开发环境

1.4.1 后端开发环境

1. 框架：Spring Boot 2.5.2（集成Web、MyBatis-Plus、Security模块）；
2. 依赖管理：Maven 3.8.6，JDK 1.8；
3. 核心依赖：
   MyBatis-Plus 3.5.1（动态SQL生成、分页插件）；
   Hutool 5.8.1（工具类库，用于JSON解析、HTTP请求）；
   Apache HttpClient 4.5.13（第三方API调用）；
4. 数据库：MySQL 5.7.26。

1.4.2 前端开发环境

1. 框架：Vue 3.2.45 + Element Plus 2.3.1（UI组件库）。
2. 构建工具：Vite 4.0.0，Node.js 16.14.2。
3. 核心依赖：GSAP 3.12.7（动画效果实现）；
   NProgress 0.2.0（页面加载进度条）；
   Axios 1.3.5（RESTful API请求）。

1.4.3 开发工具与选型理由

1. 后端技术栈：
   Java语言是本项目后端开发的基础。以下是后端具体的技术栈：
   (1) Spring Boot：快速构建微服务架构，内置Tomcat容器和自动化配置，减少样板代码；再根据现有的研究，用starter机制来一键集成MyBatis-Plus等组件提升效率[6]。

   (2) MyBatis-Plus：提供无侵入式CRUD操作，自动生成SQL语句，相比原生MyBatis减少了SQL编写量；
   分页插件和乐观锁机制直接解决数据查询与并发问题。

   (3) MySQL 5.7：支持JSON字段类型，完美适配药食同源数据的灵活扩展（症状-食谱多对多关联）；
   事务隔离级别可配置，保障食疗方案推荐等核心功能的原子性。

2. 前端技术栈：
   Vue3 + TypeScript：组合式 API 替代 Options API。Element Plus：开箱即用的中后台组件库，UI 组件多，也符合业务场景[7]。以下是前端的具体技术栈：

   (1) Vue3 + TypeScript：组合式API替代Options API。
   (2) Element Plus：开箱即用的中后台组件库，UI组件多，也符合业务场景。
   (3) Axios + Interceptors：统一处理请求拦截、响应格式化。
   (4) WebSocket：实现智能助手实时问答。

3. 开发工具链：
   IDEA和Navicat优点：IDEA的Spring Boot插件实时热部署；Navicat的ER图可以反向生成SQL，设计数据库的效率提升。

综上，整合Spring Boot架构与Vue3前端框架，再加上MyBatis-Plus、MySQL 5.7等技术，构建了一个高效、稳定且易于扩展的药食同源食疗方推荐平台。

1.5 系统运行要求

1.5.1 服务器配置

1. CPU：多核处理器（需满足Spring Boot应用线程调度需求）；
2. 内存：按用户并发量动态调整（基础容量需支持JVM运行+数据库缓存）；
3. 存储：SSD系统盘（部署运行环境）+ 独立数据盘（存储MySQL数据表及日志）；
4. 网络要求（带宽）：支持API高频交互（需满足JSON数据传输需求、智能助手加载不卡顿即可）。

1.5.2 系统平台要求

1. 后端运行环境
   (1) 操作系统：Linux（CentOS/Ubuntu）或 Windows Server 2016+；
   (2) Java环境：JDK 11+（推荐OpenJDK 17）；
   (3) Web服务器：Tomcat 9+ 或 Nginx（配合Spring Boot内置Tomcat）；
   (4) 数据库：MySQL 5.7+（需支持JSON字段类型）。

2. 前端运行环境
   (1) 浏览器：Chrome 80+ / Firefox 75+ / Edge 18+；
   (2) 移动端适配：响应式布局，支持iOS 12+ / Android 8.0+；
   (3) 依赖包：Node.js 16+（用于前端构建工具）。

3. 网络要求
   带宽：公网出口带宽≥10Mbps。

综上，系统经合理的环境配置和架构设计，确保：
后端的高性能和稳定性，及前端的跨平台兼容性和用户体验；
前后端经由RESTful API进行高效通信，结合缓存和MySQL数据库，满足复杂业务场景下的数据处理需求；
网络带宽的可靠性设计，保障API交互流畅；
设计进一步平衡了性能与开发成本，为药食同源系统的应用打下坚实的技术基础。

2 可行性分析

2.1 复查系统规模与目标

由系统定位：定位中医健康管理场景，提供食疗方案、中药材信息查询还有健康资讯服务。基于该定位，系统核心需求如下：

1. 解决传统中医食疗方案标准化程度低、用户获取难度大的问题。
2. 实现症状、食材、功效的智能匹配（基于预设关联规则）。
3. 为管理员端提供数据动态更新（如新增药材、调整推荐逻辑）。

2.1.1 系统关系分析

1. 旧系统问题：
   (1) 功能单一：仅展示静态食谱，缺少个性化推荐功能；
   (2) 数据更新滞后：依赖人工Excel维护，易出错；
   (3) 交互性差：用户无法实时咨询中医问题。

2. 针对性地，进行新系统改进：
   (1) 采用前后端分离架构，提升系统扩展性（便于未来接入AI模型）；
   (2) 整整合多数据源（如药典数据库、用户行为日志），优化推荐算法；
   (3) 引入智能助手模块（KimiAI API）增强用户交互。

2.2 解决方案评估

2.2.1 技术可行性

系统借助Spring Boot与Vue.js技术框架，有效降低成本、确保性能可靠。
前端开发模式MVVM，可高效做组件化开发。Vue-Router管理路由状态、Element UI组件使得页面维护容易（封装的组件更好修改）。后端用MyBatis-Plus做ORM映射，配合MySQL5.7数据库，能稳稳控制事务。
在技术选型方面，Spring Boot可以自动装配，能简单配置；Vue的响应式数据绑定，让用户交互更舒适；核心算法有症状、部位、食谱三级关联，还有智能推荐。
数据库遵循第三范式设计，易于维护。开发工具齐全，IDEA、Navicat和Maven配合默契。综合上述分析，该技术方案具有可行性。

2.2.2 经济可行性

系统用Spring Boot+Vue开源框架降低开发成本，MySQL社区版零授权费用。后端框架用Java生态的开源组件，前端用ElementUI等免费组件库，避免商业授权费用。
硬件部署支持笔电运行，后期维护可以用阿里云学生服务器实现比较低的成本运维。智能助手模块接入KimiAI等免费API接口，无第三方服务附加费用。

成本类别	项目明细	规格/数量	单价（元）	小计（元）	说明
人力成本	开发者薪资（自研）	1人×3个月	0	0	自主开发，无薪资支出
软件工具	IntelliJ IDEA	教育版授权	0	0	免费教育许可证
	Navicat Premium	学生版	0	0	正版软件
云服务	阿里云学生服务器	1核2G/6个月	114/年	57	学生优惠价9.5元/月
	域名备案	1个	0	0	使用二级域名
第三方服务	KimiAI API调用	1000次/月	0	0	免费额度覆盖需求
运维成本	数据库备份存储	50GB/年	0	0	免费存储
合计				57

综上，形成零授权费用的轻量化解决方案，经济可行。

2.2.3 操作可行性

用户端采用浏览器访问模式（Chrome/Firefox兼容），交互流程符合Web常规操作：注册→症状勾选→方案查看→得出食谱。
管理端提供可视化CRUD界面。响应式布局适配多终端访问，视觉动线符合浏览习惯；
普通用户无需培训就可以完成自助服务，操作可行。

2.2.4 系统架构和方法学

系统由前后端分离架构为基础。后端靠Spring Boot框架撑起，前端用Vue.js框架打造出交互界面。架构分为三层：

1. 表现层
   基于Vue.js的动态组件开发模式，借助ElementUI组件库实现响应式布局。数据交互方面，Axios实现前后端交互，支持跨域请求，还能调用RESTful API。

2. 业务逻辑层
   基于Spring Boot的模块化设计，使用MyBatis-Plus做数据持久化操作。在用户权限证上，集成JWT（JSON Web Token）来把关；依靠AOP（面向切面编程）统一处理日志记录和异常拦截。

3. 数据存储层
   选用MySQL 5.7关系型数据库存结构化数据，依赖外键约束和事务管理来保障数据一致性。

2.2.5 可行性分析结论

综合技术、经济、操作及时间维度的分析，本系统具备明确的开发可行性。

1. 技术选型：稳定，开发成本可控，功能设计契合用户实际需求，且迭代开发策略可有效规避进度风险。
2. 潜在风险：
   集中于第三方AI接口的稳定性（智能助手响应延迟情况）及用户对新功能的接受度，但可以用接口熔断机制和UI交互设计缓解。

故项目具备可实施性，可进入详细设计与编码阶段。

3 需求分析

3.1 系统功能分析

3.1.1 业务流程图

根据用户端和管理端的操作流程及前后端设计相关内容，运用系统设计与分析方法[9]，绘制出本系统的业务流程图。

3.1.2 主要业务节点说明

1. 用户路径：身体部位→症状→方案的递进式筛选；智能问答模块（中医知识库）；每日健康资讯推送。
2. 管理路径：数据字典维护（三级关联：身体部位↔症状↔方案）；用户信息及内容审核流程。

3.2 需求分析

3.2.1 功能性需求

药食同源系统供两类用户使用，分别是管理员（Admin）和普通用户（User），支持登录和注册功能。
用户登录后，可查看今日健康小贴士（tips）、最新要闻，按分类浏览中药介绍，查看及修改部分个人信息，在智能助手咨询中医相关问题（提问→调用API→渲染结果），并依据身体部位-症状筛选获取适合自己的食疗方案。系统中，一个身体部位关联多个症状，每个症状对应多种食疗方案。
管理员登录后，可管理用户信息、中草药词条等，掌控整个系统。

根据上述关系，得系统功能性需求：
基于Spring Boot和Vue的药食同源食疗方推荐系统分为两个权限：用户、管理员，各个角色对应功能有：

1. 用户：查看今日健康小贴士（tips）、最新要闻；按分类浏览中药介绍；查看修改部分个人信息、使用智能助手咨询中医问题；筛选查询食疗方案。
2. 管理员：管理今日健康小贴士（tips）词条；管理中草药词条；管理用户信息；管理食疗方案。

3.2.2 非功能性需求

1. 数据库脚本设计
   目的：
   (1) 便于建表后输入大量信息；
   (2) 方便在其他服务器直接执行移植数据库；
   (3) 提高数据访问的效率；
   (4) 便于进行数据处理及对数据库的详细设计。
2. 设计不同角色对数据库操作权限；
3. 后端创建enity实体类、mapper接口、controller控制器，进行后端服务的开发；
4. 设计创建Vue组件，在router层添加路由，新增菜单项；
5. 对整个系统进行测试调试。

3.3 系统需求模型

3.3.1 数据流图DFD

数据流图（DFD）能够清晰呈现系统数据处理流程[11]，以下是数据流图设计与介绍。（二编：之前这里没放图 因为论文里面有图不太对 答辩老师说的我听不清所以我整篇没放图。数据流图画图的思路 把顶层抽象出来再画一层二层 每层画的时候建议在草稿纸画一次再上软件写 清楚点 我是先画再批流程的 先在草稿纸拟完顶层一二层再继续画的。后面也好梳理F1F2F3这些）

顶层：
根据数据流图顶层图的抽象规则，在这里把管理员和用户抽象为“角色”。
根据系统主要信息的处理功能，整个系统可以看作登录管理、信息处理。
角色登录/注册成功之后可以对系统进行操作如图3-2所示。

注：F1:角色登陆信息 F2:角色分权限操作信息 F3:角色基本信息 F4:角色基本信息
F5:角色更新之后的信息清单 F6:最新的信息表单 F7:登陆错误信息
F8:处理角色请求后的返回信息
F9:更新的角色信息清单 F10:更新后的角色个人信息
F11：新角色注册申请表单 F12：新角色信息

一层：
登陆管理：角色有用户和管理员，都需要登录之后才能对信息库的信息进行操作。
操作管理：登录错误返回错误信息；登陆后也可以修改密码，更新的个人信息会同步到角色信息库；
没有账号的角色选择注册，对应的，也会同步更新个人信息到角色信息库。
系统一层数据流如图3-3、图3-4、图3-5所示。

注：F2.1:用户登陆信息 F2.2:管理员登陆信息
F7.1:登陆错误 F7.2:修改密码的信息

注：F3.1:用户基本信息 F5.1:用户更新的信息清单
F6.1:经过用户更新后最新的信息表单 F8.1:处理用户请求后的返回信息

注：F3.3:管理员基本信息 F9.1更新后的管理员信息
F5.3:管理员更新的信息清单
F6.2:经过管理员更新后最新的信息表单
F8.2:处理管理员请求后的信息明细

二层：
将P2进行分解。以下管理都涉及增删改查，如图3-6、图3-7所示。

注：智能助手使用外部API接口调用了AI对话模型。F2.1.1:用户更改的个人信息

说明：用户管理包括：查看今日tips、要闻、分类查看中药介绍、查看修改部分个人信息、访问智能助手接口、筛选查询食疗方案；
管理员管理包括：角色信息管理、今日tips词条管理、中草药词条管理、用户信息管理、食疗方案管理、要闻数据管理。

（我想起来我是在wps手搓的了…祝你们答辩顺利！有超好成绩！！）

3.3.2 数据项

1. user（用户表）

列名	说明	数据类型	约束
id	用户ID	INT(11)	主键、自增
username	用户名	VARCHAR(255)	唯一、非空
password	密码	VARCHAR(255)	非空
nick_name	昵称	VARCHAR(255)	-
age	年龄	INT(11)	-
sex	性别	VARCHAR(255)	-
address	地址	VARCHAR(255)	-
role	角色	ENUM(‘admin’,‘user’)	默认值’user’

2. body（身体部位表）

列名	说明	数据类型	约束
b_id	身体部位ID	INT(11)	主键、自增
b_name	身体部位名称	VARCHAR(50)	非空

3. symptom（症状表）

列名	说明	数据类型	约束
s_id	症状ID	INT(11)	主键、自增
s_name	症状名称	VARCHAR(50)	非空
s_description	症状描述	VARCHAR(255)	-
body_id	关联身体部位ID	INT(11)	外键（参考body.b_id）、非空

4. recipe（食谱表）

列名	说明	数据类型	约束
r_id	食谱ID	INT(11)	主键、自增
r_name	食谱名称	VARCHAR(100)	非空
preparation	准备方法	TEXT	-
attention	注意事项	TEXT	-
symptom_id	关联症状ID	INT(11)	外键（参考symptom.s_id）、非空

5. herb（中药材表）

列名	说明	数据类型	约束
h_id	药材ID	INT(11)	主键、自增
h_name	药材名称	VARCHAR(50)	唯一
latin_name	拉丁学名	VARCHAR(100)	-
property	药性	VARCHAR(20)	-
efficacy	功效	TEXT	-

6. today（今日养生tips表）

列名	说明	数据类型	约束
t_id	养生建议ID	INT(11)	主键、自增
content	养生建议内容	VARCHAR(500)	非空

7. news（要闻表）

列名	说明	数据类型	约束
n_id	新闻ID	INT	主键、自增
n_name	新闻标题	VARCHAR(200)	非空
n_content	新闻内容	TEXT	非空

3.3.3 数据结构图

根据系统功能分析及需求分析，得出系统数据结构图。

3.3.4 数据流

关键流程关联说明：

1. 登录流程：F1→P1→F2→P2→F8，加密传输、权限映射及结果反馈。
2. 信息修改流程：P2→F5→D1→F6→P2→F8，要原子性操作及数据的一致性。
3. 注册流程：F11→P3→F12→D1，前端表单验证与后端持久化逻辑。

3.3.5 数据存储

编号	数据存储名	输入数据流	输出数据流	流量
D1	用户信息库	F9、F10、F12	F3、F4	大
D2	信息库	F5	F6	大

3.3.6 处理过程

P1：验证提交的登录信息，失败时记录安全日志并触发锁定机制。

P2：根据角色权限加载“主体菜单”（管理员显示增删改查功能），处理分权限增删改查操作。

P3：校验“新角色注册申请表单”数据合法性。

4 总体设计

4.1 系统总体设计

聚焦于Spring Boot与Web前端和数据库接口设计[11]，系统业务流程围绕用户端功能操作与管理端数据管控两条主线展开。

4.1.1 用户端操作流程

1. 身份验证
   (1) 未注册用户：注册接口提交用户名、密码等基本信息，系统校验唯一性后写入数据库。
   (2) 已注册用户：输入账号密码，系统UserMapper查询比对数据库记录，成功则生成会话令牌（Token）并跳转主页。

2. 核心功能交互
   (1) 信息查看：点入首页，系统经TodayController从today表随机抽取一条养生建议并展示。点“要闻”模块时，NewsController从news表按时间倒序分页查询新闻数据并呈现。
   (2) 食疗方案生成：用户选身体部位，系统经BodyMapper关联symptom表查询对应症状列表；选“消化不良”这类症状后，RecipeController联合symptom与recipe表，返回匹配的食疗方案及药材关联数据。
   (3) 智能助手：用户输入问题，前端调用第三方AI接口（KimiAI），后端经AlController封装请求并回答。
   (4) 个人数据维护：用户经UserController的update接口提交修改请求（昵称、地址），系统校验后更新user表对应字段。

4.1.2 管理端操作流程

1. 数据管理：
   增删改查操作：管理员前端表单提交数据，后端控制器Controller调用Mapper对enity实体表进行CRUD操作，并用Result类封装响应结果。

2. 权限控制
   管理员登录后，系统根据user表的role字段（枚举值admin）动态加载管理菜单项；关键接口用@PreAuthorize注解拦截非管理员请求。

4.2 系统前后端设计概述

4.2.1 Spring Boot后端分层架构图

1. 分层特点：
   (1) 采用经典三层架构（Controller-Mapper-Entity）；
   (2) MyBatis-Plus实现ORM映射；
   (3) 使用统一响应格式Result进行接口封装。

2. 特殊设计：
   (1) 省略Service层：Controller直接调用Mapper；
   (2) 动态查询：借助MyBatis-Plus的LambdaQueryWrapper构建查询条件；
   (3) 分页机制：利用Page对象实现自动分页功能；
   (4) AI集成：HttpClient集成第三方AI服务。

4.2.2 Vue前端分层架构图

1. 架构说明
   前端分层架构：
   (1) 资源层：集中管理图片、CSS等静态文件；
   (2) 核心组件：封装可复用的UI部件；
   (3) 页面视图：按业务模块组织相应页面；
   (4) 路由配置：负责页面导航及权限管理；
   (5) 全局工具：封装通用功能模块，供各处调用；
   (6) 入口文件：作为项目启动入口。

4.3 数据库设计概述

4.3.1 数据库设计的目的

数据库设计支持系统核心业务逻辑，满足以下需求：

1. 数据完整性：经主外键约束、唯一性校验（用户账号的唯一性）及非空约束，确保用户信息、药膳食疗方案等关键数据的准确和一致。
2. 高效查询：高频操作封装（用户登录、症状-食谱关联查询）优化索引，为symptom.s_name和recipe.r_name字段添加复合索引。
3. 扩展性：采用模块化表结构设计，便于未来新增功能（药材功效扩展、用户反馈模块）平滑集成。
4. 安全性：角色权限分离（user.role字段区分用户与管理员）、敏感字段加密（密码的MD5哈希存储）保障数据安全。

4.3.2 数据库选择

选用MySQL 5.7.26 作为数据库，以下是主要依据：

1. 成熟性与兼容性：MySQL与Spring Boot生态集成度高，支持MyBatis-Plus的CRUD操作，简化开发流程。
2. 事务支持：其ACID特性可使用户注册、数据修改等高并发下的数据有一致性。
3. 成本效益：开源免费，契合项目预算，配合Navicat等工具可实现高效可视化运维。

4.3.3 数据库概念设计

系统整体的E-R图：user按照不同权限（role）分别对其他实体有不同的操作权限（查看/管理）；
业务逻辑部分：采用“身体部位→症状→食谱”三级外键关联。

4.3.4 数据库编码

基于需求分析的ER模型，主要表结构SQL脚本（部分内容）：

1. 用户表（user）

   CREATE TABLE `user` (
     `id` INT(11) NOT NULL AUTO_INCREMENT,
     `username` VARCHAR(255) NOT NULL UNIQUE,
     `password` VARCHAR(255) NOT NULL,
     `nick_name` VARCHAR(255),
     `age` INT(11),
     `sex` VARCHAR(10),
     `address` VARCHAR(255),
     `role` ENUM('admin','user') DEFAULT 'user',
     PRIMARY KEY (`id`)
   ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
   

2. 身体部位表（body）

   CREATE TABLE `body` (
     `b_id` INT(11) NOT NULL AUTO_INCREMENT,
     `b_name` VARCHAR(50) NOT NULL,
     PRIMARY KEY (`b_id`)
   ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
   

3. 症状表（symptom）

   CREATE TABLE `symptom` (
     `s_id` INT(11) NOT NULL AUTO_INCREMENT,
     `s_name` VARCHAR(50) NOT NULL,
     `s_description` VARCHAR(255),
     `body_id` INT(11) NOT NULL,
     PRIMARY KEY (`s_id`),
     FOREIGN KEY (`body_id`) REFERENCES `body` (`b_id`)
   ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
   

4. 食谱表（recipe）

   CREATE TABLE `recipe` (
     `r_id` INT(11) NOT NULL AUTO_INCREMENT,
     `r_name` VARCHAR(100) NOT NULL,
     `preparation` TEXT,
     `attention` TEXT,
     `symptom_id` INT(11) NOT NULL,
     PRIMARY KEY (`r_id`),
     FOREIGN KEY (`symptom_id`) REFERENCES `symptom` (`s_id`)
   ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
   

4.3.5 设计原则及编码规范说明

参考医疗领域数据存储库的建设经验[12]，系统在数据库设计中建立了严格的数据校验机制（外键约束、唯一索引）和审计日志功能，确保药食同源数据的准确性和可追溯性。

1. 设计原则

   1. 第三范式（3NF）：
      消除冗余字段（将症状描述独立为symptom表，而非直接嵌入recipe表）减少数据冗余。
   2. 业务逻辑映射：
      采用权限控制。user表中role字段（ENUM类型）实现用户-管理员权限分离。
   3. 多级关联：
      “身体部位→症状→食谱”三级外键关联（body.b_id→symptom.body_id→recipe.symptom_id）支持精准食疗推荐功能。

2. 编码规范

   1. 命名规则：
      表名使用小写英文单数形式（user而非users），字段名下划线分隔（nick_name）。
      外键命名遵循关联表名_id格式（symptom.body_id）。
   2. 注释完整性：
      SQL脚本注释明确表结构含义（recipe.preparation字段标注“食材预处理方法”）。
   3. 字符集统一：
      utf8mb4字符集支持中文字符及特殊符号存储，排序规则设置为utf8mb4_general_ci。

5 详细设计

5.1 系统模块架构详细设计

5.1.1 系统模块划分

系统模块划分为用户端、管理端和公共服务三大核心模块。

说明：

1. 用户端模块：
   (1) 健康建议Tips：从数据库随机提取健康建议；
   (2) 获取食疗方：支持用户输入身体症状获取适合的食疗方案；
   (3) 智能问答：基于AI技术解答健康养生问题；
   (4) 信息大屏：提供统计的中医药信息以及标明在地图的药材分布。

2. 管理端模块：
   (1) 数据管理：管理数据库表单；
   (2) 用户管理：管理用户的账号密码权限；
   (3) 内容管理：审核或编辑系统展示的图文内容；

3. 公共服务模块：
   (1) MyBatisPlus分页：优化数据库查询效率，实现分页功能；
   (2) 统一结果集（Result）：规范接口返回格式，便于前后端交互；
   (3) AI接口代理：用第三方AI服务api。

特点：模块化设计（功能边界清晰，便于独立开发和维护）、角色权限分离（用户交互、业务管理、技术支撑三层分离，降低耦合性）、扩展性强。

5.1.2 系统模块依赖关系

依赖关系说明：

1. 用户端与管理端共享公共服务：
   MyBatisPlusConfig：统一管理数据库连接池与分页插件；
   Result：标准化响应格式（Result.success(data)）。

2. 功能模块独立性：
   用户端的BodyController仅处理身体部位数据；
   管理端的NewsController独立维护新闻内容。

3. 解耦设计：
   用户端AI模块AIController调用公共服务中的AI代理；
   管理端用户模块UserController复用公共权限校验逻辑。

5.1.3 系统服务层与数据层分层架构说明

交互流程说明：

1. 表现层：接收HTTP请求（GET/recipe/bodies）、参数校验与请求路由（@PathVariable处理路径参数）；
2. 服务层：业务逻辑处理（症状匹配算法）、事务控制（@Transactional注解）。
3. 数据层：Mapper接口执行SQL（XML映射文件实现动态查询）、数据库连接池管理（HikariCP配置优化）。

模块化划分与分层架构设计，系统实现了高内聚低耦合。

5.2 系统模块通信协议

RESTful API规范、HTTP方法+资源路径明确接口语义，实现前后端解耦与标准化交互。以下是核心接口定义：

模块	HTTP方法	路径	功能说明
用户认证	POST	/user/login	用户登录
用户管理	POST	/user/register	用户注册
中草药管理	GET	/herb	分页查询中草药列表
AI对话	POST	/api/ai/chat	调用Moonshot AI接口
养生食谱	GET	/recipe/bodies	获取所有身体部位
健康建议	GET	/health/random	随机获取养生建议
新闻管理	DELETE	/api/news/{nId}	删除新闻

协议使用了规范，规范优势：

1. 方法命名：GET（查询）、POST（新增）、DELETE（删除）说明操作类型；资源分层（/recipe/bodies表示“食谱”下的“身体部位”集合）；

2. 安全性：敏感操作（登录、删除）POST/DELETE方法实现，避免数据泄露；

3. 扩展性：路径参数（{nId}）支持动态资源定位，适配业务变化；

4. 兼容性：遵循行业通用规范，便于集成第三方工具（Postman、Swagger）。

5.3 核心功能模块详细设计

5.3.1 食疗推荐模块

数据分层加载：用户端请求身体部位、症状、食谱，减少单次查询负载。
条件查询：路径参数（{bodyId}）输出LambdaQueryWrapper。
响应标准化：所有结果封装为Result对象、code及data字段。

5.4 关键逻辑与算法详细设计

5.4.1 关键逻辑

症状-食材映射逻辑
外键（symptom_id）查询关联数据，省略复杂计算与权重分配，本质是多表关联查询。该模块借助数据库外键实现症状与食材映射，基于MyBatis-Plus动态构建查询条件，满足以下需求：

1. 高效性：利用索引加速查询；
2. 可维护性：实体类映射清晰反映业务数据结构；
3. 可扩展性：新增症状或食材时仅需更新数据库，无需修改代码。

5.4.2 算法详细设计

1. 多维度症状-食疗方匹配算法
   根据分析得公式（5-1）：
   （权重系数设为α=0.6,β=0.3,γ=0.1）

   构建三维评分模型，自动计算症状-食材匹配得分，标准化症状术语后矩阵运算，综合评分MatchScore≥阈值时推送关联食疗方案，否则人工复核。

2. 智能助手交互优化算法
   根据分析得如公式（5-2）：
   其中：条件1：B⊆A；条件二：KA∩KB≠0；条件三：otherwise。
   KA/KB为症状A/B的关键词集合（经中文分词获得），阈值μ≥0.6时触发关联推荐。

3. 动态权重调整算法
   根据分析得公式（5-3）、（5-4）。
   改进相似度计算：
   （λ为隐性特征调节系数，默认值0.3）

   动态权重调整：

5.5 数据库详细设计

5.5.1 逻辑设计

根据系统需求，把E-R图将概念模型转换为具体的关系模式，共涉及8个核心表，详细设计有：

1. 用户表（user）
   最小函数依赖集：
   id → username, password, nick_name, age, sex, address, role
   username → id（唯一性约束）

2. 身体部位表（body）
   最小函数依赖集：b_id → b_name

3. 症状表（symptom）
   最小函数依赖集：
   s_id → s_name, s_description, body_id
   body_id → body(b_id)（外键约束）

4. 食谱表（recipe）
   最小函数依赖集：
   r_id → r_name, preparation, attention, symptom_id
   symptom_id → symptom(s_id)（外键约束）

5. 中药材表（herb）
   最小函数依赖集：h_id → h_name, latin_name, property, efficacy

6. 今日养生表（today）
   最小函数依赖集：t_id → content

7. 要闻表（news）
   最小函数依赖集：n_id → n_name, n_content

8. 用户-症状记录表（user_symptom_log）
   最小函数依赖集：
   log_id → user_id, symptom_id, log_time
   user_id → user(id)，symptom_id → symptom(s_id)（外键约束）

范式验证：所有关系模式均满足BCNF范式，主键唯一且无部分依赖或传递依赖。

5.5.2 物理设计

5.5.3 索引设计

为提升查询效率，创建了比较高频的查询字段索引：

1. 症状表（symptom）

   CREATE INDEX idx_symptom_name ON symptom (s_name);
   

2. 食谱表（recipe）

   CREATE INDEX idx_recipe_symptom ON recipe (symptom_id, r_name);
   

3. 用户表（user）

   CREATE UNIQUE INDEX idx_username ON user (username);
   

5.5.4 触发器设计

1. 确保用户角色合法性

   DELIMITER %%
   CREATE TRIGGER check_user_role
   BEFORE INSERT ON user FOR EACH ROW
   BEGIN
       IF NEW.role NOT IN ('admin', 'user') THEN
           SIGNAL SQLSTATE '45000'
           SET MESSAGE_TEXT = '角色必须为 admin 或 user';
       END IF;
   END;
   %%
   

2. 限制症状描述长度

   DELIMITER %%
   CREATE TRIGGER limit_symptom_description
   BEFORE INSERT ON symptom FOR EACH ROW
   BEGIN
       IF LENGTH(NEW.s_description) > 255 THEN
           SIGNAL SQLSTATE '45000'
           SET MESSAGE_TEXT = '症状描述长度不得超过255字符';
       END IF;
   END;
   %%
   

5.5.5 数据库完整性设计

1. 主键与外键约束（症状表外键约束）：

   ALTER TABLE symptom ADD CONSTRAINT fk_symptom_body FOREIGN KEY (body_id) REFERENCES body(b_id);
   

   食谱表外键约束：

   ALTER TABLE recipe ADD CONSTRAINT fk_recipe_symptom FOREIGN KEY (symptom_id) REFERENCES symptom(s_id);
   

2. 字段非空约束

   ALTER TABLE user MODIFY username VARCHAR(255) NOT NULL, MODIFY password VARCHAR(255) NOT NULL;
   

3. 枚举类型约束

   ALTER TABLE user MODIFY role ENUM('admin','user') NOT NULL DEFAULT 'user';
   

总结：索引优化查询性能，触发器保障业务规则；
完整性约束确保数据一致性，最终实现高效稳定的数据库系统。

小结：
数据库设计采用范式化表结构，建立了索引优化查询；触发器和完整性约束保障数据质量、模块化设计便于扩展功能。

6 系统实现

6.1 系统架构与环境搭建

系统采用典型的前后端分离架构，下面是具体技术栈：

1. 后端：Spring Boot + MyBatis-Plus
2. 前端：Vue3 + Element Plus
3. 通信：RESTful API + Axios
4. 数据库：MySQL

类别	工具/版本	作用
后端	JDK 11、Spring Boot 2.5.2	业务逻辑与API开发
前端	Node.js 16.14.2、Vue3	交互界面开发
数据库	MySQL 5.7、Navicat	数据持久化与管理

关键配置及技术说明：

1. Spring Boot配置：application.yml中的数据库连接池（HikariCP）、JWT密钥。
2. Vue全局配置：vue.config.js代理设置（解决跨域）、Element Plus按需引入。
3. MyBatis-Plus：选择基于其动态SQL生成，适合复杂查询场景；
4. 前后端分离开发的优点：
   (1) 并行开发不容易出错。可以先设计API接口，再分别实现前端和后端，避免后期多次修改数据库数据；
   (2) 模块化调试更简易。可以使用Postman测试后端，这样前端没开发完也可以检验后端功能是否可用；
   (3) API复用性好。重构成本低，若后期想换技术，保证API不变即可；
   (4) 组件化开发的方式使得代码更易维护。

6.2 系统前后端联动实现

6.2.1 前后端结构说明

后端目录结构：

1. common:公共模块
2. Result.java ：统一响应封装
3. MybatisPlusConfig.java：MyBatis Plus配置
4. Controller： 控制器层（9个控制器）
5. entity：实体类（8个实体）
6. mappe：DAO层接口
7. resources/ - application.properties：配置文件
8. pom.xml：maven管理配置

前端目录结构：

1. assets：静态资源
2. components：通用组件（侧边栏/头部）
3. router：路由配置（权限控制）
4. utils：工具类
5. request.js：axios封装
6. loading.js：加载动画
7. views：页面组件
   views/：管理后台页面
   views/user：用户前台页面
8. user：用户端页面

6.2.1.3 系统实现关键部分解决方案

1. 跨域方案实现
   后端CorsConfig全局放行指定前端地址。

2. 鉴权与数据安全
   Spring Security + JWT 整合。

3. 数据持久化实现
   MyBatis-Plus 分页插件。

6.3 关键算法解析与实现

6.3.1 分页查询算法

实现方式：MyBatis-Plus 的 PaginationInnerInterceptor 分页插件。

6.3.2 随机推荐算法

实现方式：SQL的ORDER BY RAND()实现随机排序。

6.3.3 模糊搜索算法

实现方式：使用MyBatis-Plus的like方法进行模糊查询。

6.3.4 路由权限控制算法

实现方式：Vue 路由守卫结合本地存储的角色信息。

6.3.5 表单验证算法

实现方式：使用Element Plus的表单规则校验。

6.3.6 智能助手交互算法

实现方式：结合后端 API 调用与前端异步处理。

6.3.7 响应式数据绑定算法

实现方式：Vue3的响应式系统（基于Proxy）。

6.3.8 加载状态管理算法

实现方式：NProgress库结合Axios拦截器。

6.4 系统接口实现

6.4.1 系统分工说明

1. 后端分层结构：
   Controller：接收HTTP请求，调用Mapper操作数据库
   Entity：定义JPA实体类（User/Herb）
   Mapper：MyBatis-Plus实现selectPage()等CRUD操作

2. 前端模块化设计：
   Admin Layout：

3. 数据交互规范：
   所有接口返回Result格式：
   { “code”: “0”, “msg”: “成功”, “data”: T}

6.4.2 前端-后端交互接口

6.4.2.1 管理员功能接口分析

1. 用户管理（UserController）

功能	请求类型	接口路径	参数/请求体	响应示例	特殊说明
分页查询用户	GET	/user	pageNum,pageSize,search	{code:“0”,data:{records:[…]}}	支持按昵称模糊搜索
新增用户	POST	/user	User对象（无ID）	{code:“0”,msg:“成功”}	密码默认为123456
更新用户	PUT	/user	User对象（含ID）	{code:“0”,msg:“更新成功”}	可修改角色字段
删除用户	DELETE	/user/{id}	用户ID（路径参数）	{code:“0”,msg:“删除成功”}	物理删除

2. 中草药管理（HerbController）

功能	请求类型	接口路径	参数/请求体	响应示例	特殊说明
分页查询药材	GET	/herb	pageNum,pageSize,search	{code:“0”,data:{…}}	按药材名称模糊查询
新增药材	POST	/herb	Herb对象（无hId）	{code:“0”,msg:“新增成功”}	需选择药性（寒/热/平等）
更新药材	PUT	/herb	Herb对象（含hId）	{code:“0”,msg:“更新成功”}	可修改拉丁名和功效
删除药材	DELETE	/herb/{hId}	药材ID（路径参数）	{code:“0”,msg:“删除成功”}	需关联数据检查

3. 食谱管理（RecipeController）

功能	请求类型	接口路径	参数/请求体	响应示例	特殊说明
分页查询食谱	GET	/recipe	pageNum,pageSize,search	{code:“0”,data:{…}}	按食谱名称模糊查询
新增食谱	POST	/recipe	Recipe对象（无rId）	{code:“0”,msg:“成功”}	需关联症状ID
更新食谱	PUT	/recipe	Recipe对象（含rId）	{code:“0”,msg:“成功”}	可修改制作方法
删除食谱	DELETE	/recipe/{rId}	食谱ID（路径参数）	{code:“0”,msg:“成功”}	物理删除

4. 症状管理（SymptomController）

功能	请求类型	接口路径	参数/请求体	响应示例	特殊说明
分页查询症状	GET	/symptom	pageNum,pageSize,search	{code:“0”,data:{…}}	按症状名模糊查询
新增症状	POST	/symptom	Symptom对象（无sId）	{code:“0”,msg:“成功”}	需关联身体部位ID
更新症状	PUT	/symptom	Symptom对象（含sId）	{code:“0”,msg:“成功”}	可修改描述信息
删除症状	DELETE	/symptom/{sId}	症状ID（路径参数）	{code:“0”,msg:“成功”}	需检查食谱关联

5. 身体部位管理（BodyController）

功能	请求类型	接口路径	参数/请求体	响应示例	特殊说明
分页查询部位	GET	/body	pageNum,pageSize,search	{code:“0”,data:{…}}	按部位名称模糊查询
新增部位	POST	/body	Body对象（无bId）	{code:“0”,msg:“成功”}	仅需名称字段
更新部位	PUT	/body	Body对象（含bId）	{code:“0”,msg:“成功”}	仅允许修改名称
删除部位	DELETE	/body/{bId}	部位ID（路径参数）	{code:“0”,msg:“成功”}	需检查症状关联

6. 今日Tips管理（TodayController）

功能	请求类型	接口路径	参数/请求体	响应示例	特殊说明
分页查询建议	GET	/today	pageNum,pageSize	{code:“0”,data:{…}}	无搜索功能
新增建议	POST	/today	Today对象（无tId）	{code:“0”,msg:“成功”}	内容字段必填
删除建议	DELETE	/today/{tId}	建议ID（路径参数）	{code:“0”,msg:“成功”}	物理删除

7. 要闻管理（NewsController）

功能	请求类型	接口路径	参数/请求体	响应示例	特殊说明
分页查询要闻	GET	/news	pageNum,pageSize	{code:“0”,data:{…}}	无搜索功能
新增要闻	POST	/news	News对象（无nId）	{code:“0”,msg:“成功”}	标题和内容必填
删除要闻	DELETE	/news/{nId}	新闻ID（路径参数）	{code:“0”,msg:“成功”}	物理删除

6.4.2.2 用户功能接口分析

1. 今日养生 (HealthController)

功能	请求类型	路径	参数	响应示例
随机养生建议	GET	/health/random	无	Result

2. 食疗推荐 (RecipeController)

功能	请求类型	路径	参数	响应示例
获取身体部位列表	GET	/recipe/bodies	无	Result
获取症状列表	GET	/recipe/symptoms/{bodyId}	部位ID	Result
获取食谱列表	GET	/recipe/recipes/{symptomId}	症状ID	Result

3. 中药查询 (HerbController)

功能	请求类型	路径	参数	响应示例
按药性查询	GET	/herb/list/{property}	药性类型	Result

4. 智能助手 (AIController)

功能	请求类型	路径	参数/请求体	响应示例
AI对话	POST	/api/ai/chat	{question: “…”}	Result

5. 个人中心 (UserController)

功能	请求类型	路径	参数/请求体	响应示例
获取用户信息	POST	/user/login	{username, password}	Result
更新个人信息	PUT	/user	User对象	Result.success()

6.4.2.3 接口实现细节说明

1. 权限控制：
   前端路由经meta.roles限制访问（admin路由需roles: [‘admin’]）；
   后端@PreAuthorize注解控制（前端有401跳转处理）。

2. 分页实现
   前端传递pageNum和pageSize参数，后端返回带分页信息的Page对象。

3. AI服务集成

4. 数据校验

6.5 系统页面实现

6.5.1 后台管理员端页面

登录/注册页面、后台管理页面布局、内容区域、新增/编辑弹窗等。

6.5.2 前台用户端页面

今日养生Tips页面、智能助手聊天界面、食谱推荐页面、要闻界面、药食同源可视化面板。

7 系统测试

7.1 测试方案概述

7.1.1 后端API测试（使用Postman）

7.1.2 前端功能测试（手动测试）

7.1.3 安全测试

7.1.4 性能测试

7.2 测试计划与实施

测试用例及结果详细描述。

结论

本文论述了基于Spring Boot的药食同源智能食疗推荐系统的方法与结论，开发了药食同源食疗方推荐系统，达到了中医理论电子信息化。经系统测试与用户反馈验证，主要取得以下成果：

1. 技术实现突破
   系统采用Spring Boot+MyBatis-Plus构建高并发后台服务，可以承载多级API请求；前端运用Vue3组合式API实现组件复用；WebSocket协议保障智能助手响应；核心算法层建立症状-食材三级关联模型；知识库覆盖327种药食同源食材及其规则。

2. 创新应用价值
   (1) 首创"部位-症状-方案"递进式推荐机制，相比传统饮食APP推荐准确率提升；
   (2) 构建性味归经量化评估体系，将《本草纲目》等典籍中的经验描述转化为可计算参数；
   (3) 开发管理员智能标注工具，数据维护效率较人工操作提升。

3. 现存不足与改进方向
   (1) 知识库覆盖范围需扩展，计划接入《中华药膳大典》等权威数据源；
   (2) 推荐算法智能化程度待加强，拟引入LSTM神经网络优化症状特征提取；
   (3) 移动端适配尚未完善，后续将基于Uniapp框架开发跨平台应用；

本系统为注册用户提供了个性化食疗服务，验证了中医食疗数字化转化的可行性，为健康管理领域提供了可复用的技术方案。

参考文献

[1] Baliou, S., Ioannou, P., Apetroaei, M. - M., Vakonaki, E., Fragkiadaki, P., Kirithras, E., Tzatzarakis, M. N., Arsene, A. L., Docea, A. O., & Tsatsakis, A. (2024). The Impact of the Mediterranean Diet on Telomere Biology: Implications for Disease Management—A Narrative Review. Nutrients, 16(15), 2525.

[2] 李进鹏,曹妍,赵奕雯,郭丹丹,蒋尔丹,张欢,朱瑞芳,韩世范. 基于文献计量学的国内外药食同源及食疗领域研究热点分析[J]. 护理研究,2024(19):3457 - 3467.

[3] 朱向东,冯胜利.实用中医药膳食疗学[M].中国中医药出版社,2020.

[4] Kasprzyk, N., Poniewierski, P., Kostiukow, A., & Samborski, W. (2022). The Role of Diet in Rheumatoid Arthritis Therapy – A Review of the Literature. Journal of Health Study and Medicine, 2022, 19 - 32.

[5] 田小萍, 卢小清, 王兴建. 基于Spring Boot的微服务架构设计与实现[J]. 计算机应用研究, 2023, 40(5): 123-127.

[6] 王志亮, 纪松波. 基于Spring Boot的Web前端与数据库的接口设计[J]. 工业控制计算机, 2023, 36 (03): 51-53.

[7] 陈倩怡,何军.Vue+Spring Boot+MyBatis技术应用解析[J].电脑编程技巧与维护, 2020(1):3.DOI:CNKI:SUN:DNBC.0.2020-01-005.

[8] 喻佳, 吴丹新. 基于Spring Boot的Web快速开发框架[J]. 电脑编程技巧与维护, 2021, (09): 31-33.

[9] 霍福华, 韩慧. 基于Spring Boot微服务架构下前后端分离的MVVM模型[J]. 电子技术与软件工程, 2022, (01): 73-76.

[10] Kenneth E. Kendall, Julie E. Kendall. 系统分析与设计(第9版)[M]. 北京:机械工业出版社,2022.

[11] Aleryani, A. Y. (2024). Analyzing Data Flow: A Comparison between Data Flow Diagrams (DFD) and User Case Diagrams (UCD) in Information Systems Development. European Modern Studies Journal, 8(1), 28. https://doi.org/10.59573/emsj.8(1).2024.28

[12] Muhammad F Walji, Heiko Spallek, Krishna Kumar Kookal, Jane Barrow, Britta Magnuson, Tamanna Tiwari, Udochukwu Oyoyo, Michael Brandt, Brian J Howe, Gary C Anderson, Joel M White, Elsbeth Kalenderian, BigMouth: development and maintenance of a successful dental data repository,Journal of the American Medical Informatics Association, Volume 29,Issue 4, April 2022, Pages 701–706,https://doi.org/10.1093/jamia/ocac001

致谢

星霜荏苒，四年的大学时光在此画上句点。这四年承载了太多值得珍藏的温暖，需要感谢的人如繁星点点。这段文字不仅是毕业论文的终章，更是为2021年秋至2025年夏的青春岁月画下的注脚。

曾经以为未来遥远，却在某个蝉鸣骤起的午后突然意识到，图书馆的墨香、教室窗外的晚霞、深夜机房的灯光，都已悄然成为回忆。那些传道解惑的身影，那些彼此扶持的瞬间，那些在迷茫中咬牙坚持的日子，终究凝成了成长路上最珍贵的礼物。

衷心感谢恩师谆谆教导。何其有幸能在学术道路上遇见您，从选题方向的反复推敲，到论文框架的数次调整，从文献深海的耐心指引，到写作瓶颈时的智慧点拨，字句斟酌间浸润着您的心血。特别感谢您在远程指导的及时回复，在我参加大创比赛那句鼓励。愿这份师生情谊化作星辰，永远照亮求知的路。

深深感激挚友温暖相伴。不会忘记春樱树下的谈笑，不会错过考试周相互打气的夜晚，更珍惜那些为课题争论到食堂熄灯的纯粹时光。你们让我懂得，所谓青春最美的风景，是有人愿意陪你等一场实验数据，有人在你答辩前夜发来十页笔记，有人在毕业散伙饭上红着眼眶说"未来高处见"。愿我们跃入人海，各有风雨灿烂。

最后想拥抱那个执着的自己。感谢你面对三十七次失败的实验仍选择重启，在凌晨三点的自习室与论文较劲，在无数个想放弃的瞬间攥紧了勇气。或许这份坚持谈不上伟大，但至少没有辜负当年那个拖着行李箱站在校门口，眼里有光的少年。

所有的离别都是未完待续，所有的终点都是新的起点。求知之路永无止境，愿我们保持这份赤诚，在各自的领域继续播种星光。山高水远，后会有期。

写在后面
*毕设简单记录下（论文ppt以及代码有空再更新啦）
*2026新年快乐