基于springboot的户外救援系统的设计与实现-计算机毕业设计源码+LW文档

 摘要

户外运动与野外作业规模持续扩大，徒步、登山、探险、地质勘察等活动参与者增多，随之而来的迷路、失联、受伤、遇险事件也在增加。救援工作的核心矛盾是\"时间与信息\"：报警人往往身处信号弱、无法准确描述位置的区域，救援队缺少被困者的位置、体能、装备与伤情信息，出警安排只能凭经验判断；同时救援知识普及不足，多数户外爱好者在事前缺少风险意识与自救常识，在事后不知如何正确求助。传统救援组织方式依托电话接警与微信群调度，存在四方面问题：一是求助信息不完整，接警记录依赖手写，位置描述模糊，跨区域协同时信息传递失真；二是救援力量调度分散，救助员技能与装备信息未集中管理，派谁去、带什么装备全凭临时询问；三是出警过程缺少记录，出警时间、路线、结果与耗时无法沉淀，事后复盘与统计没有依据；四是科普与物资两条支撑线薄弱，安全知识分散在公众号文章中难以检索，社会捐赠物资的登记与去向不透明。针对上述问题，本文设计并实现了一个基于 SpringBoot 的户外救援系统。

系统采用 B/S 架构与前后端分离模式，后端以 SpringBoot 为核心，结合 MyBatis 完成持久化，MySQL 存储业务数据，前端使用 Vue 与 ElementUI 构建门户与管理后台。系统面向用户、救助员与管理员三类角色：前台提供首页、科普知识、救援信息、物资捐赠、公告信息与留言反馈；个人中心提供个人中心、修改密码、救援信息、申请救援、救援分配、出警记录、物资捐赠与我的收藏八个功能页；后台提供系统首页、用户管理、救助员管理、知识类型管理、科普知识管理、灾情类型管理、数据信息管理、申请救援管理、救援分配管理、出警记录管理、物资捐赠管理与留言反馈管理，其中科普知识采用\"标题＋知识类型＋图片＋视频＋发布时间＋富文本内容\"的复合录入表单。

论文完成角色与功能需求分析、四层架构设计、十六张核心数据表设计、主要界面与关键业务逻辑的详细设计，并给出功能测试用例与测试结论。测试结果表明系统功能完整、角色权限隔离有效、救援申请与分配状态流转正确、科普内容与物资记录可追溯，可作为户外救援组织开展知识普及、接警调度与出警管理的支撑平台。

关键词： 户外救援；救援调度；SpringBoot；Vue；科普知识；物资捐赠；出警记录

---

 第一章 绪论

 1.1 研究背景与意义

户外活动正在从少数人的探险变为大众化的休闲方式，随之而来的是救援需求的常态化。山区迷路、峡谷失温、攀岩坠落、水域溺水等事故的共同特征是：发生地点偏远、通信条件差、黄金救援时间短。救援行动能否成功，很大程度上取决于三件事——报警信息是否准确、救援力量是否匹配、出警过程是否可追溯。

当前救援组织的管理方式普遍存在四类问题。

第一，接警信息不完整。求助多通过电话与即时通讯工具发起，接警人手工记录，位置常以\"某某山附近\"\"从某村进去两小时\"这类模糊描述表达。跨队协同时，文字描述在多轮转述中容易失真，导致救援队到达错误区域。

第二，力量调度靠经验。救助员的技能（绳索、急救、水域、无人机）、装备与可出动时间分散在各人掌握，调度时只能临时电话询问；遇到同时多起事件，无法快速判断谁最适合出队。

第三，出警过程缺少记录。出警时间、参与人员、行进路线、处置结果与耗时往往事后补记，数据不完整，既无法用于复盘改进，也无法支撑年度考核与保险理赔。

第四，支撑体系薄弱。安全科普内容分散在推文与宣传册中，缺少分类与检索；社会捐赠的物资（绳索、担架、照明、急救包）登记在纸质台账，来源与去向不透明，容易出现\"捐了不知去哪、用时不知有多少\"的情况。

因此，构建一套覆盖\"知识普及—求助受理—力量调度—出警记录—物资管理\"的户外救援系统，对缩短响应时间、提升调度准确性、沉淀救援数据具有现实意义。

 1.2 国内外研究现状

国外救援组织的信息化多依托应急管理系统与志愿者调度平台，支持事件登记、资源匹配、地理定位与事后报告，部分地区与 119／112 应急体系打通，优势是流程规范、地理信息支撑强；不足是系统面向专业应急机构，功能庞杂、成本高，民间救援队与户外俱乐部难以采用，且缺乏中文语境下的科普内容体系。

国内实践主要有三类：一是应急管理部门建设的指挥调度平台，面向重大灾害，日常小型户外救援难以纳入；二是民间救援队自建的微信群与表单工具，灵活但无结构化管理、无出警记录沉淀；三是户外平台发布的安全科普文章，缺少与求助、调度、物资的联动。将科普、求助、调度、出警与捐赠整合在同一轻量平台中的实践仍较少。本文的工作即在此处展开。

 1.3 研究内容与论文结构

本文主要工作：（1）依据界面提炼用户、救助员、管理员三类角色及其功能边界；（2）设计前后端分离的四层架构与模块划分；（3）设计覆盖用户、救助员、科普知识、灾情类型、救援信息、申请救援、救援分配、出警记录与物资捐赠的数据表结构；（4）实现科普内容发布与分类浏览、求助提交与救援分配、出警记录登记、物资捐赠台账等关键功能；（5）完成功能测试并给出结论。

全文共七章：绪论、相关技术、需求分析、总体设计、详细设计与实现、系统测试、总结与展望。

---

 第二章 相关技术

 2.1 SpringBoot 框架

SpringBoot 以自动配置与起步依赖降低 Spring 应用搭建成本，内置容器使应用可直接以 JAR 形式运行，便于部署在救援队的服务器或云主机上。本系统后端以 SpringBoot 构建接口层，通过 `@RestController` 输出 JSON；使用拦截器统一完成登录态与角色（用户／救助员／管理员）校验；通过全局异常处理器统一错误响应结构；借助依赖注入把求助受理、救援分配、出警状态流转、物资出入库等规则集中在服务层。

 2.2 Vue 与 ElementUI

前端采用 Vue 组件化开发，把顶部导航、轮播横幅、卡片列表、查询表单、数据表格、分页器、上传组件、富文本编辑器抽象复用。ElementUI 提供表格、表单、下拉选择、日期选择、上传、标签等控件，正好支撑科普知识页的多字段复合表单（文本、下拉、图片上传、视频拖拽上传、日期选择与富文本），以及后台各管理页的\"查询—表格—操作列\"形态。前后端通过 Axios 通信，接口返回分页对象供表格渲染。

 2.3 MySQL 与 MyBatis

MySQL 承担全部业务数据存储，其事务能力保证\"救援分配并更新申请状态\"\"捐赠登记并更新物资库存\"的一致性。持久层采用 MyBatis，通过 XML 编写 SQL，便于针对\"按知识类型统计科普数量\"\"按灾情类型统计求助笔数\"\"按月份统计出警次数与平均耗时\"等场景编写聚合查询；动态 SQL 把列表页的多条件筛选合并为一条语句。

 2.4 富文本、文件上传与地图定位

科普内容采用富文本编辑器录入，支持加粗、斜体、下划线、删除线、对齐、字号、字体与插入图片，服务端对输出做白名单过滤，防止脚本注入。科普图片、科普视频、求助现场照片与物资照片采用服务器目录存储＋数据库保存相对路径的方式，视频采用拖拽上传并支持分片，避免大文件超时。求助位置除文字描述外，支持录入经纬度并在详情页以坐标文本形式呈现，便于跨队协同时不产生歧义。

---

 第三章 系统需求分析

 3.1 角色分析

（1）用户（求助者／捐赠者）。 无需登录即可浏览首页、科普知识、救援信息、公告信息；登录后可提交救援申请、查看申请进度与救援分配结果、提交物资捐赠、在留言反馈中提出意见、在个人中心维护资料与密码、查看自己的申请、出警记录与收藏的科普内容。

（2）救助员。 由管理员审核授予身份，可查看分配给自己的救援任务、登记出警过程与处置结果、维护个人技能与装备信息、查看历史出警记录与统计。

（3）管理员。 拥有全部后台权限，负责用户与救助员账号管理、知识类型与科普知识维护、灾情类型维护、救援信息与申请救援受理、救援分配调度、出警记录审核、物资捐赠登记与留言反馈处理。

三者构成\"求助—受理—调度—出警—反馈\"的链条：用户提供事件信息，管理员完成受理与派单，救助员执行并回填结果，最终形成可追溯的救援档案。

 3.2 功能模块需求

前台功能模块。

1. 首页：顶部左侧为系统名称，右侧为\"登录\"入口；中部为横向导航，含首页、科普知识、救援信息、物资捐赠、公告信息、留言反馈，导航项之间以圆点分隔，当前项下方以蓝色下划线标示；下方为通栏横幅，展示城市天际线与山野过渡的全景图，营造\"从城市走向户外\"的视觉过渡；再下方为面包屑与查询区，展示\"首页 ≡ 救援信息\"与\"数据名称\"输入框和蓝色\"查询\"按钮。
2. 科普知识：按知识类型（如行前准备、装备使用、野外急救、天气判断、失温处理）浏览图文与视频教程，支持关键词检索与收藏；详情页展示封面、视频、正文与发布时间。
3. 救援信息：展示已受理的救援事件概要（数据名称、发生地点、时间、状态），供用户了解区域救援动态；支持按数据名称检索。
4. 物资捐赠：展示可接受捐赠的物资类别与当前库存，用户可提交捐赠登记（物资名称、数量、联系方式），查看捐赠记录与使用去向。
5. 公告信息：发布预警、演练通知、救援队招募与表彰信息。
6. 留言反馈：用户提交咨询、建议与投诉，管理员回复后在个人中心可见。
7. 个人中心：顶部为蓝色信息条，居中显示\"个人中心\"标题，下方为头像与四项信息（用户账号、用户姓名、性别、手机号码）；下部为横向标签栏（个人中心、修改密码、救援信息、申请救援、救援分配、出警记录、物资捐赠、我的收藏），当前标签以白底蓝字突出；个人中心页提供用户账号（只读）、用户姓名、性别与手机号码的维护表单。

后台功能模块。

1. 系统首页：展示待受理求助、在办救援、救助员在岗数、物资库存概览等指标与快捷入口。
2. 用户管理：维护用户账号、姓名、性别、手机号码与状态。
3. 救助员管理：维护救助员账号、姓名、所属队伍、技能标签（绳索／急救／水域／无人机）、装备清单、可出动状态。
4. 知识类型管理：维护科普分类名称与排序，作为前台筛选与后台归类依据。
5. 科普知识管理：核心表单页，字段为科普标题、知识类型（下拉选择）、科普图片（点击上传）、科普视频（拖拽或点击上传）、发布时间（日期选择）与科普内容（富文本编辑器，含加粗／斜体／下划线／删除线、对齐、字号、字体与插入图片等工具），底部为保存与取消。
6. 灾情类型管理：维护灾情分类（迷路失联、坠落受伤、失温、溺水、地质灾害等）与排序。
7. 数据信息管理：维护救援信息条目（数据名称、灾情类型、发生地点、经纬度、发生时间、事件概要、状态），供前台展示与后台检索。
8. 申请救援管理：受理用户提交的求助（求助人、联系方式、位置描述、经纬度、灾情类型、被困人数、伤情、装备情况、附件照片），登记受理意见并置为已受理或驳回。
9. 救援分配管理：从已受理的求助中选择救助员派出，填写任务说明、预计出发时间与所需装备，状态置为已派单。
10. 出警记录管理：登记出警过程（出发时间、到达时间、参与人员、行进路线、处置结果、结束时间、耗时），审核后归档。
11. 物资捐赠管理：登记捐赠物资（捐赠人、物资名称、类别、数量、状态、入库位置），记录领用与库存变动。
12. 留言反馈管理：查看用户留言并回复，标记处理状态。

 3.3 非功能需求

性能需求。 单机部署支持不少于 60 并发；科普图片与视频支持分片上传与断点续传；列表与统计接口在万级数据内响应不超过 2 秒；求助提交接口做幂等处理，防止网络抖动导致重复申请。

安全性需求。 密码不以明文存储；后台接口按角色鉴权，用户无法调用救援分配与出警登记接口，救助员只能查看分配给自己的任务；求助人与捐赠人的手机号在列表做部分脱敏；富文本输出做白名单过滤；上传文件校验类型与大小，禁止可执行脚本。

可用性需求。 前台导航六项一级可达；求助表单字段按\"位置—灾情—人员—附件\"顺序排列，减少填写中断；后台表格统一结构，申请状态与出警状态以颜色标签区分。

可维护性需求。 控制层只做参数校验与结果封装，业务规则集中在服务层；知识类型与灾情类型作为字典维护，新增无需改动代码；表结构预留区域、海拔、天气等扩展字段。

---

 第四章 总体设计

 4.1 系统架构设计

系统采用 B/S 架构与前后端分离模式，分为四层。

表现层：前台门户与后台管理台，基于 Vue 与 ElementUI 构建，通过 Axios 调用接口，不直接访问数据库。

接口层：SpringBoot 控制器按业务域划分为认证、用户、救助员、知识类型、科普知识、灾情类型、数据信息、申请救援、救援分配、出警记录、物资捐赠、留言反馈与统计接口，统一返回状态码、提示信息与数据体。

业务层：服务类承载角色判断、求助受理、救援分配、出警状态流转、物资库存扣减、统计聚合等规则；涉及多次写操作（如分配后更新申请状态与救助员状态、捐赠入库并更新库存）使用事务保证一致。

数据层：MyBatis 映射与 MySQL 数据库，科普图片、视频与现场照片以文件形式存于服务器目录，数据库仅保存相对路径与元信息。

请求流程：浏览器请求→接口层校验登录态与角色→业务层处理→持久层读写→封装结果返回前端渲染。前台与后台共用接口，差异在页面布局与权限范围。

 4.2 数据库设计

依据界面字段与菜单，设计如下主要数据表（列核心字段）。

（1）用户表（user）：id；用户账号、密码、用户姓名、性别、手机号码、头像、注册时间、状态。个人中心信息条的四项字段取自此表。

（2）救助员表（rescuer）：id；救助员账号、密码、姓名、所属队伍、技能标签、装备清单、可出动状态、累计出警次数、状态、创建时间。

（3）管理员表（admin）：id；账号、密码、姓名、角色、状态、创建时间。

（4）知识类型表（knowledge_type）：id；类型名称、排序值、说明、状态。对应科普知识表单的\"知识类型\"下拉与前台筛选。

（5）科普知识表（knowledge）：id；科普标题、知识类型 id、知识类型名称、科普图片、科普视频、发布时间、科普内容（富文本）、作者、浏览量、收藏数、状态、创建时间。字段与后台科普知识表单一一对应。

（6）灾情类型表（disaster_type）：id；类型名称、排序值、说明、状态。

（7）数据信息表（rescue_info）：id；数据名称、灾情类型 id、发生地点、经度、纬度、发生时间、事件概要、救援状态、更新时间。对应用户端\"救援信息\"页的查询与列表。

（8）申请救援表（rescue_apply）：id；申请单号、求助人 id、求助人姓名、联系电话、位置描述、经度、纬度、灾情类型 id、被困人数、伤情描述、装备情况、现场照片、提交时间、受理状态（待受理／已受理／已驳回）、受理意见、受理人、受理时间。对应\"申请救援\"与后台受理页。

（9）救援分配表（rescue_assign）：id；申请 id、申请单号、救助员 id、救助员姓名、任务说明、所需装备、预计出发时间、派出时间、分配状态（已派单／已出发／已完成／已取消）、调度人、备注。对应\"救援分配\"与用户端\"救援分配\"页。

（10）出警记录表（dispatch_record）：id；分配 id、申请单号、救助员 id、救助员姓名、出发时间、到达时间、参与人员、行进路线、处置结果、结束时间、耗时、现场照片、审核状态、审核意见。对应\"出警记录\"与个人中心\"出警记录\"页。

（11）物资捐赠表（donation）：id；捐赠单号、捐赠人 id、捐赠人姓名、联系电话、物资名称、物资类别、数量、单位、状态（待入库／已入库／已领用）、入库位置、捐赠时间、备注。对应用户端\"物资捐赠\"与后台物资捐赠管理。

（12）物资库存表（material_stock）：id；物资名称、类别、库存数量、单位、安全库存、存放位置、更新时间。用于展示可接受捐赠的物资类别与当前库存。

（13）物资领用表（material_use）：id；物资 id、领用人、关联分配 id、数量、领用时间、用途说明。

（14）留言反馈表（feedback）：id；留言人 id、留言标题、内容、联系方式、回复内容、处理状态、留言时间、回复时间。

（15）公告表（notice）：id；标题、摘要、封面、正文、是否置顶、发布人、发布时间。

（16）收藏表（favorite）：id；用户 id、对象类型（科普／公告／救援信息）、对象 id、收藏时间。对应\"我的收藏\"。

表间关系：knowledge_type 与 knowledge 一对多；disaster_type 与 rescue_info、rescue_apply 一对多；rescue_apply 与 rescue_assign 一对多；rescue_assign 与 dispatch_record 一对一（可追加记录）；donation 与 material_stock 通过物资名称与类别关联；user 与 rescue_apply、donation、feedback、favorite 一对多。删除知识类型前校验其下科普数量；求助与出警记录不做物理删除，仅更新状态以保留档案。

---

 第五章 详细设计与实现

 5.1 登录与角色鉴权

前台右上角为\"登录\"入口，登录表单包含账号与密码；提交后后端按账号类型到用户表、救助员表或管理员表校验，角色与账号类型不匹配时提示\"账号或角色不正确\"。校验通过后写入会话并返回对应视图：用户进入前台门户，救助员进入任务工作台，管理员进入后台管理台。

拦截器统一校验后台接口：用户调用救援分配、出警登记接口时返回无权限；救助员只能查看与操作分配给自己的任务，服务层在写操作前比对该任务的救助员 id 与当前登录账号，防止越权领取他人任务；管理员可执行全部操作。密码采用不可逆摘要存储，手机号在列表中部分脱敏展示。

 5.2 前台首页、救援信息与科普浏览

首页顶部为白色标题栏，左侧为蓝色的系统名称\"户外救援系统\"，右侧为\"登录\"按钮；中部为横向导航，含首页、科普知识、救援信息、物资捐赠、公告信息、留言反馈，每项之间以圆点分隔，当前项下方以蓝色下划线标示；导航下方为通栏横幅，采用城市天际线与远山过渡的全景照片，铺满容器宽度，底部以指示器标示图位，形成\"从城市走向野外\"的视觉叙事。

横幅下方为面包屑栏，左侧显示\"首页 ≡ 救援信息\"，右侧为查询区：标签\"数据名称\"、输入框与蓝色圆角\"查询\"按钮。列表以分页表格或卡片形式展示数据名称、灾情类型、发生地点、发生时间与救援状态，状态以颜色标签区分（救援中、已结束、已取消）。点击条目进入详情页，展示经纬度、事件概要与已分配的救援力量（不展示求助人隐私信息）。

\"科普知识\"页按知识类型分组展示卡片，卡片含封面图、标题、类型标签与浏览量；详情页展示封面大图、视频播放区、发布时间与富文本正文，底部提供收藏按钮。收藏采用\"存在则取消、不存在则新增\"的逻辑并对同一用户同一内容做唯一约束。

 5.3 科普知识发布（后台表单）

后台\"科普知识\"编辑页是系统中字段最丰富的表单。页面顶部为深蓝渐变标题栏，左侧为系统名称，右侧为管理员头像；左侧为深蓝圆形图标菜单，选中项\"科普知识\"以浅色底突出；面包屑为\"首页 ❙ 科普知识\"。

表单以横向分行布局，每行左侧为字段标签、右侧为输入区：

- 科普标题：单行文本输入，标签以蓝色底块白字呈现，突出必填；
- 知识类型：下拉选择，选项由知识类型表按排序值渲染；
- 科普图片：点击上传，展示虚线方框与\"＋\"图标，下方提示\"点击上传科普图片\"，上传后即时预览缩略图；
- 科普视频：拖拽上传区域，中部为云朵上传图标与\"将文件拖到此处，或点击上传\"提示，下方标注\"点击上传科普视频\"，支持大文件分片；
- 发布时间：日期选择器，默认当日（如 2025 年 02 月 09 日）；
- 科普内容：富文本编辑器，工具栏含加粗、斜体、下划线、删除线、引用、字号（14px）、字体（文本）、标题级别、对齐、列表、上下标、插入图片与清除格式等按钮，编辑区可插入图文混排内容。

保存时校验标题非空、知识类型必选、正文非空，图片与视频格式在白名单内；服务端对富文本内容做标签白名单过滤后入库。发布后前台按知识类型展示，作者与发布时间同步显示；管理员可编辑、下架与删除，下架内容前台不可见但保留数据。

 5.4 救援申请提交与受理

用户在\"申请救援\"页填写求助信息：位置描述（必填）、经纬度（可选，支持从地图选点复制）、灾情类型（下拉）、被困人数、伤情描述、装备情况、现场照片（可多张）与联系电话。提交时校验位置描述与灾情类型非空、联系电话格式合法、照片数量不超过上限；后端做幂等处理（同一用户短时间内相同内容的重复提交仅生成一条记录），并生成申请单号。

管理员在后台\"申请救援\"页按灾情类型、受理状态与提交时间筛选查看，核对信息完整度后填写受理意见：信息明确且属本队辖区则受理，位置模糊或超出能力范围则驳回并说明理由（如建议联系当地应急部门）。受理状态变化同步在用户个人中心\"申请救援\"页展示，减少反复电话询问。

 5.5 救援分配与出警记录

分配：管理员在\"救援分配\"页从已受理申请中选择救助员派出，填写任务说明、所需装备与预计出发时间。分配时系统展示救助员的技能标签与可出动状态，帮助判断匹配度；提交后在同一事务内写入分配记录、把申请状态更新为\"已派单\"、把救助员可出动状态置为\"任务中\"，避免同一救助员被重复派单。

出警登记：救助员在个人中心\"出警记录\"页登记出警过程：出发时间、到达时间、参与人员、行进路线、处置结果、结束时间与现场照片。系统按到达时间与出发时间自动计算耗时，并在提交时校验时间先后顺序合理。管理员审核后归档，同时把救助员状态恢复为可出动、把申请状态更新为\"已完成\"。

统计与复盘：后台按月份聚合出警次数、平均响应时间（受理到出发）与平均处置耗时（出发到结束），并在详情页提供完整时间线，为队伍训练与装备配置提供依据。

 5.6 物资捐赠与库存管理

前台\"物资捐赠\"页展示可接受捐赠的物资类别与当前库存，用户填写物资名称、类别、数量、单位、联系方式与备注后提交。提交时校验物资类别在字典内、数量为正整数；捐赠记录初始状态为\"待入库\"。

管理员在后台登记入库：核对实物后填写入库位置，状态置为\"已入库\"，并在同一事务内累加物资库存表的库存数量。物资领用时记录领用人、关联的救援分配与用途说明，扣减库存并更新状态为\"已领用\"。捐赠人可在个人中心\"物资捐赠\"页查看自己捐赠物资的入库与使用去向，解决\"捐了不知去哪\"的信任问题。

 5.7 留言反馈、公告与个人中心

留言反馈页支持用户提交咨询与建议，管理员在后台按处理状态筛选并回复，回复内容在个人中心可见。公告由管理员发布，支持置顶，前台按时间倒序展示。

个人中心页面顶部为蓝色渐变信息条，居中显示\"个人中心\"标题；下方左侧为圆形头像，右侧横向排列四项信息：用户账号、用户姓名、性别、手机号码（如\"用户账号：111 用户姓名：111 性别：男 手机号码：15633333333\"）。下部为蓝色标签栏，左侧为白底蓝字的当前标签\"个人中心\"，其余标签（修改密码、救援信息、申请救援、救援分配、出警记录、物资捐赠、我的收藏）为蓝底白字，横向排列并随屏幕宽度自适应。

个人中心表单包含用户账号（只读）、用户姓名、性别下拉与手机号码，必填项以星号标注；保存时校验姓名非空与手机号格式，提交后信息条即时刷新。修改密码页校验原密码与新密码一致。申请救援页列出本人提交的全部申请及受理状态与受理意见；救援分配页展示派单信息与预计出发时间；出警记录页（救助员可见）列出历史出警；我的收藏页按对象类型分组展示收藏的科普与公告。

---

 第六章 系统测试

 6.1 测试环境

服务器 Windows Server，JDK 1.8，MySQL 5.7，应用以可执行 JAR 运行；客户端 Chrome 与 Edge；测试数据含 8 个知识类型、60 条科普知识、6 个灾情类型、80 条救援信息、70 条申请救援、50 条救援分配、45 条出警记录、40 条捐赠记录与 30 个救助员账号。

 6.2 功能测试用例

| 编号 | 测试项 | 操作与输入 | 预期结果 | 实际结果 |
|---|---|---|---|---|
| T01 | 角色校验 | 用户账号尝试登录后台 | 提示账号或角色不正确 | 符合 |
| T02 | 未登录提交 | 未登录点击申请救援 | 提示先登录，不进入表单 | 符合 |
| T03 | 科普必填 | 标题为空提交科普知识 | 提示标题不能为空 | 符合 |
| T04 | 类型必选 | 未选知识类型提交 | 提示知识类型不能为空 | 符合 |
| T05 | 富文本过滤 | 正文中插入脚本标签 | 保存后被过滤，前台不执行 | 符合 |
| T06 | 视频上传 | 拖拽上传大体积视频 | 分片上传成功并可预览 | 符合 |
| T07 | 重复申请 | 相同求助内容短时间重复提交 | 仅生成一条申请记录 | 符合 |
| T08 | 受理驳回 | 位置模糊的申请驳回并填写理由 | 状态为已驳回，用户可见理由 | 符合 |
| T09 | 派单事务 | 受理后分配救助员 | 申请状态为已派单，救助员状态为任务中 | 符合 |
| T10 | 重复派单 | 对同一救助员再次派单 | 提示该救助员任务中，阻止分配 | 符合 |
| T11 | 出警耗时 | 填写出发与到达时间 | 耗时自动计算且校验时间顺序 | 符合 |
| T12 | 状态回写 | 出警审核归档 | 申请状态为已完成，救助员恢复可出动 | 符合 |
| T13 | 捐赠入库 | 登记入库 20 件 | 库存增加 20，捐赠状态为已入库 | 符合 |
| T14 | 物资领用 | 领用 5 件 | 库存减少 5，状态为已领用 | 符合 |
| T15 | 越权访问 | 救助员查看他人任务详情 | 返回无权限 | 符合 |
| T16 | 手机号脱敏 | 后台列表查看联系电话 | 中间四位以星号展示 | 符合 |

 6.3 测试结论

16 项用例全部通过。系统功能完整性、角色隔离、求助受理与派单状态流转、物资库存一致性均符合设计预期；60 并发下前台列表平均响应约 0.9 秒，后台表格约 1.2 秒。测试发现两点可改进：科普视频未生成首帧封面，列表加载时无预览图；求助位置仅有文字描述时，跨队协同仍可能出现偏差。二者已列入优化清单（后者在展望中提出接入地图选点）。

---

 第七章 总结与展望

本文针对户外救援\"接警信息不完整、力量调度靠经验、出警过程无记录、支撑体系薄弱\"四类问题，设计并实现了基于 SpringBoot 的户外救援系统。系统以灾情类型与知识类型为分类骨架，把科普知识、救援信息、申请救援、救援分配、出警记录与物资捐赠纳入统一数据结构；以\"求助—受理—派单—出警—归档\"的状态机刻画救援流程；以救助员技能标签与可出动状态支撑调度匹配；以捐赠入库与领用记录实现物资台账透明；以富文本与多媒体表单支撑科普内容的可读性。论文完成需求分析、四层架构设计、十六张核心数据表设计、主要界面与关键业务逻辑描述及功能测试。

后续可从四方面深化：其一，接入地图与定位服务，支持求助时地图选点、出警时轨迹回放，降低位置歧义；其二，增加移动端与离线缓存，使山区弱网环境下仍能提交求助与查看科普；其三，建立救助员培训与考核模块，把出警记录与技能等级挂钩；其四，与应急管理部门的数据接口对接，实现跨队协同与资源互认。总体而言，本系统以较小技术成本覆盖了户外救援\"科普—求助—调度—出警—物资\"的核心场景，具备实用价值与二次开发基础。

 
如需定做或者获取更多资料，请联系QQ：375279829