1. 项目概述与核心需求拆解1.1 保安公司日常管理都有哪些“痛点”保安公司这个行业的痛点和一般互联网公司差别巨大我接触了不少物业、安保行业的信息化需求这类企业最典型的问题就是“人员多、分布散、管理靠电话”。一个中等规模的保安公司通常有几百到上千名保安员派驻到几十个甚至上百个不同的客户单位比如商场、小区、写字楼、学校、银行网点。这些保安员的排班、考勤、巡逻路线是否落实公司总部其实很难实时掌握。传统的管理方式就是微信群里打卡、纸质登记巡逻本、月底人工统计考勤。问题随之暴露排班靠Excel来回发版本混乱保安员在群里发个定位截图就算签到作弊成本极低巡逻记录真假难辨客户投诉了才知道保安根本没按路线走工资核算需要文员花两三天时间整理考勤表还经常对不上。这些就是“智慧管理系统”要解决的核心问题把人员、排班、考勤、巡逻、合同、事件上报整合到一个平台里让总部看到各驻点的实时情况让队长能在线安排工作让保安员用一个手机就能完成签到、巡逻、报事。1.2 系统角色与核心业务流程这套系统面向的角色大致分为三类公司管理端总部行政、人事、运营、驻点队长现场管理、一线保安员。如果再考虑技术展示需要还可以加入一个超级管理员的角色用于系统初始化、配置客户单位和权限分配。核心业务流程围绕一条主线展开客户签约 → 合同确定服务范围和人数 → 公司指派驻点队长 → 队长制定排班表 → 保安员按排班到岗 → 手机端签到打卡 → 按巡逻路线完成打卡点巡查 → 发现异常在线上报 → 队长核实处理 → 后台形成统计数据。整个过程环环相扣任何一个环节漏了后续的考核、结算、服务质量评估就都会出问题。1.3 为什么这套系统非常适合做毕设从毕设选题的角度讲这套系统的定位很好业务场景真实、模块边界清晰、技术含量适中、容易做出可视化展示效果。它不像“网上商城”那种烂大街的选题又不会像人工智能算法研究那样需要深厚的数学基础。系统的难点恰好在于业务逻辑的串联排班影响考勤考勤关联薪资巡逻记录关联事件上报客户合同关联驻点的权限和人员配置。这种“数据之间的联动关系”正是评委想看到的业务理解深度。技术实现上不涉及复杂的算法但用到了权限管理、文件上传、地图定位、数据统计等常见技术点难度梯度合理非常适合作为课程设计和毕业设计的载体。2. 技术选型与整体架构方案2.1 后端框架Spring Boot 还是 FastAPI后端是整个系统的大脑技术选型直接决定开发周期和答辩时的技术方案质量。目前主流的选择有两个方向Java 系的 Spring Boot 和 Python 系的 FastAPI。如果是在校期间系统学过 Java Web 开发我建议优先选 Spring Boot。原因主要是生态成熟、相关教程和组件极其丰富权限框架用 Spring Security 或 Sa-Token持久层用 MyBatis-Plus几乎是为这类管理系统量身定制的。而且答辩时问“为什么选 Spring Boot”你可以从微服务生态、事务管理、安全框架、社区活跃度等角度展开技术支撑点很扎实。如果团队擅长 Python选 FastAPI 也完全没有问题。FastAPI 的编码效率高自带 OpenAPI 文档前端联调时直接看接口文档页面非常方便。但要注意如果你对 Python 不是很熟遇到一些复杂的事务处理和并发问题资料相对 Spring Boot 少一些。我的建议是不要在这个环节纠结太久选你最有把握的那个。毕设的核心是功能完整、逻辑清晰、能上线演示而不是追求某个框架本身。2.2 前端与管理端Vue 3 Element Plus 是最稳妥的路线管理后台浏览器端我最推荐 Vue 3 Element Plus 组合。Vue 3 的组合式 API 让代码组织更清晰Element Plus 的表格、表单、日期选择器、树形控件都非常适合管理类系统的界面开发。可视化大屏这一块可以用 ECharts 的折线图、饼图、地图等组件来实现例如展示今日到岗率、各驻点分布、事件处理趋势。如果想把大屏做得更炫目一些还可以用 DataV 的 React 版本或 Vue 版本拉几个现成的大屏模板来改效果非常出彩。移动端保安员使用的部分不必单独开发一个原生 App首选微信小程序。原因有三点一是保安员不用额外安装软件微信里就能打开二是小程序可以调用微信的定位接口省去自己处理 GPS 坐标转换的麻烦三是小程序的审批流程比 App 简单很多对于毕设演示完全够用。开发框架可以用原生小程序也可以用 uni-app一套代码编译到小程序和 H5。考虑到答辩时你可能会用电脑浏览器演示手机端uni-app 还能顺便编译成 H5方便在 PC 上直接演示。2.3 数据库与地图服务MySQL 与高德地图 API数据库方面尽量用 MySQL 8.0免费、稳定、资料多。如果是为了毕业设计提交可以顺便说一句“考虑到数据量级和成本选择 MySQL 这类关系型数据库已经足够没必要引入时序数据库或大数据组件”。这句话能体现你在技术选型上是思考过业务的而不是只会追新。地图服务使用的是高德地图的 Web 服务 API 和 JavaScript API关键用途有两个后端调高德 Web API将打卡上传的经纬度坐标转换为具体地址文本或者计算打卡点与目标工位的实际距离前端调高德 JavaScript API展示巡逻路线轨迹和打卡点位置。高德的开放平台提供免费的开发者配额个人认证后基本够毕设使用。申请 Key 的过程就十几分钟在控制台里创建一个 Web 服务应用获取 Key 和安全密钥即可。2.4 项目仓库结构建议综合上述技术选型推荐的前后端分离结构如下security-manage-system/ ├── backend/ # Spring Boot 项目 │ ├── src/main/java │ └── src/main/resources ├── admin-web/ # Vue3 管理后台 ├── mobile/ # 小程序或 uni-app 移动端 └── docs/ # 需求文档、数据库说明、PPT 素材前后端分离是目前的主流开发模式毕设答辩的时候评委会大概率问到“前端怎么解决跨域”你要么用后端 Spring Boot 里配置 CORS 全局跨域要么在 Vue 工程里配置 Vite 代理把/api开头的请求代理到后端端口。这是答辩必问点之一提前准备好。3. 核心功能模块设计与实操要点3.1 人员档案与资质管理保安公司运转的“底盘”保安员的信息管理和普通公司员工管理略有不同它更强调“资质”和“驻点关系”。每个保安员需要记录证件信息保安员证、健康证、消防证等、证件有效期、当前在哪个驻点、历史服务单位、奖惩记录。这个模块的设计要点在于“状态机”保安员的在岗状态应包括待入职、在岗、休假、离职、待调派。每改变一次状态系统应该自动记录一条变动日志。例如把张三从 A 小区调到 B 商场系统需要更新他的驻点关联同时生成一条“调派记录”方便后续追溯。这块用代码实现并不难难点在于逻辑设计。我见过很多同学把人员状态直接用一个字段字符串表示结果数据错了都不知道怎么查。建议至少要加一张staff_status_log表记录每次操作的动作和操作人。3.2 排班考勤与定位打卡最容易出问题的环节排班是整个系统的核心引擎。保安员按“班次”轮流上岗常见班次是白班8:00-20:00和夜班20:00-次日8:00也有的驻点是早中晚三班倒。系统需要支持“按周模板排班”也就是队长先设置一个周期模板例如第1天白班、第2天夜班、第3天休息然后系统按模板自动生成下月的排班表。排完班之后考勤就基于排班数据进行校验。保安员在小程序里打卡上传位置后端接收位置后计算出与工位坐标的距离。打卡是否有效的核心逻辑就是两个条件时间是否落在班次前后允许的容错区间内距离是否在设定阈值比如300米范围内。这一块有个常见的业务规则需要提前想清楚那就是“跨夜班次”。夜班的开始日期是今天结束日期是明天考勤统计时到底算哪一天建议统一采用“班次开始时间所在日期”作为考勤归属日期这样可以避免很多不必要的纠纷。3.3 巡逻巡查路线、点位、记录三层闭环巡查模块在保安公司系统里属于“业务亮点”非常值得认真做。一个驻点通常有多个巡查点位例如地下车库入口、配电房、消防通道、顶层天台等。管理者预先在管理后台创建巡查路线按顺序添加多个点位每个点位有名称和经纬度然后设置巡查的时间窗口。保安员到现场后走一步扫一个点小程序根据当前位置判断“是否在点位附近”如果在才允许上报巡逻记录可以拍照、填备注。所有记录都带有时间和坐标。这里我特别想强调“路线顺序校验”这个设计。很多简单的系统只判断“点到没到”但不校验“顺序对不对”。实际场景中巡查是有规定顺序的点位1到点位10必须按路线走完不能只是去点位1和点位10打卡中间的点位绕过不巡。后端可以做简单校验当前提交的点位序号必须大于最近一次提交的点位序号否则提示“巡查顺序异常”。虽然逻辑很简单但评审时会觉得你有深度的业务思考。3.4 客户合同与服务范围管理把“人”和“事”绑定起来客户合同模块是很多同学容易忽略的一块但它恰恰是把系统从“工具”提升为“平台”的关键。每个驻点一定是属于某个客户的客户签订合同后合同里会写明服务期限、服务地点、需要多少名保安员、服务范围包括哪些区域。系统设计上用户保安员驻点和客户单位是多对一关系驻点与客户单位是一对多关系。部署权限时要遵循“数据范围隔离”原则总部管理员可以看到所有数据驻点队长只能看到自己驻点的数据和人员一般保安员只能看到自己的排班和巡逻任务。这个模块可以用前端树形组件展示左侧客户单位右侧驻点列表。答辩时这块可以重点讲“多租户的简化实现方案”用一张client_contract表和station表中的client_id字段做隔离再配合后台的数据权限过滤即可不必引入真正意义上的租户隔离方案。这会让评委觉得你懂“按需设计”而不是生搬硬套。3.5 数据大屏与报表统计让系统“看起来”很聪明一个完整的智慧管理系统必须有一个让决策者“一眼看全局”的界面。数据大屏建议独立一个页面展示以下指标今日应到勤人数 / 实际到勤人数 / 到岗率今日巡逻总次数 / 漏巡任务数各驻点在岗人数排名近7天考勤趋势折线图事件上报类型分布饼图设备故障、安全隐患、突发情况等最新未处理事件滚动列表。实现上ECharts 足够支撑不需要引入重量级的数据可视化平台。做数据大屏有个心得页面首屏加载时发起多个异步请求同时向后端一次性拉取这些指标注意合理设计 API不要每个指标都单独写一个接口。可以提供一个/dashboard/summary聚合接口后端用异步线程或者直接顺序查多张表后组装返回这种聚合接口的玩法也是答辩时能讲的亮点。4. 数据库表设计用最少字段支撑核心业务数据库设计是毕设项目的灵魂不少同学在写数据库时经常出现“建了一堆表但字段之间对不上”的问题。这里给出一个经过我实际验证的合理表结构不用求全但每一张表都要真正服务于业务。表名核心字段说明sys_userid, username, password, role, station_id, real_name账号表登录身份认证client_contractid, customer_name, contract_no, start_date, end_date, service_content客户合同表stationid, client_id, station_name, address, lng, lat驻点表绑定客户和坐标staff_infoid, user_id, station_id, real_name, id_card, cert_no, cert_end_date, status保安员信息表与账号一对一绑定shift_templateid, station_id, template_name, shift_detail_json排班模板表用 JSON 存模板细节scheduleid, staff_id, station_id, shift_date, start_time, end_time排班表attendance_recordid, staff_id, schedule_id, sign_time, sign_lng, sign_lat, address, is_valid打卡记录patrol_pointid, station_id, point_name, lng, lat, order_no巡查点位表patrol_routeid, station_id, route_name, point_ids, time_window巡查路线表用逗号拼接点位IDpatrol_recordid, staff_id, point_id, record_time, lng, lat, photo_url, remark巡逻记录event_reportid, station_id, reporter_id, event_type, severity, description, status, handle_result事件上报表work_orderid, event_id, assignee_id, status, feedback, create_time工单处理表几个需要特别解释的地方shift_detail_json字段存的是排班模板的 JSON 字符串比如{1:DAY,2:NIGHT,3:OFF}。用 JSON 的好处是无需为了模板再拆多张表对于毕设来说逻辑简单实用。如果要体现更高水平可以再说明“生产环境可将 JSON 拆分为明细表但当前数据量 JSON 足够”。patrol_route表里的point_ids同样使用逗号拼接。虽然这不是关系型数据库的最佳实践但在这个场景下路线是一个固定的有序集合单独建中间表会增加复杂度性价比不高。所有表建议加上create_time、update_time字段MyBatis-Plus 的自动填充功能可以直接维护也能在答辩时展示你对公共字段处理的理解。5. 核心环节实现定位打卡与巡逻上报的关键代码5.1 后端打卡接口距离计算与幂等校验打卡是系统的第一高频接口必须处理好两个问题距离计算和重复提交。距离计算使用高德地图的坐标类或者用 Java 的 Haversine 公式手写。我建议手写逻辑很固定而且答辩时能展示你的算法功底。public double getDistance(double lat1, double lng1, double lat2, double lng2) { double radLat1 Math.toRadians(lat1); double radLat2 Math.toRadians(lat2); double a radLat1 - radLat2; double b Math.toRadians(lng1) - Math.toRadians(lng2); double s 2 * Math.asin(Math.sqrt( Math.pow(Math.sin(a / 2), 2) Math.cos(radLat1) * Math.cos(radLat2) * Math.pow(Math.sin(b / 2), 2) )); return s * 6371000; // 地球半径 6371km单位米 }打卡接口的业务逻辑是先根据当前登录用户的 user_id 查是否有今天某个班次的排班如果没排班直接返回“当前无排班任务”排班查出后读取驻点的经纬度和请求中的经纬度计算距离距离在阈值内再判断重复打卡这里需要在attendance_record表加一个唯一索引比如(schedule_id, staff_id, sign_date)这样即使前端重复提交数据库也会直接拦住。我在实际开发中遇到的坑是启动时没有判断距离直接把一次性校验通过就返回成功结果测试人员在深圳打卡成功了被大家一顿吐槽。距离参数建议先做成配置项方便答辩时现场调整比如把阈值调大一点演示效果。5.2 小程序端打卡与巡逻上报的实现思路小程序里打卡的过程很简单核心是获取经纬度然后用wx.request提交到后端。有一个值得注意的问题小程序里wx.getLocation接口需要在小程序后台申请权限同时需要用户在手机上授权否则返回的定位精度会很高但可能失败。如果怕用户拒绝授权导致打卡不了可以在界面上做一次“引导授权”的交互设计用户点打卡按钮后先检查wx.getSetting中是否有定位权限如果没有通过wx.openSetting引导用户去设置页打开定位权限。巡逻上报和打卡在代码实现上类似但要多一步“选择巡查点位”。我建议在小程序中做一个列表页面展示当前路线的所有点位保安员按顺序走到点位附近时点击“到达上报”按钮把当前定位坐标和点位坐标一起传后端校验。这个交互设计有一个细节路线点位列表的排序应该严格按 order_no 排序而不是按创建的先后顺序否则实际巡逻体验会非常混乱。初始数据入库时一定要检查点位顺序是否正确。5.3 排班生成的逻辑模板解析避免手动逐条录入排班表如果让队长每天手动录一定是不现实的。系统要支持“一键生成”队长选择一个排班模板和日期范围后端根据模板生成对应日期段内的排班记录。核心逻辑是用一个 Map 表示模板例如MapInteger, String template new HashMap(); template.put(1, DAY); // 周一白班 template.put(2, NIGHT); // 周二夜班 template.put(3, OFF); // 周三休息生成排班时遍历日期范围内的每一天取 LocalDate 的getDayOfWeek().getValue()周一到周日分别对应1-7去模板里查对应班次再结合该驻点的当时在职保安员列表循环分配。这里的“分配”有一个业务约束同一天同一个驻点不能所有人休息至少要保证最低上岗人数。可以在生成时做个简单校验日期对应的在岗人数是否大于等于该驻点配置的最低人数不满足则前端提示重新调整模板。答辩时可以把这个规则作为“业务完整性要求”来讲述。6. 实操过程从0到1开发的真实推进节奏6.1 第一阶段需求确认与原型设计我拿到这类项目时习惯的第一步不是写代码而是拉出一张表格把角色、页面、功能列清楚。这一步看起来偏管理但对后期开发的影响非常大。具体做法是角色清单超级管理员、公司管理员、驻点队长、保安员页面清单每个角色能看到哪几个页面核心流程清单比如打卡流程、巡逻流程、事件上报流程非功能性需求平均响应时间2秒以内、支持500人并发打卡、数据可视化展示。原型工具建议用 Figma 或者在线免费的墨刀。对于毕设来说原型的核心价值是让评委看到“你真的懂业务需求”甚至可以把原型截图贴到最终的设计报告里。我当时做原型花了大约3天把每个页面的布局和交互都画清楚后续写 Vue 页面时基本就是照抄自己的原型效率极高。6.2 第二阶段数据库建表和核心接口开发数据库建议先用设计器把表定义好再统一执行 SQL 脚本初始化。我不太建议直接在 Navicat 里手动改表结构很多同学改着改着就漏了字段前端联调时一堆 500 错误相当头疼。把schema.sql文件纳入项目管理所有表结构通过版本化 SQL 进行维护这种做法更容易复现和评审。接口开发建议按模块切分先做用户登录和权限这是所有功能的前提再做客户、驻点和人员管理再做排班、考勤、巡逻、事件上报最后做数据大屏的聚合接口。这个顺序符合业务依赖关系一个模块封版后再进入下一个避免代码互相影响。6.3 第三阶段前端开发与真机联调前端页面开发时我建议管理后台和小程序同步推进但联调阶段必须有先后顺序。先把管理后台与后端接口联调完成因为管理后台是管理端的核心数据录入和配置都依赖它管理端通了之后再联调小程序端的打卡、巡逻、事件上报流程。小程序真机调试时有个常见问题模拟器定位和真机定位数据不一致导致模拟器上点击打卡能成功真机上却提示“距离过远”。遇到这个情况不要怀疑代码先看高德 API 返回的经纬度与驻点实际坐标的差距。如果差距有大几百米多半是小程序的coordinateType参数没设置正确或者后端用的驻点坐标是后台手动填的其他坐标系。统一用 GCJ-02 坐标系并保证前后端都使用同一坐标系问题基本就解决了。7. 常见问题与排查技巧实录我在完成类似系统开发的过程中踩过不少坑这里挑几个有代表性的记录下来希望能帮你少走弯路。7.1 打卡定位不准或者时而成功时而不行这个现象的根源通常是坐标系不一致。小程序wx.getLocation返回的是 GCJ-02 坐标高德地图也基于 GCJ-02而 MySQL 里如果手工录入驻点坐标时从网页上直接复制了 GPS 坐标WGS-84两个坐标之间是有几百米偏差的。解决办法在后端统一做一次坐标转换或者在管理后台录入驻点坐标时直接通过地图组件选点确保记录的就是 GCJ-02 坐标。7.2 考勤统计“不生效”重复打卡的问题这是并发场景下非常经典的问题。同一个保安员在很短的时间内点了两次打卡按钮由于两个请求同时到达后端两个请求都通过了“查询是否已经打卡”的校验于是插入了两条记录。我在排查时本来以为前端做了防抖就没事其实后端必须兜底。解决方式就是给表加唯一索引数据库层面直接拒绝重复值代码层面再配合查询做提示双保险。7.3 大屏数据不刷新总觉得“卡卡的”大屏页面数据如果不更新通常是后端做了缓存或者前端的图表初始化配置有误。建议大屏的数据接口不要加缓存每次前端进入页面时重新请求。前端图表使用 ECharts 后当数据变化要调用chart.setOption(data, true)第二个参数notMerge置为 true告诉 ECharts 完全替换数据而不是合并否则会出现旧的数据点残留的诡异现象。7.4 小程序接口请求总是报域名不合法小程序要求所有请求域名必须是 HTTPS 且在小程序后台配置合法域名。开发阶段可以勾选“不校验合法域名”但答辩演示时如果用的是体验版或者开发版记得在手机预览时打开调试模式。如果想避免这个麻烦可以用本机的局域网 IP 加反向代理做临时演示但要注意手机和电脑必须处于同一局域网内。7.5 演示时怎么准备好“演示数据”避免手忙脚乱答辩前必须准备一套完整的“演示数据脚本”比如提前创建好 2 个客户、3 个驻点、5 名保安员、1个排班模板、10 个巡逻点位并且提前生成好一周的排班和打卡记录。真到答辩的时候如果用空的数据库现场演示录数据就得好几分钟观感很差。更好玩的做法是布一个定时任务每隔几分钟自动生成一条巡逻记录大屏上一直能看到数据在动演示效果非常加分。8. 项目亮点提炼与后续扩展方向8.1 答辩时可以从哪几个角度提炼技术亮点这个系统如果只是“做到了”答辩时可能显得平平无奇。建议把下列几个设计点拿出来专门准备一段话第一排班算法的“模板最低人数校验”。传统排班系统是手工填表这里通过模板自动生成并且加入最低在岗人数校验避免了所有队员同时休息的情况。第二打卡与巡逻的“双重校验机制”。系统不是只接收位置就完事而是同时校验时间窗口和空间距离后台还带唯一约束防住并发重复提交。这属于完整性的业务闭环。第三移动端与管理端的分工设计。移动端做得“轻”只处理现场执行操作管理端做得“重”承担数据配置、统计分析和决策支持。前后端分离和模块解耦的思路可以展开讲。第四数据可视化与决策辅助。大屏不只是好看的图表而是把“到岗率、漏巡率、事件及时处理率”等核心管理层关心的指标直接呈现出来相当于给保安公司管理层做了一个管理驾驶舱。8.2 后续可以扩展的功能方向如果你有余力或者想把毕设做成一个长期项目可以考虑扩展以下功能接入智能硬件例如巡逻记录仪或智能工牌自动上报位置这可以和“血氧仪方案开发”的物联网思路靠拢——所有穿戴设备都是数据采集终端增加薪资自动核算模块基于考勤、加班、补贴自动生成工资条增加培训与考试模块保安员的岗前培训和定期考核记录线上化增加公告通知和消息推送重要事件实时推送到相关负责人的微信订阅消息。从更长远的角度看这套系统完全可以嵌入到更大的物业或安防一体化平台中与视频监控、门禁事件联动这就进入了更广义的智慧园区范畴了。这个项目做到最后我个人的感触是做管理系统拼的不是某个炫技的技术点而是你能不能把业务逻辑闭环想清楚。排班、打卡、巡逻、上报每一个模块单独看都不难难的是它们之间的数据流转和状态联动。很多人觉得后台管理系统没什么技术含量但真正能在答辩现场把“为什么这样设计业务规则”讲得头头是道的同学反而不多。如果你也打算做这个方向建议多花时间在业务流程梳理上代码只是最后一步。真出了 bug也别慌先看日志再看数据把问题定位准了再改代码这本身就是对工程能力最好的锻炼。