智能无人机巡检系统产品系统

在电力巡检、农业植保、城市安防、油气管道巡查等领域，传统的人工巡检方式存在效率低、风险高、覆盖范围有限、数据难以标准化等痛点。无人机作为“空中机器人”正在大规模替代人工执行高危、重复性任务。当无人机数量从几架扩展到几十上百架时，就衍生出一个核心管理问题——如何像管理一支“空中车队”一样，高效地调度飞手、分配设备、跟踪任务进度，并确保飞行数据的完整回传。
这个系统本质上是一个“工业级无人机的地面指挥与数据中台”。它在行业中的定位具有三重属性：
1.作业标准化：将飞手的个人经验（“我觉得这个塔该拍了”）转化为组织级的标准作业程序（SOP），确保每一次飞行都有计划、有执行、有记录、有审核。
2.资产数字化：每一台无人机的累计飞行时长、起降次数、故障记录均被结构化存储，为设备全生命周期管理（何时该保养、何时该报废）提供精确的数据支撑——这正是你项目中 flight_count 和 flight_hours 增量统计的现实意义。
3.安全合规化：在国家对“低慢小”飞行器管控日趋严格的背景下，系统内置的电子围栏校验和空域报备记录，是企业获取飞行资质、避免“黑飞”处罚的合规底线。
从技术架构看，这个项目的复用边界远远超出了无人机领域。它的任务流引擎（状态机） 可以直接服务于物流配送的派单调度，它的资源占用与释放逻辑（锁机制） 可以直接移植到共享汽车的租借管理系统，它的媒体附件上传与分组可以直接用于工程项目的施工进度留档。因此，虽然业务载体是无人机，但它的技术本质是一套面向“人-机-任务”三角关系的通用调度中台——这正是它在面试中可以跨行业叙事的基础。

这个系统的核心功能可以概括为：以任务为驱动，围绕人、机、任务三方协同，实现工单全生命周期管理和资产数据闭环。

功能主要集中在五大模块：

一、任务管理
支持新建工单、下发、接受、拒绝、执行、提交审核、审核通过/驳回，以及删除等全流程操作。任务状态在“待执行→待接受→执行中→待审核→已完成/已驳回”之间流转。这是整个系统最核心的模块，面试时重点讲这部分的状态机设计。

二、无人机管理
支持无人机设备的增删改查，记录每台设备的累计飞行时长和飞行次数。任务执行完毕后，系统自动累加飞行数据。这部分面试时可以结合SQL里的 flight_hours 增量统计来讲。

三、飞手管理
基于用户权限体系，对飞手进行任务指派和状态跟踪。任务期间飞手状态被锁定，任务完成后自动释放，防止资源冲突。这部分的核心是资源并发锁，面试时可以讲如何避免飞手被重复分配。

四、围栏管理
支持禁飞区、限飞区、允许飞行区的电子围栏维护，为任务提供空域约束。高德地图集成，用于航线规划和空域校验。

五、媒体管理
任务完成后，飞手可上传现场照片和视频，按任务分组存储，支持审核时查看。这部分覆盖了文件上传、类型筛选、分组展示等通用逻辑。

这五个模块中，飞手管理实际复用用户管理模块的权限体系（permission字段），无人机管理中的state字段用于锁定/释放。贯穿整个系统的核心设计原则是：任务驱动资源变化，而非人工维护资源状态。 每次任务下发、完成、驳回，系统都会自动联动修改无人机和飞手的状态，确保“人-机-任务”三方数据始终保持一致。在面试中，这个设计理念比简单罗列功能更能体现对业务本质的理解。

本项目采用前后端分离架构，我独立完成了从需求分析、数据库设计、后端接口开发到前端页面联调的完整实现过程。
后端基于 Spring Boot 框架，结合 MyBatis 进行数据库操作，MySQL 存储业务数据。前端使用 Vue 3 + Element Plus 构建管理界面，通过 Axios 与后端进行异步通信。整体采用三层架构设计（Controller-Service-Mapper），确保业务逻辑与数据访问分离。
项目亮点与难点攻克
状态机设计：针对任务流转过程中状态混乱的问题，我梳理了完整的业务流程，将状态迁移逻辑固化在服务层，避免了前端直接修改状态字段带来的安全风险。
资源竞争问题：在飞手和无人机的并发分配场景中，通过数据库状态字段的原子性更新，避免了同一资源被同时分配给多个任务的问题。
遗留代码修复：在项目迭代过程中，对原有框架代码进行了多次重构，修复了类型转换异常（ClassCastException）和状态拦截逻辑错误等隐藏问题，增强了系统的健壮性。