摘要

随着现代医疗技术的不断发展，慢性病的管理需求日益增加。为了更好地服务慢性病患者，医院需要借助信息化手段进行有效管理。基于SpringBoot框架的医院慢性病管理系统，结合了前端用户交互与后端数据处理功能，旨在提供一种高效、便捷的管理平台。该系统主要分为管理员、患者和医生三种用户角色，每个角色拥有不同的功能模块。管理员可通过系统进行患者数据管理、健康计划制定、咨询管理等操作，确保医院的运营效率和患者的健康监测。患者用户可查看个人信息、健康数据、咨询医生等，医生则可管理患者的健康记录、日常检测数据，并提供专业的咨询服务。系统通过数据分析和健康计划功能，为患者提供定制化的健康管理服务，提高慢性病患者的生活质量。

本系统采用SpringBoot作为开发框架，具备良好的扩展性和高效性，能够满足现代医院对慢性病管理的需求。系统设计简洁易用，具有较高的稳定性和安全性，是提升慢性病管理水平的有力工具。

关键词：SpringBoot；医院管理；慢性病；患者管理；健康计划；数据分析

Abstract

With the continuous development of modern medical technology, the demand for chronic disease management is increasing day by day. In order to better serve chronic disease patients, hospitals need to use information technology for effective management. The hospital chronic disease management system based on the SpringBoot framework combines front-end user interaction and back-end data processing functions, aiming to provide an efficient and convenient management platform. The system is mainly divided into three user roles: administrator, patient, and doctor, each with different functional modules. Administrators can perform patient data management, health plan development, consultation management, and other operations through the system to ensure the operational efficiency of the hospital and patient health monitoring. Patient users can view personal information, health data, consult doctors, etc. Doctors can manage patients' health records, daily testing data, and provide professional consulting services. The system provides customized health management services to patients through data analysis and health planning functions, improving the quality of life of chronic disease patients.

This system adopts SpringBoot as the development framework, which has good scalability and efficiency, and can meet the needs of modern hospitals for chronic disease management. The system design is simple and easy to use, with high stability and safety, and is a powerful tool for improving the level of chronic disease management.

Key words: SpringBoot； Hospital management; Chronic diseases; Patient management; Health plan; data analysis

目录

摘要

Abstract

1 绪论

1.1 研究背景和意义

1.2 国内外研究现状

1.3 研究目标与内容

1.4 论文结构与章节安排

2 相关技术介绍

2.1 B/S框架

2.2 SpringBoot框架

2.3 Vue技术

2.4 MySQL数据库

3 需求分析

3.1 可行性分析

3.1.1 技术可行性

3.1.2 经济可行性

3.1.3 操作可行性

3.2 系统性能分析

3.3 功能需求分析

3.3.1 患者用户功能

3.3.2 管理员功能

3.3.3 医生用户功能

3.4 系统流程分析

3.4.1 程序操作流程

3.4.2 登录流程

3.4.3 注册流程

4 系统设计

4.1 系统架构设计

4.2 系统总体功能设计

4.3 数据库设计

4.3.1 数据库实体设计

4.3.2 数据库表设计

5 系统实现

5.1 患者用户功能实现

5.1.1 用户注册

5.1.2 用户登录

5.1.3 患者信息

5.1.4 健康知识

5.1.5 日常检测

5.2 管理员功能实现

5.2.1 角色管理

5.2.2 患者信息管理

5.2.3 日常检测管理

5.2.4 健康计划管理

5.2.5 系统管理

5.2.6 系统公告管理

5.3 医生用户功能实现

5.3.1 日常检测

5.3.2 健康计划

5.3.3 咨询医生

6 系统测试

6.1 测试目的

6.2 测试方法

6.3 测试内容

6.4 测试结果

7 总结

参考文献

致谢

附录

系统核心代码设计

用户注册

用户登录

修改密码

修改数据

删除数据

获取列表

图片上传

1 绪论

1.1研究背景和意义

随着社会老龄化进程的加快，慢性病患者的数量逐年增加，慢性病的管理面临着巨大的挑战。慢性病不仅对患者的健康造成严重影响，也给家庭和社会带来了沉重的负担。传统的慢性病管理方式往往依赖人工记录和管理，效率低、易出错，难以满足日益增长的管理需求。随着信息技术的飞速发展，基于现代化信息管理平台对慢性病进行精准管理成为一种必然趋势。

在此背景下，医院慢性病管理系统的研究显得尤为重要。该系统旨在通过信息化手段提升慢性病的管理水平，使医院能够更加高效地为患者提供个性化的健康服务。通过集成患者信息管理、健康计划管理、检测数据管理以及医患沟通等功能，能够实时跟踪患者的健康状态，及时调整治疗方案，确保患者获得更好的治疗效果和生活质量。对医院而言，这种管理模式不仅提高了运营效率，也增强了患者对医院服务的满意度和信任度。

医院慢性病管理系统的研究与开发，不仅有助于医院提升慢性病管理的规范化、精细化水平，还能够推动医院信息化建设的发展，为未来更多疾病的管理提供借鉴和支持。通过该系统的实施，可以显著减少人工操作的误差，提升数据处理效率，并为慢性病患者提供更加科学、合理的健康管理方案。

1.2国内外研究现状

随着慢性病患者数量的不断增加，国内外研究者在医院慢性病管理系统领域进行了广泛的探索和研究。在国内，许多医院和科研机构开始重视慢性病管理的信息化建设，推出了不同类型的慢性病管理平台。国内的研究多聚焦于如何通过信息化手段提升慢性病管理的效率，主要涉及患者数据的数字化管理、健康档案的建立、医患沟通的便利化等方面。一些系统通过集成电子病历、患者健康记录以及治疗方案管理，努力实现个性化的慢性病管理。然而，许多现有系统仍面临着数据标准化不足、系统兼容性差、以及用户界面不够友好等问题。

国外在医院慢性病管理系统方面的研究起步较早，相关研究更注重于系统的智能化与全面性。国外的研究通常强调多学科的协同工作，如医学、信息技术与健康管理的深度融合。多个国际医疗机构已经部署了智能化的慢性病管理系统，系统不仅能有效整合患者的健康数据，还通过智能算法进行治疗方案的优化，帮助医生更好地进行决策。与此同时，国外的系统设计也更加注重患者体验，强调系统操作的简便性与互动性。

无论是国内还是国外，尽管在慢性病管理系统的研究与实践中取得了一定进展，仍然存在数据安全性问题、患者隐私保护难度大、系统稳定性和可扩展性不足等挑战。这些问题的解决需要进一步加强技术的创新与跨领域合作，为慢性病患者提供更为高效、安全的管理服务。

1.3研究目标与内容

医院慢性病管理系统的研究目标主要是通过信息技术的应用提升慢性病患者的健康管理水平，优化医院管理流程，提供高效的医疗服务。研究的核心在于如何通过一个集成化平台，帮助医院实现对慢性病患者的全面管理。系统不仅需要具备高效的数据处理能力，还要能够支持个性化的健康管理方案，提升患者的治疗效果与生活质量。

研究内容包括医院慢性病管理系统的功能设计、架构规划及技术实现。功能设计方面，系统需要涵盖患者信息管理、健康计划制定、日常健康检测、医患互动、数据分析等模块，确保信息的流畅传递与实时更新。架构规划上，系统需要采用高效的开发框架，保证系统的扩展性和稳定性，便于医院在未来的应用与扩展。技术实现则侧重于如何通过信息化手段有效整合医院的各项数据，提升管理效率，减少人工干预的错误，确保数据安全与隐私保护。

研究还将探索如何使系统在提高医院运营效率的同时，增强患者的使用体验。系统设计应简洁、易用，方便患者与医生之间的互动，同时能够有效支持医院的管理决策，推动医院信息化管理水平的提升。

通过这一研究，旨在为医院慢性病管理提供一种高效、安全、可扩展的解决方案，推动慢性病管理模式的转型和升级，最终实现患者健康管理的科学化和个性化。

1.4论文结构与章节安排

本文共分为六章，章节内容安排如下：

第一章为绪论，此章节对所设计和实现的系统的背景和意义以及国内外研究现状等进行详细的论述以及说明，同时进行了论文整体框架的结构的简要介绍。

第二章相关技术介绍，研究了系统的所采用的开发技术。

第三章为系统分析，章节所做的主要的工作是对系统进行了技术、经济和操作方面可行性的分析；对系统实行了总体功能的需求、用例分析。

第四章为系统的设计，主要是对系统的功能结构进行设计，并对系统数据库的概念结构以及物理结构的设计进行了分析。

第五章就是对系统的实现，根据系统功能的划分，分别的对系统所需要实现的功能进行了分析和说明。

第六章：系统测试。主要对系统的部分界面进行测试并对主要功能进行测试

最后：总结。

2 相关技术介绍

2.1B/S框架

B/S（Browser/Server）架构是一种基于浏览器和服务器的应用架构模式。它以Web浏览器作为客户端，服务器端通过Web技术提供应用服务。客户端通过浏览器与服务器进行交互，用户无需安装专门的客户端应用程序，只需要通过互联网连接即可访问应用程序[1]。在B/S架构中，客户端主要承担用户界面的呈现和基本的输入输出功能，而核心的业务处理、数据存储等操作则由服务器端完成。这种架构的核心优势在于无需在每个客户端机器上安装或更新软件，只要用户的浏览器符合要求，就可以使用系统。

B/S（Browser/Server）架构是一种网络架构模型，其主要特点是客户端通过浏览器与服务器进行通信，所有的业务逻辑和数据处理都在服务器端完成，客户端仅负责展示数据[2]。B/S架构本质上是一种客户端-服务器模式的变体，它通过将传统的C/S（Client/Server）架构中的客户端功能移到浏览器中，简化了客户端的开发和维护工作。在B/S架构中，用户通过浏览器发送请求，浏览器负责展示从服务器获取的数据，服务器则处理请求并返回响应。该架构避免了安装和配置客户端软件的麻烦，也减少了对客户端硬件的依赖，适合于需要大规模部署和跨平台支持的应用系统。

B/S模式三层结构图如图2-1所示。

图2-1  B/S模式三层结构图

2.2 SpringBoot框架

SpringBoot是一个用于简化Spring应用开发的开源框架，通过减少开发人员配置和依赖的复杂性，使得开发者能够快速构建基于Spring的生产级应用。SpringBoot基于Spring框架之上，提供了一种自配置的方式，使得开发者可以以最少的配置来启动和开发Spring应用[3]。它通过约定优于配置的原则，将常见的配置预设，使得开发人员能够聚焦于业务逻辑的实现，而不必过多关注繁琐的配置和环境搭建。

SpringBoot框架的核心特点之一是其自动配置功能。它能够根据项目中已存在的类和库，自动推断出开发环境的配置需求，减少了手动配置的工作量。SpringBoot还提供了嵌入式Web服务器支持（如Tomcat、Jetty等），使得应用可以以独立的Java应用形式运行，不再依赖外部的Web容器。这种特性使得SpringBoot特别适合于微服务架构的构建。SpringBoot还通过其提供的启动器（Starters）简化了常见功能的集成，例如数据库连接、消息队列、缓存、认证与授权等，从而提升了开发效率[4]。

2.3 Vue技术

Vue.js是一款用于构建用户界面的渐进式JavaScript框架，提供一种灵活而高效的方式来开发单页面应用（SPA）。Vue的设计理念是通过尽量简化开发过程，提供一种声明式的方式来构建用户界面[5]。Vue.js通过数据驱动的视图模型，允许开发者以声明式语法绑定数据与视图，使得应用的状态和界面表现更加简洁和可维护。它的核心思想是通过组件化开发将复杂的UI拆分为可重用的独立模块，从而提升了代码的模块化、可维护性和可扩展性。

Vue.js具备响应式数据绑定和虚拟DOM的特性。响应式数据绑定意味着当数据变化时，Vue会自动更新与之绑定的DOM元素，从而实现视图的实时更新。虚拟DOM则是Vue.js的一种优化手段，通过将对DOM的操作抽象为一个虚拟的DOM树来提高性能，减少实际DOM操作的开销[6]。Vue还提供了丰富的插件和工具，如Vue Router用于路由管理，Vuex用于状态管理，方便开发者构建复杂的前端应用。Vue的灵活性和简洁性使其成为现代Web开发中常用的前端框架之一。

2.4 MySQL数据库

MySQL是一种开源的关系型数据库管理系统（RDBMS），基于SQL（结构化查询语言）进行数据操作。作为一个被广泛使用的数据库系统，MySQL具有高度的性能、可扩展性和可靠性。MySQL使用表格结构来存储数据，每个表由多个列和行组成，数据通过SQL查询语言进行操作[7]。MySQL支持多种数据类型，如整数、浮动小数、字符串、日期等，以满足不同应用场景对数据存储的需求。在实际应用中，MySQL通常用于存储和管理结构化数据，通过索引、视图、触发器等功能提升数据查询的效率和数据的完整性。

MySQL支持ACID事务特性（原子性、一致性、隔离性、持久性），确保数据库操作的可靠性和数据的一致性。它还支持多种存储引擎，其中InnoDB是最常用的存储引擎，具备事务支持、行级锁定和外键约束等特性，适用于高并发、高可靠性的数据存储需求。MySQL可以通过主从复制、分区和分库分表等技术实现横向扩展，以应对大规模数据存储和高负载的应用需求。MySQL还具有灵活的权限管理机制，支持用户角色管理、细粒度的权限控制等，保障数据的安全性。

3 需求分析

3.1可行性分析

3.1.1技术可行性

从技术角度来看，Spring Boot作为一种轻量级、快速构建的Java框架，能够提高开发效率，降低系统的复杂程度，易于维护和升级。同时，MySQL作为关系型数据库，能够支持平台数据的存储与管理，保障系统的稳定性和高效性。因此，本系统具有技术可行性。

3.1.2经济可行性

考虑到Springboot、Vue、MyBatis Plus及MySQL等均为开源技术，无需支付高昂的许可费用，大大降低了系统的开发成本。同时，这些技术拥有广泛的用户群体和成熟的社区支持，便于获取技术支持和资源共享。此外，系统的实施将显著用户体验，从而带来潜在的经济效益。因此，从经济角度来看，该系统的开发同样具备可行性。

3.1.3操作可行性

系统设计应遵循用户友好原则，确保用户能够轻松上手并高效使用。通过合理的界面布局、直观的操作流程以及详尽的帮助文档，可以大大降低用户的学习成本，提高系统的操作可行性。此外，系统还应具备完善的权限管理和数据安全机制，确保操作的安全性和合规性。

3.2系统性能分析

对于医院慢性病管理系统，下面是系统性能分析表：

表3.1性能需求表

项目	内容
响应时间	系统对用户请求的响应时间需在500ms以内
并发用户数	系统需要支持1000个并发用户同时访问
吞吐量	系统每秒需要处理1000个请求
可用性	系统需要保证每月99.9%的可用性
数据安全	用户敏感数据需要加密存储，并支持数据库备份和恢复
数据一致性	系统中的数据操作需保证ACID特性，确保数据一致性
扩展性	系统需要支持水平扩展，能够方便地增加服务器节点以应对高请求量
可维护性	系统代码需要清晰易懂、结构良好，方便维护和修改
日志记录	系统需要记录用户操作日志、异常日志以及系统运行日志
监控报警	系统需要实时监控运行状态，当系统异常时能够及时发送警报通知相关人员
缓存设置	针对频繁使用的数据，系统需要进行合适的缓存

3.3功能需求分析

功能需求分析是对系统所需功能进行详细描述的过程，明确系统的目标、功能模块及其相互关系。在此阶段，结合用户需求、业务流程和技术架构，识别系统必须实现的各项功能，并对其优先级、实现方式和约束条件进行梳理。通过功能需求分析，确保系统设计能够满足实际需求，且具有良好的可用性、可维护性和扩展性，为后续的系统开发和测试提供明确的指导和依据。

3.3.1患者用户功能

首页：患者登录后进入系统首页，查看最新的系统公告、健康知识和新闻动态，快速获取与自己健康相关的信息。

系统公告：患者可以查看医院发布的各类公告，了解医院的最新安排、政策以及健康管理服务的更新。

健康知识：系统提供丰富的健康知识资源，患者可以通过该功能学习关于慢性病管理、饮食、运动等方面的知识，帮助提高自我保健能力。

患者信息：患者可以在系统中查看和更新自己的个人信息，包括基本信息、就诊记录和健康档案等，确保信息的准确性。

日常检测：患者可以记录和查看自己的日常健康检测数据，如体重、血糖、血压等，便于长期跟踪自身健康状况。

个人账户：患者通过个人账户管理自己的系统登录信息、密码、联系方式等，保障账户的安全性。

个人中心：在个人中心，患者可以查看自己的详细信息，包括个人首页、健康计划、日常检测数据等。同时，患者可以通过该功能与医生进行在线咨询，获取医疗建议。

健康计划：患者能够查看和跟踪由医生或管理员为自己制定的健康管理计划，及时了解自己的健康目标和干预措施。

咨询医生：患者可以通过系统与医生进行在线咨询，提出自己的健康问题，获得医生的指导。

咨询回复：患者可以查看医生对其咨询的回复内容，确保得到专业、及时的解答。

患者用户用例图如图3-1所示。

图3-1 患者用户用例图

3.3.2管理员功能

数据分析：管理员可以通过系统提供的数据分析工具，对患者的健康数据、治疗效果和日常检测数据进行详细分析。这些分析结果为医院的管理决策提供数据支持，帮助评估慢性病管理效果并作出相应调整。

角色管理：管理员可以设置和管理系统中的用户角色，包括患者、医生等，赋予不同的权限，确保每个用户仅能访问与其角色相关的数据和功能。

患者信息管理：管理员可以查看、编辑和更新患者的个人信息、健康记录以及治疗历史。通过这一功能，管理员能够确保患者信息的准确性和完整性。

日常检测管理：管理员可以查看患者的日常健康监测数据，如血糖、血压等，帮助医院及时掌握患者的健康状况，为医生提供准确的临床数据支持。

健康计划管理：管理员可以制定和调整患者的健康计划，确保慢性病患者得到个性化的健康指导和干预方案。

咨询医生管理：管理员负责管理患者与医生之间的咨询记录，确保患者能够及时得到医生的专业建议，并对咨询内容进行存档和管理。

咨询回复管理：管理员可以查看医生对患者咨询的回复，确保咨询过程中的信息流畅和及时。

系统管理：管理员可以对系统中的轮播图、公告、新闻等进行管理，确保医院的最新信息及时传达给患者和医生。

新闻管理：管理员可以发布与健康知识相关的新闻，分类并管理这些信息，为患者提供有价值的健康科普内容。

管理员用例图如图3-2所示。

图3-2管理员用例图

3.3.3医生用户功能

首页：医生登录后进入系统首页，查看最新的系统公告、健康知识和新闻动态，随时了解医院和健康管理领域的更新信息。

系统公告：医生可以查看医院发布的公告，及时掌握医院的政策变动和工作安排。

健康知识：医生可以在系统中发布或管理健康知识内容，为患者提供科学、权威的健康指导。

个人账户：医生可以管理自己的账户信息，如登录名、密码、联系方式等，确保账户安全性。

个人中心：在个人中心，医生可以查看自己的工作任务、患者健康记录、日常检测数据等，确保医疗工作的顺利开展。

患者信息：医生可以查看所负责患者的详细信息，包括健康档案、治疗记录、检测数据等，以便为患者制定个性化的治疗方案。

日常检测：医生可以查看患者的日常健康检测数据，进行分析并根据检测结果调整治疗计划。

健康计划：医生可以为患者制定个性化的健康管理计划，确保患者获得科学的治疗和健康干预。

咨询医生：医生可以通过系统与患者进行在线咨询，解答患者的健康问题，并提供专业的医学建议。

咨询回复：医生可以查看患者的咨询内容并作出回复，确保患者得到及时、有效的医疗服务。

医生用户用例图如图3-3所示。

图3-3医生用户用例图

3.4系统流程分析

3.4.1程序操作流程

用户访问系统，可以选择进行注册或登录操作。注册成功后，用户可以使用注册的账号登录系统。登录后的用户可以进入系统功能界面，使用自己权限内的功能操作。程序操作流程图如图3-4所示。

图3-4 程序操作流程图

3.4.2登录流程

用户访问系统，进入登录页面页面，入其用户名和密码，后端服务接收登录请求，验证用户提供的用户名和密码是否匹配数据库中存储的信息，验证通过即可登录成功。登录流程图如图3-5所示。

图3-5登录流程图

3.4.3注册流程

未有账号的用户可进入注册界面进行注册操作，填写注册表格，包括用户名、密码、电子邮件等必要信息。后台系统验证并保存用户提交的信息。分配唯一用户标识符。注册成功后，用户可以使用账号密码进行登录。用户注册流程图如图3-6所示。

图3-6注册流程图

4 系统设计

4.1系统架构设计

系统由表现层、业务逻辑层、数据访问层和数据库服务器组成。表现层通过浏览器（如IE、Chrome、Firefox）与用户交互，采用FreeMarker、Bootstrap、jQuery等技术实现界面呈现。业务逻辑层负责处理系统的核心业务逻辑，通过分模块设计实现功能分离。数据访问层使用MyBatis框架连接数据库，执行数据的增删改查操作。数据库服务器采用MySQL进行数据存储和管理，为系统提供稳定的数据库支持。整个架构通过Tomcat服务器完成用户请求的接收和处理，确保系统的高效运行[8]。整个系统架构如图4-1所示。

图4-1 系统架构图

4.2系统总体功能设计

系统功能结构图如图4-2所示。

图4-2 系统功能结构图

4.3数据库设计

数据库设计是系统开发中至关重要的环节，为系统提供高效、规范的数据存储和管理方案。设计过程包括需求分析、实体设计、表设计和逻辑结构设计。首先，通过分析业务需求，确定系统的核心实体及其属性，同时明确实体间的关系。接着，将实体抽象为具体的数据库表，为每张表定义字段名、数据类型、主键和外键，通过主外键关系和关联表设计，保证数据的完整性和一致性。最后，数据库逻辑设计进一步优化表之间的关系，通过索引、视图和存储过程提升查询效率和操作性能。整个设计需严格遵循规范，避免数据冗余和冲突，确保系统在高并发访问和复杂数据处理场景下的稳定性和高效性。

4.3.1数据库实体设计

数据库实体设计是数据库设计的关键步骤，对实际业务逻辑中涉及的实体及其属性进行抽象建模，明确系统中的主要信息对象及其关系[9]。在实体设计中，根据需求分析确定系统的核心实体，如用户、角色、权限等，提取实体的主要属性，如用户的ID、姓名、联系方式，名称、类型等，同时定义各实体之间的关系，包括一对一、一对多、多对多等。在设计过程中，注重实体的完整性、规范性和唯一性，确保设计能够满足系统功能需求，并为后续的表设计提供清晰的结构框架。实体设计需遵循数据库设计的标准化要求，避免数据冗余和不必要的复杂度。

系统全局E-R图如图4-3所示。

图4-3系统E-R图

4.3.2数据库表设计

数据库表设计基于实体设计，将抽象的实体映射为具体的表结构。设计过程中，为每个实体定义表名、字段名及数据类型 [10]。根据业务需求，合理定义主键、外键及约束条件，确保表之间的关联性，例如通过外键建立用户表和角色表之间的关系。表设计时注重数据存储的完整性、一致性，并通过索引优化查询效率，最终确保数据库结构能够支持系统的功能需求。以下是系统的数据库表设计展示。

表 4-1-access_token（登陆访问时长）

编号	字段名	类型	长度	是否非空	是否主键	注释
1	token_id	int		是	是	临时访问牌ID
2	token	varchar	64	否	否	临时访问牌
3	info	text	65535	否	否	信息
4	maxage	int		是	否	最大寿命：默认2小时
5	create_time	timestamp		是	否	创建时间
6	update_time	timestamp		是	否	更新时间
7	user_id	int		是	否	用户编号

表 4-2-article（文章）

编号	字段名	类型	长度	是否非空	是否主键	注释
1	article_id	mediumint		是	是	文章id
2	title	varchar	125	是	是	标题
3	type	varchar	64	是	否	文章分类
4	hits	int		是	否	点击数
5	praise_len	int		是	否	点赞数
6	create_time	timestamp		是	否	创建时间
7	update_time	timestamp		是	否	更新时间
8	source	varchar	255	否	否	来源
9	url	varchar	255	否	否	来源地址
10	tag	varchar	255	否	否	标签
11	content	longtext	4294967295	否	否	正文
12	img	varchar	255	否	否	封面图
13	description	text	65535	否	否	文章描述

表 4-3-article_type（文章分类）

编号	字段名	类型	长度	是否非空	是否主键	注释
1	type_id	smallint		是	是	分类ID
2	display	smallint		是	否	显示顺序
3	name	varchar	16	是	否	分类名称
4	father_id	smallint		是	否	上级分类ID
5	description	varchar	255	否	否	描述
6	icon	text	65535	否	否	分类图标
7	url	varchar	255	否	否	外链地址
8	create_time	timestamp		是	否	创建时间
9	update_time	timestamp		是	否	更新时间

表 4-4-auth（用户权限管理）

编号	字段名	类型	长度	是否非空	是否主键	注释
1	auth_id	int		是	是	授权ID
2	user_group	varchar	64	否	否	用户组
3	mod_name	varchar	64	否	否	模块名
4	table_name	varchar	64	否	否	表名
5	page_title	varchar	255	否	否	页面标题
6	path	varchar	255	否	否	路由路径
7	parent	varchar	64	否	否	父级菜单
8	parent_sort	int		是	否	父级菜单排序
9	position	varchar	32	否	否	位置
10	mode	varchar	32	是	否	跳转方式
11	add	tinyint		是	否	是否可增加
12	del	tinyint		是	否	是否可删除
13	set	tinyint		是	否	是否可修改
14	get	tinyint		是	否	是否可查看
15	field_add	text	65535	否	否	添加字段
16	field_set	text	65535	否	否	修改字段
17	field_get	text	65535	否	否	查询字段
18	table_nav_name	varchar	500	否	否	跨表导航名称
19	table_nav	varchar	500	否	否	跨表导航
20	option	text	65535	否	否	配置
21	create_time	timestamp		是	否	创建时间
22	update_time	timestamp		是	否	更新时间

表 4-5-code_token（验证码）

编号	字段名	类型	长度	是否非空	是否主键	注释
1	code_token_id	int		是	是	验证码ID
2	token	varchar	255	否	否	令牌
3	code	varchar	255	否	否	验证码
4	expire_time	timestamp		是	否	失效时间
5	create_time	timestamp		是	否	创建时间
6	update_time	timestamp		是	否	更新时间

表 4-6-comment（评论）

编号	字段名	类型	长度	是否非空	是否主键	注释
1	comment_id	int		是	是	评论ID
2	user_id	int		是	是	评论人ID
3	reply_to_id	int		是	否	回复评论ID
4	content	longtext	4294967295	否	否	内容
5	nickname	varchar	255	否	否	昵称
6	avatar	varchar	255	否	否	头像地址
7	create_time	timestamp		是	否	创建时间
8	update_time	timestamp		是	否	更新时间
9	source_table	varchar	255	否	否	来源表
10	source_field	varchar	255	否	否	来源字段
11	source_id	int		是	否	来源ID

表 4-7-consultation_reply（咨询回复）

编号	字段名	类型	长度	是否非空	是否主键	注释
1	consultation_reply_id	int		是	是	咨询回复ID
2	patient_user	int		否	否	患者用户
3	user_name	varchar	64	否	否	用户姓名
4	doctor_user	int		否	否	医生用户
5	doctors_name	varchar	64	否	否	医生姓名
6	advisory_questions	varchar	64	否	否	咨询问题
7	reply_content	varchar	64	否	否	回复内容
8	create_time	datetime		是	否	创建时间
9	update_time	timestamp		是	否	更新时间
10	source_table	varchar	255	否	否	来源表
11	source_id	int		否	否	来源ID
12	source_user_id	int		否	否	来源用户

表 4-8-consult_a_doctor（咨询医生）

编号	字段名	类型	长度	是否非空	是否主键	注释
1	consult_a_doctor_id	int		是	是	咨询医生ID
2	patient_user	int		否	否	患者用户
3	user_name	varchar	64	否	否	用户姓名
4	doctor_user	int		否	否	医生用户
5	advisory_questions	varchar	64	否	否	咨询问题
6	consulting_content	text	65535	否	否	咨询内容
7	consultation_reply_limit_times	int		是	否	咨询回复限制次数
8	create_time	datetime		是	否	创建时间
9	update_time	timestamp		是	否	更新时间
10	source_table	varchar	255	否	否	来源表
11	source_id	int		否	否	来源ID
12	source_user_id	int		否	否	来源用户

表 4-9-daily_inspection（日常检测）

编号	字段名	类型	长度	是否非空	是否主键	注释
1	daily_inspection_id	int		是	是	日常检测ID
2	patient_user	int		否	否	患者用户
3	user_name	varchar	64	否	否	用户姓名
4	user_age	varchar	64	否	否	用户年龄
5	user_gender	varchar	64	否	否	用户性别
6	heart_rate	double		否	否	心率
7	blood_pressure	double		否	否	血压
8	blood_sugar	double		否	否	血糖
9	body_temperature	double		否	否	体温
10	test_date	date		否	否	检测日期
11	health_plan_limit_times	int		是	否	计划建议限制次数
12	create_time	datetime		是	否	创建时间
13	update_time	timestamp		是	否	更新时间

表 4-10-doctor_user（医生用户）

编号	字段名	类型	长度	是否非空	是否主键	注释
1	doctor_user_id	int		是	是	医生用户ID
2	doctors_name	varchar	64	否	否	医生姓名
3	doctors_title	varchar	64	否	否	医生职称
4	department	varchar	64	否	否	所属科室
5	gender_of_doctor	varchar	64	否	否	医生性别
6	doctors_age	double		否	否	医生年龄
7	doctors_phone	varchar	16	否	否	医生手机
8	qualification_certificate	varchar	255	否	否	资质证明
9	examine_state	varchar	16	是	否	审核状态
10	user_id	int		是	否	用户ID
11	create_time	datetime		是	否	创建时间
12	update_time	timestamp		是	否	更新时间

表 4-11-health_plan（健康计划）

编号	字段名	类型	长度	是否非空	是否主键	注释
1	health_plan_id	int		是	是	健康计划ID
2	patient_user	int		否	否	患者用户
3	user_name	varchar	64	否	否	用户姓名
4	doctor_user	int		否	否	医生用户
5	doctors_name	varchar	64	否	否	医生姓名
6	health_diagnostics	varchar	64	否	否	健康诊断
7	health_score	double		否	否	健康评分
8	rating_date	date		否	否	评分日期
9	name_of_medication	varchar	64	否	否	服药名称
10	dose_of_medication	varchar	64	否	否	服药剂量
11	frequency_of_medication	varchar	64	否	否	服药频次
12	diet_plan	text	65535	否	否	饮食计划
13	schedule	text	65535	否	否	作息计划
14	exercise_plan	text	65535	否	否	运动计划
15	consult_a_doctor_limit_times	int		是	否	咨询医生限制次数
16	create_time	datetime		是	否	创建时间
17	update_time	timestamp		是	否	更新时间
18	source_table	varchar	255	否	否	来源表
19	source_id	int		否	否	来源ID
20	source_user_id	int		否	否	来源用户

表 4-12-hits（用户点击）

编号	字段名	类型	长度	是否非空	是否主键	注释
1	hits_id	int		是	是	点赞ID
2	user_id	int		是	否	点赞人
3	create_time	timestamp		是	否	创建时间
4	update_time	timestamp		是	否	更新时间
5	source_table	varchar	255	否	否	来源表
6	source_field	varchar	255	否	否	来源字段
7	source_id	int		是	否	来源ID

表 4-13-notice（公告）

编号	字段名	类型	长度	是否非空	是否主键	注释
1	notice_id	mediumint		是	是	公告ID
2	title	varchar	125	是	否	标题
3	content	longtext	4294967295	否	否	正文
4	create_time	timestamp		是	否	创建时间
5	update_time	timestamp		是	否	更新时间

表 4-14-patient_information（患者信息）

编号	字段名	类型	长度	是否非空	是否主键	注释
1	patient_information_id	int		是	是	患者信息ID
2	patient_user	int		否	否	患者用户
3	user_name	varchar	64	是	否	用户姓名
4	user_phone_number	varchar	64	是	否	用户电话
5	user_age	varchar	64	是	否	用户年龄
6	user_gender	varchar	64	是	否	用户性别
7	user_number	varchar	64	否	否	用户编号
8	height	varchar	64	否	否	身高
9	weight	varchar	64	否	否	体重
10	name_of_disease	varchar	64	否	否	疾病名称
11	medical_history	text	65535	否	否	病史
12	allergy_history	text	65535	否	否	过敏史
13	create_time	datetime		是	否	创建时间
14	update_time	timestamp		是	否	更新时间

表 4-15-patient_user（患者用户）

编号	字段名	类型	长度	是否非空	是否主键	注释
1	patient_user_id	int		是	是	患者用户ID
2	user_name	varchar	64	是	否	用户姓名
3	user_phone_number	varchar	64	是	否	用户电话
4	user_age	double		是	否	用户年龄
5	user_gender	varchar	64	是	否	用户性别
6	examine_state	varchar	16	是	否	审核状态
7	user_id	int		是	否	用户ID
8	create_time	datetime		是	否	创建时间
9	update_time	timestamp		是	否	更新时间

表 4-16-praise（点赞）

编号	字段名	类型	长度	是否非空	是否主键	注释
1	praise_id	int		是	是	点赞ID
2	user_id	int		是	是	点赞人
3	create_time	timestamp		是	否	创建时间
4	update_time	timestamp		是	否	更新时间
5	source_table	varchar	255	否	否	来源表
6	source_field	varchar	255	否	否	来源字段
7	source_id	int		是	否	来源ID
8	status	tinyint		是	否	点赞状态:1为点赞，0已取消

表 4-17-schedule（日程管理）

编号	字段名	类型	长度	是否非空	是否主键	注释
1	schedule_id	smallint		是	是	日程ID
2	content	varchar	255	否	否	日程内容
3	scheduled_time	datetime		否	否	计划时间
4	user_id	int		是	否	用户ID
5	create_time	datetime		否	否	创建时间
6	update_time	datetime		否	否	更新时间

表 4-18-slides（轮播图）

编号	字段名	类型	长度	是否非空	是否主键	注释
1	slides_id	int		是	是	轮播图ID
2	title	varchar	64	否	否	标题
3	content	varchar	255	否	否	内容
4	url	varchar	255	否	否	链接
5	img	varchar	255	否	否	轮播图
6	hits	int		是	否	点击量
7	create_time	timestamp		是	否	创建时间
8	update_time	timestamp		是	否	更新时间

表 4-19-upload（文件上传）

编号	字段名	类型	长度	是否非空	是否主键	注释
1	upload_id	int		是	是	上传ID
2	name	varchar	64	否	否	文件名
3	path	varchar	255	否	否	访问路径
4	file	varchar	255	否	否	文件路径
5	display	varchar	255	否	否	显示顺序
6	father_id	int		否	否	父级ID
7	dir	varchar	255	否	否	文件夹
8	type	varchar	32	否	否	文件类型

表 4-20-user（用户账户）

编号	字段名	类型	长度	是否非空	是否主键	注释
1	user_id	int		是	是	用户ID
2	state	smallint		是	否	账户状态：(1可用|2异常|3已冻结|4已注销)
3	user_group	varchar	32	否	否	所在用户组
4	login_time	timestamp		是	否	上次登录时间
5	phone	varchar	11	否	否	手机号码
6	phone_state	smallint		是	否	手机认证：(0未认证|1审核中|2已认证)
7	username	varchar	16	是	否	用户名
8	nickname	varchar	16	否	否	昵称
9	password	varchar	64	是	否	密码
10	email	varchar	64	否	否	邮箱
11	email_state	smallint		是	否	邮箱认证：(0未认证|1审核中|2已认证)
12	avatar	varchar	255	否	否	头像地址
13	open_id	varchar	255	否	否	针对获取用户信息字段
14	create_time	timestamp		是	否	创建时间

表 4-21-user_group（用户组）

编号	字段名	类型	长度	是否非空	是否主键	注释
1	group_id	mediumint		是	是	用户组ID
2	display	smallint		是	否	显示顺序
3	name	varchar	16	是	否	名称
4	description	varchar	255	否	否	描述
5	source_table	varchar	255	否	否	来源表
6	source_field	varchar	255	否	否	来源字段
7	source_id	int		是	否	来源ID
8	register	smallint		否	否	注册位置
9	create_time	timestamp		是	否	创建时间
10	update_time	timestamp		是	否	更新时间

5 系统实现

5.1患者用户功能实现

5.1.1用户注册

用户注册：输入账号、设置密码、确认密码、昵称、邮箱、选择用户身份、用户姓名、用户性别、联系电话等用户个人信息，点击注册按钮进行注册，用户注册界面如下图所示。

图5-1用户注册界面图

5.1.2用户登录

用户登录：输入用户名跟密码点击登录按钮，校验通过后即可登录，用户登录界面如下图所示。

图5-2用户登录界面图

5.1.3患者信息

患者可以在系统中查看和更新自己的个人信息，包括基本信息、就诊记录和健康档案等，确保信息的准确性。界面如下图所示。

图5-3患者信息界面

5.1.4健康知识

用户进入健康知识页面，浏览健康知识的图片、名称、描述等基本信息。通过搜索栏输入关键词或筛选条件，快速定位健康知识界面。可以进行点赞、收藏和评论。健康知识界面如下图所示。

图5-4健康知识界面

5.1.5日常检测

患者可以记录和查看自己的日常健康检测数据，如体重、血糖、血压等，便于长期跟踪自身健康状况。日常检测界面如下图所示。

图5-5日常检测界面

5.2管理员功能实现

5.2.1角色管理

在“角色管理”模块下，管理员可以管理系统上的三类用户：管理员、患者用户和医生用户。管理员可以进行用户的增、删、改、查操作，包括设置权限、修改用户信息等。角色管理界面如下图所示。

图5-6角色管理界面

5.2.2患者信息管理

管理员点击“患者信息管理”这一菜单会显示患者信息列表和患者信息添加两个子菜单，点击“患者信息列表”可以查看患者信息详情，可以进行查询、重置和删除等操作。点击“患者信息添加”，管理员可以添加新的患者信息。患者信息管理界面如下图所示。

图5-7患者信息管理界面

5.2.3日常检测管理

管理员点击“日常检测管理”这一菜单会显示日常检测列表和日常检测添加两个子菜单，点击“日常检测列表”可以查看日常检测详情，可以进行查询、重置和删除等操作。点击“日常检测添加”，管理员可以添加新的日常检测。日常检测管理界面如下图所示。

图5-8日常检测管理界面

5.2.4健康计划管理

管理员点击“健康计划管理”这一菜单会显示健康计划列表这个子菜单，点击“健康计划列表”可以查看健康计划详情和咨询医生，可以进行查询、重置和删除等操作。健康计划管理界面如下图所示。

图5-9健康计划管理界面

5.2.5系统管理

管理员点击“系统管理”菜单，可以对前台展示的轮播图进行设置，系统管理界面如下图所示。

图5-10系统管理界面

5.2.6系统公告管理

管理员点击“系统公告管理”这个菜单，可以对系统中的系统公告进行管理，包括公告的增删改查等操作。系统公告管理界面如下图所示。

图5-11系统公告管理界面

5.3医生用户功能实现

5.3.1日常检测

医生可以查看患者的日常健康检测数据，如血糖、血压、体重、心率等重要健康指标。医生可以根据这些数据分析患者的健康状态，并根据需要调整治疗方案或进行干预。系统提供的数据图表和分析工具有助于医生在日常工作中进行精确的医疗决策。界面如下图所示。

图5-12日常检测界面

5.3.2健康计划

医生负责制定和调整患者的个性化健康管理计划。这些健康计划包括患者的饮食、运动、药物治疗等内容，医生可以根据患者的健康状况、检测结果以及治疗反应来定期调整健康计划，以确保患者能够在长期的治疗过程中获得最佳效果。健康计划模块帮助医生持续跟踪患者的健康进展，确保治疗方案的有效性。界面如下图所示。

图5-13健康计划界面

5.3.3咨询医生

在系统中，医生能够与患者进行实时的在线咨询。患者可以通过系统向医生提出健康问题，医生根据自己的专业知识为患者提供治疗建议或健康指导。这一功能促进了医生与患者之间的有效沟通，帮助医生实时解答患者的疑虑并提供必要的医学支持。界面如下图所示。

图5-14咨询医生界面

6 系统测试

6.1测试目的

测试的主要目的是确保系统的功能和性能满足预期的需求，同时识别和修复潜在的缺陷。通过系统测试，可以验证各个功能模块的正确性和稳定性，确保系统在不同使用场景下的表现符合设计要求。测试目的包括确认系统功能的完整性、验证数据处理的准确性、评估系统的性能和安全性。测试还可以提高用户满意度，保证用户在使用系统时获得流畅和可靠的体验。通过全面的测试，可以降低后期维护成本，减少系统上线后出现故障的风险，从而保障系统的长期稳定运行。

6.2测试方法

在本系统中，测试方法主要依赖于测试用例的设计与执行。测试用例是根据系统需求文档编写的，覆盖所有功能模块及其边界情况。每个测试用例包含输入数据、预期结果和实际结果的对比，以验证系统的功能是否按预期工作。

常见的测试用例包括功能测试用例、边界测试用例和异常测试用例[11]。功能测试用例针对系统的各项功能进行验证；边界测试用例则侧重于输入数据的边界条件，验证系统在极端情况下是否能够稳定运行；异常测试用例则用于验证系统在处理错误输入或异常情况时的反应。本文选择功能测试用例进行系统测试。

在测试执行过程中，记录每个用例的执行结果，并根据实际结果与预期结果的对比，判断系统是否存在缺陷。通过系统化的测试用例执行，可以有效提高测试的覆盖率和效率，为系统的最终上线提供保障。

6.3测试内容

通过对系统中所含的主要实体对象及其功能操作进行测试用例设计。以下是详细的测试：

表6-1用户注册登录测试表

用户注册登录测试用例：

用例说明	测试目的	测试步骤	预期结果	输出结果	通过情况
用户注册、登录	测试用户正确注册、登录	在首页界面注册一个新用户，按规定输入合理的注册信息，提交。 用户在登录界面输入账户密码登录	用户注册成功，登录成功	结果输出符合预期	通过

表6-2咨询医生测试表

咨询医生用例：

用例说明	测试目的	测试步骤	预期结果	输出结果	通过情况
咨询医生	测试用户咨询医生功能	点击咨询医生，进入详情页； 点击“咨询医生”，输入相关信息后点击提交	用户咨询医生成功，生成新的咨询医生信息	结果输出符合预期	通过

表6-3健康知识评论测试表

健康知识评论测试用例：

用例说明	测试目的	测试步骤	预期结果	输出结果	通过情况
健康知识评论	测试用户健康知识评论功能	1、在首页点击健康知识并看详情； 2、点击评论，输入相关信息点击提交	生成新的评论信息	结果输出符合预期	通过

表6-4健康知识添加测试表

管理员健康知识添加测试用例：

用例说明	测试目的	测试步骤	预期结果	输出结果	通过情况
健康知识添加测试	测试管理员添加健康知识功能	管理员点击健康知识、点击添加； 输入相关信息点击提交	健康知识添加成功	结果输出符合预期	通过

表6-5公告删除测试表

公告删除测试用例：

用例说明	测试目的	测试步骤	预期结果	输出结果	通过情况
公告删除测试	测试公告删除功能	管理员点击公告管理； 选择一个公告点击删除并确认删除	公告删除成功，前端不在展示该公告	结果输出符合预期	通过

6.4测试结果

在本次测试的过程主要针对所有功能下的添加操作，修改操作和删除操作，并以真实数据一一进行相关功能项目的输入，最终能够保证每个项目涉及的功能都是能够正常运行，因此能够保证本次设计的，已实现的功能能够正常运行并且相关数据库的信息也同样保证正确。