基于机器学习的心血管疾病风险诊断系统-计算机毕设 附源码63045

基于机器学习的心血管疾病风险诊断系统

第一章 系统需求分析

1.1 系统功能需求分析

　　普通用户在系统中可以完成注册登录操作。注册时需要填写用户名、密码、手机号等基本信息，登录后系统会生成访问令牌用于后续请求的身份校验。用户可以查看系统发布的各类通知公告，公告列表按发布时间倒序排列。新闻资讯模块展示了医疗健康相关的科普文章，用户点击标题后可跳转至详情页面阅读完整内容。医生信息页面列出了入驻系统的医生名单，每个医生条目包含姓名、专长、简介以及预约入口。用户选择目标医生后填写预约表单，提交后生成一条待处理的诊断预约记录。诊断信息管理模块展示了医生反馈的诊断结果，用户可以查看每次诊断的详细内容。

　　普通用户用例图如图3.1所示。

图3.1普通用户用例图

　　医生用户登录后可以对个人资料进行编辑与更新。医生信息管理模块允许医生修改个人简介、专长描述以及头像照片。诊断预约管理模块展示了患者提交的预约请求列表，医生可以查看预约详情并决定是否接诊。数据信息预测功能是系统的核心模块，医生输入收缩压、舒张压、血糖、血脂四项指标后系统返回风险等级预测结果。预测完成后医生可以选择将本次记录保存至数据库。数据信息管理模块展示了所有历史预测记录，每条记录包含输入体征、输出等级以及生成的图表路径。医生可以点击查看按钮在新窗口中展示相关性热力图、特征重要性图与混淆矩阵。诊断信息管理模块允许医生填写诊断结论并关联到对应的患者预约记录。

　　医生用户用例图如图3.2所示。

图3.2医生用户用例图

　　管理员拥有系统最高权限，可以对所有业务数据进行管理。数据信息管理模块允许管理员增删改查心血管病例样本，这些样本将作为模型训练的原始数据源。诊断预约管理模块中管理员可以查看所有预约记录并进行状态调整。诊断信息管理模块负责维护系统内所有的诊断结论记录。通知公告管理模块支持管理员发布、编辑或删除系统公告，公告内容将同步展示在普通用户的首页。资讯分类管理模块定义了新闻资讯的类别层级，如健康科普、医疗动态等。新闻资讯管理模块用于维护文章标题、正文、来源及封面图片。操作日志管理模块记录了管理员的关键操作行为，包括操作时间、操作人、操作类型等信息，便于后期审计追溯。

　　管理员用例图如图3.3所示。

图3.3管理员用例图

1.2 数据采集与预处理

1.2.1 数据采集

　　系统训练数据的来源为MySQL数据库中的data_information表。该表在系统运行前由管理员导入历史病例样本，每条记录对应一位患者的临床检查结果。原始数据包含收缩压、舒张压、血糖、血脂四项连续型数值特征，以及由专业医生标注的风险等级标签。风险等级划分为高、中、低三个类别，构成一个三分类预测任务。数据采集过程通过SQLAlchemy构建数据库连接引擎，执行形如“SELECT {特征列}, {目标列} FROMdata_informationLIMIT 1000”的查询语句。抽取上限设置为1000条，这一限制既保证了模型训练具有足够的样本量，又避免了单次请求占用过多数据库资源。若表中实际记录数不足1000条，则抽取全部可用数据。样本按照主键的升序顺序读取，未引入随机采样机制。在数据采集阶段，系统同时保留了原始数据帧的副本，用于后续预测结果处理时的类别解码操作。采集到的原始样本进入内存后以PandasDataFrame格式存储，每行代表一个病例，每列对应一个临床指标或风险标签。统计特征表明，四个数值型特征的取值范围差异较大，收缩压与舒张压通常分布在60至200 mmHg之间，血糖与血脂的数值范围相对集中。风险等级标签在分布上可能存在类别不均衡问题，但系统未在采集阶段对此进行特殊处理。典型样本示例如表3.4所示。

表3.4数据集字段定义及统计特征表

1.2.2 数据预处理

　　原始数据进入处理链路后，首要任务是完成数据类型的一致性检查与转换。系统遍历输入特征列与预测目标列，检测各字段的Pandas数据类型标识。对于目标列risk_level，其存储形式为字符串枚举值，无法直接输入到决策树模型中进行计算。系统采用LabelEncoder工具完成类别到整数的映射转换。编码过程首先收集目标列中出现的所有唯一值，为每个类别分配一个从0开始的整数编号。高、中、低三个类别被随机映射为0、1、2三个数字，映射关系存储在编码器对象的classes_属性中。这种编码方式将分类问题转化为整数标签预测问题，决策树在分裂时依据基尼指数计算各类别在子节点中的分布概率。值得说明的是，系统未对类别映射顺序做特殊约束，不同运行批次中相同风险等级可能对应不同整数编码。但对于单次训练过程，编码器一旦拟合就不再改变，保证了同一批次内标签的一致性。编码完成后，原始的目标列被替换为整数标签列，原字符串值则通过编码器保留以便后续解码。

　　特征编码阶段，系统检测输入特征列中是否存在object类型的字段。从data_information表的实际构成来看，四项临床体征均为数值型浮点数，不存在字符串特征。但系统的编码函数仍实现了对分类特征的通用处理逻辑。若某特征列被识别为object类型，系统同样会对其应用LabelEncoder，将该列的所有字符串转换为整数索引。这种设计的普适性使得系统能够扩展到其他包含分类特征的数据集，例如将性别、吸烟史等离散变量纳入输入空间。对于数值型特征，编码函数不做任何转换，直接保留原始数值。在完成上述处理后，系统生成特征相关性热力图，用于分析各变量之间的线性依赖关系。相关性矩阵的计算采用皮尔逊相关系数，其取值范围在-1到1之间，绝对值越接近1表示两个变量之间的线性关联越强。图3.4展示了四个输入特征与风险等级之间的相关性分布。

　　数据划分环节采用了顺序切分策略，未执行随机打乱操作。系统按照样本在DataFrame中的原始顺序，将前80%的样本划入训练集，后20%的样本划入测试集。设总样本量为N，则训练集大小为floor(0.8×N)，测试集大小为N减去训练集大小。这种划分方式简单直接，保证了划分结果的可复现性。但顺序划分可能存在隐患，若原始数据按照某种规律排列，例如前80%的样本均为低风险病例、后20%的样本均为高风险病例，则训练集与测试集的分布会产生严重偏差。系统未对此类情况进行显式检验或纠正。

　　模型训练阶段采用自实现的随机森林式集成分类器。集成策略的核心是Bagging有放回抽样。对于每棵决策树，系统从训练集中随机抽取样本构成子训练集，抽样数量与原始训练集大小相等。由于采用有放回方式，同一个样本可能在同一棵树的训练集中出现多次，也可能完全不出现。未被抽中的样本称为袋外数据，可用于评估模型性能，但本系统未利用这一特性。共生成10棵CART分类树，每棵树独立训练，树之间不进行交互。单棵树的最大深度限制为5层，这一设置控制了模型的复杂度。若不对深度做限制，决策树可能持续分裂直到每个叶节点只包含单一类别，导致严重的过拟合现象。深度为5意味着从根节点到叶节点最多经历5次分裂，树的规模被限制在可解释范围内。叶节点最小样本数设为5，当节点中的样本数低于该阈值时停止分裂，该节点成为叶节点并取子集中多数类别作为输出。这个参数避免了树过度细化到个别异常样本上。每次寻找最优分裂点时，系统从全部4个特征中随机抽取2个作为候选。这种随机特征选择策略是随机森林区别于普通Bagging的关键，它降低了各棵树之间的相关性，使得集成模型在投票时能够综合更多样化的判断视角。分裂准则采用基尼指数，其计算方式如公式3-1所示。

　　其中D表示当前节点包含的样本集合，K为类别总数，p_k为第k类样本在D中出现的频率。基尼指数衡量从数据集中随机抽取两个样本其类别标签不一致的概率。该值越小，表示节点的纯度越高。对于候选的每个特征及其可能的分割阈值，系统计算分割后左右两个子节点的加权基尼指数，选择使该加权和最小的特征-阈值组合作为最优分裂。

　　模型构建完成后，系统在测试集上进行预测评估。对于测试集中的每个样本，所有10棵决策树分别输出一个类别预测。系统统计各棵树输出结果的频次，将出现次数最多的类别作为集成模型的最终输出。这种多数投票机制能够有效降低单棵树预测错误带来的负面影响。系统基于预测结果与真实标签计算分类评估指标，包括精确率、召回率、F1分数。精确率衡量预测为正类的样本中有多少真正属于正类，召回率衡量真正的正类样本中有多少被成功预测出来，F1分数则是精确率与召回率的调和平均值。上述指标按类别分别计算，并输出宏平均与加权平均结果。预处理参数配置汇总如表3.5所示。

表3.5预处理前后关键统计指标对比表

　　核心代码片段展示了数据读取、标签编码与训练集构造的关键逻辑。

　　python

　　defget_data(source_table,input_columns,forecast_column):

columns =input_columns+ [forecast_column]

sql=f"SELECT{','.join(columns)} FROM {source_table} LIMIT 1000"

df=query_from_mysql(sql)

　　ifdf[forecast_column].dtype== 'object':

　　df[forecast_column] =df[forecast_column].astype(str)

　　forecast_type= 'classification'

　　returndf,forecast_type

　　defencode_target_variable(df,forecast_column,forecast_type):

　　ifforecast_type== 'classification':

　　le =LabelEncoder()

　　df[forecast_column] =le.fit_transform(df[forecast_column].astype(str))

　　returndf, le

　　returndf, None

　　deftrain_test_split(dataset,split_ratio=0.8):

train_size= int(len(dataset) *split_ratio)

train_set= dataset[:train_size]

test_set= dataset[train_size:]

　　returntrain_set,test_set

　　数据存储阶段，系统将预测结果及生成的图表路径写入MySQL数据库的data_information_forecast表。每次预测请求会生成一个唯一的时间戳，用于命名输出图像文件。相关性热力图、特征重要性图、模型性能评估图三张图片以PNG格式保存到static/output目录。数据库记录中存储图片的相对路径，前端展示时通过拼接静态资源URL完成图片加载。这种存储方式将图像文件与结构化数据分离，既保留了实验结果的可追溯性，又避免了数据库因存储大量二进制数据而膨胀。

1.3 系统非功能需求

　　系统的响应时间需要满足医疗场景下的实时性要求。预测接口从接收请求到返回结果的全过程应在5秒内完成，其中数据库样本抽取不超过1秒，模型训练与推理控制在3秒以内，图像生成与保存限制在1秒以内。页面加载方面，首次进入预测页面时所有静态资源的总下载时间不应超过3秒，列表数据的接口响应时间控制在500毫秒以内。

　　系统在数据安全性方面需要满足医疗信息管理的合规要求。所有用户的密码在存入数据库之前必须经过哈希加密处理，禁止以明文形式存储。用户登录后的每一次关键操作均应记录操作日志，包括操作人、操作时间、操作类型及操作前后的数据状态。普通用户只能访问与自己账号相关的预约记录与诊断信息，无权查看其他用户的隐私数据。医生用户只能查看分配给自己的预约请求，无权访问其他医生的患者信息。管理员拥有完整的数据访问权限，但所有管理操作必须留下可追溯的审计痕迹。

　　系统的可用性体现在界面交互的直观性与操作的容错性上。预测页面的四个输入框应配有明确的中文标签与单位说明，用户无需查阅使用手册即可理解每个字段的含义。当用户输入非数值字符或超出合理范围的值时，系统应在提交前给出明确的错误提示，阻止无效请求发送至后端。预测结果展示区域应采用醒目的颜色区分高中低三个等级，帮助医生快速识别风险程度。表格中的操作按钮应具有一致的样式与布局，用户完成新增或编辑操作后页面自动刷新列表，无需手动重新加载。

　　系统的可维护性要求代码结构清晰且模块划分合理。机器学习预测逻辑封装在独立的decision_tree_forecast.py文件中，与业务视图代码解耦。数据库连接参数集中配置于settings.py，修改数据库地址时无需逐个文件调整。前端组件按照功能类型分目录组织，API请求统一封装在aiApi.js与aiRequestHelper.js中，便于后续接口地址的批量修改。系统运行过程中产生的错误信息应写入日志文件，而非直接暴露给前端用户。

1.4 本章小结

　　本章对系统开发所采用的核心技术进行了介绍。Django框架为后端服务提供了完整的ORM映射、路由分发与中间件支持机制，承担了业务逻辑控制与数据库交互的职责。Vue.js框架采用组件化开发模式与响应式数据绑定机制，支撑了前端预测页面、历史记录表格与图表弹窗等交互界面的构建。MySQL数据库以关系型表结构组织训练样本、预测结果与业务数据，通过事务机制保证数据的一致性与完整性。决策树与集成学习部分阐述了CART算法的分裂准则与Bagging策略的多数投票机制，说明了自实现随机森林式分类器的构成逻辑。上述技术共同构成了系统的技术底座，为后续需求分析与系统设计提供了实现层面的支撑。

第二章 系统总体设计

2.1 系统架构设计

　　系统采用前后端分离的分层架构，将用户界面、业务逻辑、模型服务与数据存储划分为独立的层次。前端Vue.js应用运行于浏览器环境，通过HTTP协议与后端Django服务进行通信。后端接收到请求后，由路由层将请求分发至对应的视图控制器。对于常规业务请求，视图控制器调用服务层完成数据库的增删改查操作。对于预测类请求，视图控制器将参数传递给决策树预测模块，该模块连接MySQL数据库抽取训练样本，完成模型训练与推理后返回预测结果及图表路径。数据持久层采用MySQL关系型数据库，存储用户信息、病例样本、预测记录及业务数据。系统架构图如图3.4所示。

图3.4系统架构图

2.2 功能结构设计

　　系统围绕三类用户角色组织功能模块。普通用户端提供注册登录、通知公告浏览、新闻资讯查阅、医生信息查看、诊断预约提交、诊断结果查询等功能。医生端包含个人资料维护、预约请求处理、数据信息预测、预测记录管理、诊断结论录入等功能。管理员端负责病例样本管理、预约记录监管、诊断结论归档、公告内容发布、资讯分类维护、新闻文章管理、操作日志审计等功能。预测模块作为系统的核心功能，接受收缩压、舒张压、血糖、血脂四项输入，调用集成决策树模型返回风险等级。系统功能结构如图3.5所示。

图3.5系统功能结构图

2.3 业务流程设计

2.3.1 系统总体业务流程设计

　　用户访问系统时首先进入登录页面，完成身份认证后跳转至对应角色的首页。普通用户可浏览医生信息并发起预约请求，预约记录进入待处理状态。医生登录后查看预约列表，选择接诊后填写诊断结果并提交。诊断结论会同步推送至普通用户的诊断信息模块。管理员负责后台数据的全面维护，包括病例样本导入、医生信息审核、公告发布等操作。系统总体业务流程如图3.6所示。

图3.6系统总体业务流程图

2.3.2 用户登录认证流程设计

　　用户在前端输入用户名与密码，系统将凭证封装为POST请求发送至后端认证接口。后端接收请求后查询用户表校验账号存在性与密码正确性。校验通过后生成访问令牌并返回前端。前端将令牌存入本地存储，后续请求均在请求头中携带该令牌。认证流程如图3.7所示。

图3.7用户登录认证流程图

2.3.3 诊断预约流程设计

　　普通用户在医生列表页面选择目标医生，点击预约按钮后跳转至预约表单填写页面。用户填写预约时间及相关备注后提交表单。系统将预约记录写入诊断预约表，状态初始化为待处理。医生登录后在预约管理模块查看待处理请求，选择接诊后状态更新为已接诊。预约流程如图3.8所示。

图3.8诊断预约流程图

2.3.4 风险预测流程设计

　　医生进入数据信息预测页面，在四个输入框中分别填写收缩压、舒张压、血糖、血脂数值。点击预测按钮后前端发起GET请求，参数以查询字符串形式传递至后端预测接口。后端调用决策树预测模块，模块连接MySQL抽取data_information表样本完成模型训练与推理。预测结果以JSON格式返回前端，页面展示风险等级。预测流程如图3.9所示。

图3.9风险预测流程图

2.3.5 数据信息管理流程设计

　　管理员进入数据信息管理页面，页面以表格形式展示所有病例样本记录。管理员可执行新增操作，在弹出的表单中填写体征数据与风险等级后提交保存。编辑操作允许修改现有样本的字段值。删除操作需要二次确认，确认后系统从数据库中物理删除该记录。数据信息管理流程如图3.10所示。

图3.10数据信息管理流程图

2.4 数据库设计

2.4.1 数据库概念设计

　　概念设计阶段从系统功能需求中抽象出核心实体，并分析实体之间的业务联系。经过筛选，系统共包含12个核心业务实体。每个实体对应数据库中的一张表，实体属性对应表中的字段。实体之间通过主外键关联形成完整的数据关系网络。概念结构为后续的逻辑表设计提供了基础框架。

　　普通用户实体主要包含用户编号、用户名、性别、手机号、审核状态、用户编号等。实体属性图如图3.11所示。

图3.11普通用户实体属性图

　　医生用户实体主要包含医生编号、医生姓名、医生性别、联系电话、审核状态、用户编号等。实体属性图如图3.12所示。

图3.12医生用户实体属性图

　　医生信息实体主要包含资料编号、医生用户、医生姓名、医生照片、医生专长、医生简介、点击量、点赞数等。实体属性图如图3.13所示。

图3.13医生信息实体属性图

　　系统用户实体主要包含用户编号、状态、用户组、登录时间、手机号、用户名、昵称、密码、邮箱、头像等。实体属性图如图3.14所示。

图3.14系统用户实体属性图

　　系统核心实体之间存在明确的业务关联。用户实体与普通用户实体、医生用户实体通过用户编号建立一对一扩展关系，统一身份认证与角色专属属性分离存储。医生用户实体与医生信息实体通过医生用户字段关联，前者存储账号状态，后者存储展示性资料。诊断预约实体同时关联普通用户与医生用户，记录一次预约请求的发起方与接收方。诊断信息实体在预约确认后创建，关联同一对医患双方并记录诊断结论。数据信息实体独立存储训练样本，数据信息预测实体存储每一次预测行为的输入与输出。新闻资讯与资讯分类通过分类编号关联，操作日志独立记录后台操作行为。系统E-R图如图3.15所示。

图3.15系统E-R图

2.4.2 数据库表设计

　　用户表主要用来存储系统所有账号的登录信息与身份标识。主要包含用户编号、用户名、昵称、密码、用户组、手机号、邮箱、头像、状态、创建时间等字段。如表3.1所示。

表3.1用户表

　　医生信息表主要是用来展示医生资料与统计互动数据。主要包含医生信息编号、医生用户、医生姓名、医生照片、医生专长、医生简介、点击量、点赞数等字段。如表3.2所示。

表3.2医生信息表

　　诊断预约表主要是用来记录患者发起的预约请求。主要包含诊断预约编号、普通用户、用户姓名、医生用户、医生姓名、用户年龄、收缩压、舒张压、血糖、血脂、预约时间等字段。如表3.3所示。

表3.3诊断预约表

　　诊断信息表主要是用来记录医生对患者的诊断结论。主要包含诊断信息编号、医生用户、医生姓名、普通用户、用户姓名、风险等级、诊断结果等字段。如表3.4所示。

表3.4诊断信息表

　　数据信息表主要是用来存储训练样本与体征标注数据。主要包含数据信息编号、收缩压、舒张压、血糖、血脂、风险等级、备注信息等字段。如表3.5所示。

表3.5数据信息表

　　数据信息预测表主要是用来记录每次预测行为的输入与输出。主要包含预测记录编号、收缩压、舒张压、血糖、血脂、风险等级、输出图表路径等字段。如表3.6所示。

表3.6数据信息预测表

2.5 模型构建

2.5.1 算法选型

　　系统采用随机森林式集成树模型作为核心预测算法。该模型属于监督学习范畴下的分类器家族，适用于结构化表格数据的分类任务。选择集成树模型而非单一决策树的理由在于降低过拟合风险。单棵决策树容易在训练集上达到完美分类，但在测试集上的泛化能力不足。集成方法通过组合多棵树的预测结果来平滑个体模型的偏差与方差。模型的任务类型为三分类，输入空间是四维实数向量，输出空间是三个离散类别。模型结构由多棵CART分类树构成，每棵树独立完成从输入空间到输出空间的映射，最终通过多数投票机制聚合为单一预测结果。

2.5.2 树结构设计

　　单棵CART分类树采用二叉树结构组织分裂节点。每个内部节点包含三个核心组件：分裂特征索引、分裂阈值、左右子节点指针。分裂特征索引指示当前节点使用四个输入特征中的哪一个进行判断。分裂阈值是该特征上的一个数值边界，样本到达节点后比较特征值与阈值的大小关系，小于阈值的样本进入左子树，大于等于阈值的样本进入右子树。叶子节点不再继续分裂，而是存储一个类别标签，该标签由到达该节点的训练样本的多数类别决定。树的最大深度设置为5，这一限制防止树生长得过深而过度拟合训练集中的噪声。最小叶子节点样本数设置为5，当一个节点包含的样本数小于或等于5时停止分裂，将该节点转为叶子节点。这两个超参数的取值在决策树模型中具有明确的统计学含义：最大深度控制模型的复杂度，最小叶子样本数控制分裂的保守程度。

2.5.3 分裂准则

　　节点分裂时系统从四个特征中随机选取两个候选特征，仅在这两个特征上搜索最优分裂点。这种随机特征选择机制是随机森林区别于普通袋装集成的关键特征。传统袋装集成每棵树使用全部特征搜索分裂点，随机森林在每个节点处引入额外的随机性，迫使树之间的结构产生更大差异。节点分裂的评判指标采用基尼指数。对于包含K个类别的节点，基尼指数的计算公式为Gini = 1 – Σ(p_k^2)，其中p_k是第k类样本在节点中所占的比例。基尼指数衡量节点的纯度，数值越小表示节点中样本的类别分布越集中。分裂算法遍历候选特征的所有取值作为候选阈值，计算每个划分方式下的加权基尼指数，选择使基尼指数下降最多的特征与阈值组合。这种贪心搜索策略在每一步都做出局部最优选择，不保证全局最优但计算效率较高。

2.5.4 集成策略

　　系统集成10棵CART分类树构成随机森林。每棵树的训练数据通过有放回抽样从原始训练集中抽取，抽样比例设为1.0，即每棵树的训练集大小与原始训练集相同。有放回抽样导致某些样本在同一棵树中被多次选中，另一些样本从未出现，这种自举采样机制增强了树之间的差异性。预测阶段对新的输入样本，每棵树独立输出一个类别预测。系统收集10棵树的预测结果后执行多数投票，得票最高的类别作为最终预测输出。若出现平票情况，系统按类别编号顺序选择编号较小的类别。这种投票策略的数学基础在于，当个体分类器的错误率低于0.5且相互独立时，集成分类器的错误率随着分类器数量增加而指数级下降。实际任务中分类器不可能完全独立，但随机特征选择与自举采样尽可能降低了树之间的相关性。模型构建阶段的参数配置汇总如表3.7所示。

表3.7模型超参数配置表

2.6 模型训练

2.6.1 数据划分

　　模型训练阶段首先对预处理后的数据集进行划分。系统未使用随机打乱机制，而是按照样本在数据集中的原始顺序进行切分。前80%的样本作为训练集，后20%的样本作为测试集。这种划分方式的合理性建立在样本顺序与数据分布无关的前提之上。若数据录入时已按时间排序，则测试集全部由后期采集的样本组成，这种设置在一定程度上模拟了模型对未来数据的预测能力。训练集用于参数学习，包括树结构的确定、分裂阈值的计算、叶子节点类别的赋值。测试集在训练完成后一次性用于性能评估，不参与任何参数更新过程。

2.6.2 训练流程

　　训练过程围绕10棵CART分类树的构建展开。对于每一棵树，系统从训练集中执行有放回抽样，生成与该树对应的自举样本集。该样本集的规模与原始训练集相同，但由于有放回抽样的特性，某些样本重复出现，某些样本完全缺失。系统以自举样本集为输入调用build_tree_classification函数构建单棵树。构建过程从根节点开始递归进行。到达某个节点后首先检查终止条件：当前深度是否达到最大深度5，当前节点包含的样本数是否小于或等于最小叶子样本数5。若满足任一条件，则停止分裂，将该节点标记为叶子节点，叶子节点的类别标签由当前节点中多数样本的类别决定。若不满足终止条件，则执行分裂操作。系统从四个特征中随机选取两个作为候选特征，遍历每个候选特征的所有取值作为候选阈值，计算每种分裂方式下的基尼指数加权和。选择使基尼指数最小的特征与阈值组合作为该节点的最优分裂规则。分裂规则确定后，当前节点变为内部节点，样本根据特征值与阈值的大小关系分配到左右子节点，递归调用自身继续构建左右子树。

2.6.3 训练记录

　　训练过程中系统不显式输出每棵树的详细结构，但在内存中维护trees列表存储所有构建完成的树对象。每棵树在完成构建后被追加到该列表中，供后续的预测与特征重要性计算使用。训练阶段的日志输出包括数据读取状态、编码转换结果、训练集与测试集规模、树结构构建完成提示等信息。这些日志信息打印到控制台，不写入数据库或文件。若需持久化训练记录，可扩展实现训练日志表。当前版本的训练流程未设置随机种子，bagging抽样与随机特征选择依赖Python标准库的randrange函数，其随机性来源为系统时间。这意味着同一份数据集在不同时刻运行会得到略有差异的树结构与预测结果。如需严格复现实验结果，应在训练脚本开头添加random.seed(固定值)语句。

2.7 模型评估

2.7.1 分类指标

　　模型评估阶段采用准确率、精确率、召回率、F1分数四项指标衡量分类性能。准确率计算测试集中预测正确的样本比例，公式为正确预测样本数除以总样本数。精确率针对每个类别单独计算，分子为正确预测为该类别的样本数，分母为所有被预测为该类别的样本数。召回率同样按类别计算，分子为正确预测为该类别的样本数，分母为实际属于该类别的样本数。F1分数是精确率与召回率的调和平均值，计算公式为2乘以精确率与召回率的乘积除以两者之和。这四项指标从不同角度刻画模型的分类能力，准确率反映整体正确性，精确率反映预测的可信度，召回率反映对正例的敏感程度，F1分数在两者之间取得平衡。系统调用scikit-learn库的classification_report函数一次性生成所有类别的精确率、召回率、F1分数及其宏平均与加权平均。

2.7.2 混淆矩阵

　　混淆矩阵以二维表格形式展示分类结果的详细分布。矩阵的行对应真实类别，列对应预测类别。对角线单元格的数值表示被正确分类的样本数量，非对角线单元格表示被错误分类的样本数量。对于三分类任务，混淆矩阵的规模为3×3。通过观察混淆矩阵可以识别模型在哪些类别之间容易发生混淆。例如若高风险的样本被频繁预测为中风险，说明模型在高风险与中风险的决策边界上存在模糊区域。系统使用sklearn.metrics.confusion_matrix计算混淆矩阵，随后通过seaborn的heatmap函数绘制热力图。热力图的每个单元格填充颜色深浅与数值大小对应，单元格内标注具体的样本数量。该图保存为PNG文件，文件名包含时间戳与performance标识。

2.7.3 评估结果输出

　　评估指标与混淆矩阵不直接写入数据库，而是通过两个渠道输出。第一个渠道是控制台打印，classification_report生成的表格在服务端运行时输出到终端窗口。第二个渠道是图像文件，混淆矩阵热力图与准确率柱状图合并为一张图片保存到static/output目录。图片文件名的格式为{timestamp}_random_forest_performance.png，其中timestamp精确到秒，确保每次运行生成独立的文件。该图片的访问路径拼接为相对URL后返回给前端，前端在图表弹窗中展示。若后续需要将评估指标持久化以便横向对比不同参数配置下的模型表现，可扩展实现评估结果表，记录每次训练的时间戳、样本量、各项指标数值与图片路径。

2.8 本章小结

　　本章努力形成系统总体设计方案，确立融合大数据处理技术和Web服务技术的双层架构体系，并且把功能模块细致划分开来，在文章当中着重阐述了数据采集与预处理、民宿智能推荐、交互式可视化展示以及后台运维管理这四大核心组件的设计重点内容。采用流程图来明确显示关键业务逻辑和信息传递途径，从而给后面的开发工作给予全面的技术框架支撑及操作指南参考来源。

第三章 系统详细设计

3.1 普通用户功能实现

3.1.1 注册登录功能实现

　　用户访问系统时首先进入登录页面。前端收集用户名与密码后封装为JSON格式，通过axios库向后端/api/auth/login接口发送POST请求。Django视图函数接收请求后调用认证服务，在user表中查询匹配记录。密码采用哈希存储，比对时对请求中的明文执行相同哈希算法。认证通过后服务端生成session_id写入Cookie，后续请求携带该标识维持登录状态。注册登录界面如图4.1所示。

图4.1注册登录界面

　　核心代码实现如下：

　　defpost(self, request):

data =json.loads(request.body)

username =data.get('username')

password = hashlib.md5(data.get('password').encode()).hexdigest()

user =User.objects.filter(username=username, password=password).first()

if user:

　　request.session['user_id'] =user.user_id

　　returnJsonResponse({'result': '登录成功'})

3.1.2 通知公告查看功能实现

　　系统从notice表中读取已发布的公告记录。前端页面加载时调用/api/notice/get_list接口，传递分页参数与排序条件。后端服务类执行SQL查询，按创建时间倒序返回公告列表。列表页展示公告标题与发布时间，用户点击某条记录后进入详情页面。详情页面通过公告编号从数据库中检索完整内容。前端采用懒加载策略，滚动到底部时自动请求下一页数据。通知公告查看界面如图4.2所示。

图4.2通知公告查看界面

　　核心代码实现如下：

　　defGet_list(self,ctx):

query =dict(ctx.query)

config = {"table": "notice", "orderby": "create_timedesc"}

count =self.service.Count(query, config)

lst=self.service.Get_list(query, config)

return {"result": {"list":lst, "count": count}}

3.1.3 新闻资讯查看功能实现

　　新闻资讯模块从article表中提取数据。首页展示新闻列表时仅返回标题、封面图、摘要、创建时间四个字段，减少数据传输量。用户点击某条新闻后调用/api/article/get_obj接口，传入文章编号获取完整正文内容。系统在返回正文时自动记录点击量，每访问一次详情页，对应文章的hits字段增加1。列表支持按分类类型筛选与按发布时间排序。新闻资讯查看界面如图4.3所示。

图4.3新闻资讯查看界面

　　核心代码实现如下：

　　defget_article_detail(article_id):

　　article =Article.objects.filter(article_id=article_id).first()

　　if article:

　　article.hits+= 1

　　article.save()

　　return {'title':article.title, 'content':article.content}

3.1.4 医生信息查看功能实现

　　医生信息查看模块从doctor_information表联合doctor_user表查询数据。列表页展示医生姓名、专长、照片、点赞数四个核心字段。用户点击医生卡片后进入详情页面，详情页额外显示医生简介与累计点击量。系统在详情页加载时调用/api/doctor_information/hits接口，无感增加点击量统计。列表页顶部提供专长类型筛选器，用户可按心血管内科、内分泌科等分类快速定位目标医生。医生信息查看界面如图4.4所示。

图4.4医生信息查看界面

　　核心代码实现如下：

　　defget_doctor_list(request):

　　doctors =DoctorInformation.objects.select_related('doctor_user').all()

　　result = [{'name':d.doctors_name, 'expertise':d.doctors_expertise,

　　'photo':d.photo_of_doctor, 'praise_len':d.praise_len}

　　for din doctors]

　　returnJsonResponse({'result': result})

3.1.5 诊断预约功能实现

　　用户在医生详情页点击预约按钮后进入预约表单。表单收集患者姓名、年龄、收缩压、舒张压、血糖、血脂六项信息。前端对体征数值进行范围校验，收缩压超出50-250范围时提示错误。校验通过后调用/api/diagnostic_appointment/add接口，将预约记录写入diagnostic_appointment表，状态字段初始化为0表示待确认。提交成功后跳转到预约记录列表页。诊断预约界面如图4.5所示。

图4.5诊断预约界面

　　核心代码实现如下：

　　defadd_appointment(data):

appointment =DiagnosticAppointment(

regular_user=data['user_id'],user_name=data['name'],

doctor_user=data['doctor_id'],systolic_blood_pressure=data['sbp'],

diastolic_blood_pressure=data['dbp'], status=0)

appointment.save()

return {'appointment_id':appointment.diagnostic_appointment_id}

3.1.6 诊断信息管理功能实现

　　诊断信息管理模块展示医生已完成诊断的历史记录。列表从diagnostic_information表中检索当前用户的记录，按创建时间倒序排列。每条记录显示医生姓名、诊断时间、风险等级三项关键信息。用户点击某条记录后进入详情弹窗，弹窗内展示完整的诊断结果与医生建议。该模块不提供编辑或删除功能，仅支持只读查询。诊断信息管理界面如图4.6所示。

图4.6诊断信息管理界面

　　核心代码实现如下：

　　defget_user_diagnostics(user_id):

　　records =DiagnosticInformation.objects.filter(regular_user=user_id)

　　return [{'doctor_name':r.doctors_name, 'risk_level':r.risk_level,

　　'diagnosis':r.diagnosis_result, 'create_time':r.create_time}

　　for r inrecords.order_by('-create_time')]

3.2 医生用户功能实现

3.2.1 医生信息管理功能实现

　　医生登录后进入个人中心页面。系统从doctor_information表中加载当前医生的资料数据，回填到表单各字段中。医生可修改专长描述、更新照片、调整简介内容。照片上传采用分片上传机制，文件保存到static/upload目录后返回访问路径。修改操作提交后执行UPDATE语句更新数据库，前台展示的医生信息立即同步刷新。医生信息管理界面如图4.7所示。

图4.7医生信息管理界面

　　核心代码实现如下：

　　defupdate_doctor_info(request):

　　data =json.loads(request.body)

　　DoctorInformation.objects.filter(doctor_user=request.user.id).update(

doctors_expertise=data['expertise'],

doctor_profile=data['profile'],

photo_of_doctor=data['photo'])

3.2.2 诊断预约管理功能实现

　　诊断预约管理模块展示患者向当前医生发起的预约请求。列表按预约时间倒序排列，新到达的预约请求在页面顶部显示红色标记。医生点击某条记录后查看完整的体征数据与患者信息。确认按钮将预约状态更新为1，并触发诊断信息记录的预创建。拒绝按钮弹出拒绝原因输入框，填写后状态更新为2并向患者发送消息。诊断预约管理界面如图4.8所示。

图4.8诊断预约管理界面

　　核心代码实现如下：

　　defhandle_appointment(appointment_id, action, reason=''):

　　apt =DiagnosticAppointment.objects.get(pk=appointment_id)

　　apt.status= 1 if action == 'accept' else 2

　　apt.save()

　　if action == 'accept':

　　DiagnosticInformation.objects.create(doctor_user=apt.doctor_user,

　　regular_user=apt.regular_user,risk_level='待评估')

3.2.3 数据信息预测功能实现

　　医生在预测页面输入收缩压、舒张压、血糖、血脂四个数值。前端收集参数后调用/api/data_information/get_algorithm_forecast接口。后端从data_information表抽取最多1000条样本完成模型训练，对当前输入进行推理。预测结果以JSON格式返回，前端弹窗展示风险等级。医生点击保存按钮时，将输入体征、预测结果、图表路径写入data_information_forecast表。数据信息预测界面如图4.9所示。

图4.9数据信息预测界面

　　核心代码实现如下：

　　defGet_algorithm_forecast(self,ctx):

input_value= [float(v) for v inctx.query['input_value'].split(',')]

forecast =decision_tree_forecast.Get_forecast(

source_table='data_information',

input_column=['systolic_blood_pressure','diastolic_blood_pressure',

　　'patients_blood_glucose','patient_blood_lipuser_id'],

　　input_value=input_value,forecast_column='risk_level')

3.2.4 数据信息管理功能实现

　　数据信息管理模块维护历史预测记录与训练样本。列表展示data_information_forecast表中的所有记录，支持按时间范围检索与按风险等级筛选。医生可删除错误录入的记录或修改体征数值后重新预测。编辑操作触发新的预测流程并用新结果覆盖旧记录。删除操作执行前弹出二次确认对话框，确认后执行物理删除。数据信息管理界面如图4.10所示。

图4.10数据信息管理界面

　　核心代码实现如下：

　　defupdate_forecast_record(record_id,new_values):

　　record =DataInformationForecast.objects.get(pk=record_id)

　　record.systolic_blood_pressure=new_values['sbp']

　　record.diastolic_blood_pressure=new_values['dbp']

　　record.risk_level=predict_risk(new_values)

　　record.save()

3.2.5 诊断信息管理功能实现

　　诊断信息管理模块用于填写对患者的诊断结论。系统自动加载该预约关联的患者信息与体征数据到诊断表单中。医生在诊断结果文本区域输入专业意见，风险等级字段可从预测结果中自动填充。提交后系统将诊断信息写入diagnostic_information表，患者端立即可查询到该诊断结论。已填写的诊断记录支持编辑修改。诊断信息管理界面如图4.11所示。

**

图4.11诊断信息管理界面

　　核心代码实现如下：

　　defsave_diagnosis(data):

　　diag, created =DiagnosticInformation.objects.update_or_create(

　　diagnostic_appointment_id=data['appointment_id'],

　　defaults={'risk_level': data['risk_level'],

　　'diagnosis_result': data['result']})

　　return {'diagnosis_id':diag.diagnostic_information_id}

3.3 管理员用户功能实现

3.3.1 数据信息管理功能实现

　　管理员在数据信息管理模块中对训练样本执行增删改查操作。列表页展示data_information表的所有记录，支持按风险等级筛选与按创建时间排序。新增样本时填写四项体征并选择风险等级，提交后执行INSERT操作。编辑样本时表单自动回填原有内容，修改后执行UPDATE更新对应记录。删除操作需要二次确认，确认后执行DELETE物理删除。数据信息管理界面如图4.12所示。

图4.12数据信息管理界面

　　核心代码实现如下：

　　defmanage_sample(request):

　　ifrequest.method== 'POST':

　　DataInformation.objects.create(

systolic_blood_pressure=request.POST['sbp'],

diastolic_blood_pressure=request.POST['dbp'],

risk_level=request.POST['risk'])

　　returnJsonResponse({'result': '操作成功'})

3.3.2 诊断预约管理功能实现

　　诊断预约管理模块从全局视角展示系统内所有预约记录。管理员可查看任意医生与患者之间的预约请求及其处理状态。列表支持按医生姓名筛选、按预约时间范围检索。对于异常预约，管理员有权直接取消或修改预约时间。修改操作记录到operation_log表，便于事后审计。该模块不参与常规业务流程。诊断预约管理界面如图4.13所示。

图4.13诊断预约管理界面

　　核心代码实现如下：

　　defadmin_update_appointment(appointment_id,new_time):

　　apt =DiagnosticAppointment.objects.get(pk=appointment_id)

　　apt.appointment_time=new_time

　　apt.save()

　　OperationLog.objects.create(user=request.user, action='修改预约',

　　target_id=appointment_id)

3.3.3 诊断信息管理功能实现

　　诊断信息管理模块用于监督医生填写的诊断质量。管理员查看所有诊断记录，检查风险等级判定与诊断结果是否匹配。若发现明显错误，管理员可编辑诊断信息进行修正。修正操作同样记录到operation_log表，记录修改前后的内容对比。列表页支持按医生姓名筛选与按诊断时间排序。诊断信息管理界面如图4.14所示。

图4.14诊断信息管理界面

　　核心代码实现如下：

　　defaudit_diagnosis(diagnosis_id,new_risk,new_result):

　　diag=DiagnosticInformation.objects.get(pk=diagnosis_id)

　　old_risk,old_result=diag.risk_level,diag.diagnosis_result

　　diag.risk_level,diag.diagnosis_result=new_risk,new_result

　　diag.save()

3.3.4 通知公告管理功能实现

　　管理员填写公告标题与内容后设置发布状态。已发布的公告在用户端首页的公告栏区域展示。公告支持置顶操作，置顶公告在列表中优先显示。置顶逻辑通过设置sort字段为1实现，普通公告sort字段为0。过期的公告可下线处理，下线后将status字段更新为0，前端不再展示。通知公告管理界面如图4.15所示。

图4.15通知公告管理界面

　　核心代码实现如下：

　　defpublish_notice(title, content,is_top=False):

notice =Notice(title=title, content=content,

status=1, sort=1 ifis_topelse 0)

notice.save()

3.3.5 资讯分类管理功能实现

　　资讯分类管理模块维护新闻的分类层级结构。分类表采用自关联设计，father_id字段指向父分类编号，支持无限级分类。管理员可新增、编辑、删除分类。删除分类前检查该分类下是否有关联的新闻，若有关联新闻则提示先转移或删除新闻。分类列表以树形结构展示，缩进表示层级关系。资讯分类管理界面如图4.16所示。

图4.16资讯分类管理界面

　　核心代码实现如下：

　　defdelete_category(category_id):

　　ifArticle.objects.filter(type=category_id).exists():

　　return {'error': '该分类下存在新闻，无法删除'}

　　ArticleType.objects.filter(type_id=category_id).delete()

3.3.6 新闻资讯管理功能实现

　　管理员填写新闻标题、选择分类、上传配图、编辑正文内容后提交发布。配图上传采用富文本编辑器插件，图片保存后自动插入img标签。已发布的新闻支持编辑与删除操作，编辑时表单自动回填原有内容。删除操作将新闻的status字段更新为2，前端不再展示而非物理删除，保留历史数据用于审计。新闻资讯管理界面如图4.17所示。

图4.17新闻资讯管理界面

　　核心代码实现如下：

　　defsave_article(data):

　　article, created =Article.objects.update_or_create(

　　article_id=data.get('id'),

　　defaults={'title': data['title'], 'type': data['type_id'],

　　'content': data['content'], 'status': 1})

3.3.7 操作日志管理功能实现

　　操作日志管理模块记录后台用户的敏感操作行为。日志内容包括操作用户、操作时间、访问路由、请求参数等字段。日志记录通过Django中间件拦截请求自动写入，不依赖业务代码显式调用。列表支持按用户筛选与按时间范围检索。日志记录不可修改不可删除，保证审计数据的完整性。操作日志管理界面如图4.18所示。

图4.18操作日志管理界面

　　核心代码实现如下：

　　classLogMiddleware:

　　def __call__(self, request):

　　response =self.get_response(request)

　　ifrequest.user.is_authenticated:

　　OperationLog.objects.create(user=request.user,

　　route=request.path, method=request.method)

　　return response

第四章 系统测试

4.1 测试目的

　　系统测试的根本目标在于验证已实现的软件模块是否满足需求分析阶段确定的各项功能规格。测试过程围绕业务逻辑的正确性展开，检查用户注册登录、医生信息浏览、诊断预约发起、体征数据预测、诊断信息填写等核心链路是否按预期执行。测试还关注系统的边界处理能力，包括输入校验触发时的错误提示、缺失数据提交时的拒绝机制、异常操作路径下的回退行为。数据一致性校验是测试的另一重点，验证预约记录与诊断记录的关联是否正确，预测结果保存后数据库中的字段值是否与前端展示一致。

4.2 测试方法

　　测试工作采用黑盒测试为主、白盒测试为辅的策略。黑盒测试关注功能规格的符合程度，不考虑内部实现细节。测试用例基于第三章的功能需求分析设计，覆盖正常流程与异常分支。等价类划分法将输入域划分为有效等价类与无效等价类，每个等价类至少选取一个测试样本。边界值分析法针对数值输入类型的上下边界构造测试数据。白盒测试聚焦核心预测模块，检查决策树分裂逻辑在极端输入条件下的执行路径。测试执行分为单元测试、集成测试、系统测试三个阶段。单元测试由开发人员在编码阶段完成，集成测试验证模块间接口的正确性，系统测试在完整部署环境中模拟真实用户操作。测试过程中发现的缺陷记录到问题跟踪表，修复后执行回归测试确认问题已解决。

4.3 测试用例

4.3.1 用户注册登录功能测试

　　用户注册登录测试如表6.1所示。

表6.1用户注册登录测试表

4.3.2 数据信息预测功能测试

　　数据信息预测测试如表6.2所示。

表6.2数据信息预测测试表

4.3.3 诊断预约功能测试

　　诊断预约测试如表6.3所示。

表6.3诊断预约测试表

4.3.4 医生资料管理功能测试

　　医生资料管理测试如表6.4所示。

表6.4医生资料管理测试表

4.3.5 通知公告管理功能测试

　　通知公告管理测试如表6.5所示。

表6.5通知公告管理测试表

测试结论

　　系统测试覆盖了普通用户、医生用户、管理员用户三类角色的核心功能模块。测试用例执行结果显示，用户注册登录、医生信息查看、诊断预约发起、体征数据预测、诊断信息填写、通知公告管理等主要功能均通过验证。输入校验机制在缺失数据与超出范围数值提交时正确触发错误提示。数据一致性检查表明预约记录与诊断记录的关联完整，预测结果保存后数据库字段值与前端展示一致。测试过程中发现的少量界面显示问题已完成修复。系统功能实现与需求分析文档的匹配程度较高，具备部署上线条件。

喜欢本项目的朋友可以点赞关注我，私信发【源码】就能免费领取完整项目代码