搞这个项目之前我一直觉得“地铁综合服务管理系统”无非是几个增删改查页面堆在一起直到自己上手后才明白什么叫“综合”。运营调度、设备巡检、乘客服务这三块业务单独拎出来都不算复杂可一旦放进同一个SpringBoot项目里它们之间的状态联动、权限边界、数据一致性才是真正的重头戏。这篇文章是我完整跑通“基于SpringBoot的轨道交通智慧运维管理平台”之后的经验复盘覆盖了从需求拆解到表结构设计、从核心接口实现到答辩演示的整个链条。如果你正准备做类似的毕设项目或者刚入行想了解地铁运维系统的真实逻辑这篇内容应该能帮你少走不少弯路。我选择的技术底座是SpringBoot原因是它在毕设场景和真实项目中都足够“稳”。一方面SpringBoot的自动装配让我不用在配置上纠缠太久另一方面它的生态又很成熟安全认证有Spring Security数据持久化有MyBatis-Plus缓存可以上Redis前后端分离可以接Vue。但技术选型只是第一步真正拉开差距的是业务理解。所以这篇文章会花不少篇幅讲业务而不是只堆代码因为面试官和答辩老师更喜欢看到“你为什么要这么做”而不是“你怎么敲出来的”。1. 先讲清楚一套地铁综合服务系统到底在管什么很多人拿到这类题目后第一反应是去网上找一套通用后台管理系统模板然后套上“地铁”两个字就开始写代码。这么做不是不行但做完之后很容易被问到一句“你的调度逻辑在哪里体现”就卡壳。所以我会先把自己在项目启动前做的业务建模过程说清楚。1.1 运营调度不只是排班表运营调度是地铁系统的神经中枢但它不是一张简单的员工排班表。平时我们理解的调度至少包含三个层次列车运行计划的编排、车站值班人员的工作安排、突发情况下的应急调度指挥。在系统里这三个层次分别对应调度计划表、值班任务表和调度指令表。列车运行计划表记录了某条线路一天内的首末班时间、发车间隔、大小交路等信息值班任务表则把计划拆成具体的人比如某个站台在某时段需要几名站务员调度指令表更像是一个“事件驱动”的产物当列车晚点、设备故障或者客流激增时调度员手动下发指令系统把指令推送到相关岗位。我在设计时特意把“调度计划”和“调度指令”分成两张表而不是合并成一张。原因是它们的生命周期完全不同计划是静态的按天或按周生成指令是动态的只在异常时产生而且必须记录下发的操作人、下发时间、接收人和执行反馈方便事后追溯。表拆分后后续做统计报表也方便得多。1.2 设备巡检必须和调度联动的原因设备巡检看起来是纯线下工作为什么要和调度联动打个比方某站台A的闸机在早高峰前报修了按照巡检流程巡检员会上报故障并生成工单维修人员接单处理。但如果系统不和调度联动调度员可能根本不知道这个闸机停摆早高峰时还在按原计划引导乘客走这个闸机口结果现场乱成一团。所以我在设计里给故障设备加了一个“影响等级”字段一旦巡检员上报的故障等级是“紧急”系统会同时生成维修工单和调度提示事件调度员在调度台首页就能看到。另一个联动的点是巡检路线本身受运行时段影响。比如列车运行的高峰期巡检员不能进入轨行区只能进行站台层和站厅层巡检只有在非运营时段或者“天窗点”才能下轨行区。系统里就给巡检点做了时段属性巡检员扫码打卡时后台会校验当前时间是否允许巡检该位置不符合条件的打卡会被标记为异常并提醒调度员。1.3 “综合服务”四个字落在哪综合服务模块是面向乘客和运营管理人员双向的。乘客侧能看到线路公告、首末班时间、失物招领、投诉建议反馈管理侧则要维护这些公告、处理投诉、配置车站服务设施信息。这一块虽然不涉及实时调度但它有一个容易忽略的价值所有乘客反馈数据都能沉淀下来变成设备巡检和调度优化的输入。举个例子乘客多次反馈某站台自动扶梯声音异常系统在收集这些反馈后可以按车站、设备类型做热度统计运营人员就能把这条反馈转成一条“重点巡检任务”下发给巡检组。这就是综合服务和运维管理之间的一个闭环。我的项目里专门有一个“反馈转工单”的功能按钮就是用来体现这个闭环的。2. SpringBoot技术选型从“能跑”到“够用”的取舍2.1 为什么我把SpringBoot作为唯一后端底座后端框架可选的不算多老项目还在用SSM新项目往往直接SpringBoot也有用微服务套装的。但地铁运维这类项目单体应用完全够用强行上微服务只会让部署和调试变得更复杂。SpringBoot最大的价值在于它的自动配置和约定优于配置我只需要在pom.xml里引入对应场景的starter大部分基础组件就能直接工作不用手写一堆XML配置。我用的是SpringBoot 2.7.x版本而不是最新的3.x。原因有两个一是3.x从Java 17起步如果本机环境还停留在JDK 8切来切去很麻烦二是很多第三方组件对3.x的适配还没有完全跟上尤其是一些教程、示例代码大多基于2.x遇到问题网上能搜到的解决方案更多。对于毕设和项目实战来说稳定性优先。2.2 配套组件的选择与理由后端核心搭配是SpringBoot MyBatis-Plus MySQL Redis。MyBatis-Plus比较适合国内开发者的习惯它能在不写SQL的情况下完成大部分单表CRUD还提供了分页插件和条件构造器开发效率很高。Redis主要用来做三件事会话状态的缓存、调度指令的临时推送队列、巡检二维码的短时令牌。前端我没有用特别花哨的框架基础版选了Vue2 Element-UI因为网上资料多遇到问题容易解决。如果想在演示时更有冲击力可以在项目里单独拆一个页面用ECharts做数据可视化大屏。前后端通过RESTful接口通信用JWT做无状态认证这样就不需要依赖服务端Session部署也简单。2.3 项目结构分层逻辑和模块边界项目结构的坑在于“包路径乱”。我见过不少项目把controller、service、mapper三层分得清楚但业务模块之间互相乱调比如巡检模块的Service里直接去查调度模块的Mapper。刚开始开发会很快后面改需求时会痛苦到怀疑人生。我自己的做法是包结构先按技术分层再按业务模块归组com.metro.system ├── common // 通用工具、统一返回结果 ├── config // 配置类如Redis、跨域 ├── security // 认证授权 ├── module │ ├── dispatch // 运营调度 │ ├── inspect // 设备巡检 │ ├── service // 综合服务 │ └── system // 用户角色菜单业务模块之间只允许通过Service接口访问不允许Controller直接跨越。比如综合服务要把乘客反馈转成巡检工单我会在service模块里封装一个FeedbackConvertService它内部调用inspect模块的工单Service而不是在service的Controller里直接注入inspect的Mapper。这样每个模块的边界是清晰的后面单独取出来复用或者扩展都容易得多。3. 数据库与模型设计调度、巡检、服务三张网怎么织数据库设计是整个项目的定盘星。表如果设计得不好后面写业务代码时会被迫写出一堆奇怪的判断逻辑。我按领域拆分成三组核心表再加上用户权限相关的表总共二十多张。这里挑最关键的几张表讲一下。3.1 调度域核心表表名关键字段作用train_scheduleline_no, start_time, end_time, interval_min, is_holiday, status维护某条线路在某天的运行计划station_staff_taskschedule_id, station_no, shift_type, staff_id, task_date把车站人员的排班任务落到具体日期和班次dispatch_commandcommand_no, type, content, sender_id, receiver_id, status, create_time, feedback记录调度指令的完整下发链路station_incidentstation_no, incident_type, level, description, status记录站点突发事件并关联调度指令运营调度的核心需求是“人员和事件都能被追踪”。所以每张表里都尽量包含状态和时间的生命周期字段。比如dispatch_command的状态就有待接收、已接收、处理中、已完成、已超时后端通过定时任务扫描超时未完成指令并提醒。3.2 巡检域核心表表名关键字段作用device_infodevice_code, device_name, station_no, location, device_type, install_date, last_maintain_date设备台账统一管理所有设备的基础信息inspect_routeroute_name, route_desc, applicable_line, route_type定义巡检路线比如站厅层、站台层、轨行区inspect_pointroute_id, point_name, qr_code, sort_no, inspect_time_type巡检路线下的具体巡检点每个点有唯一的二维码编码inspect_tasktask_no, route_id, inspect_date, inspect_user_id, status按天生成的巡检任务inspect_recordrecord_no, inspect_task_id, point_id, inspect_time, is_normal, remark巡检打卡结果记录repair_orderorder_no, source_type, source_id, device_id, fault_desc, level, status维修工单可来源于巡检或乘客反馈巡检模块最容易忽略的是“点”和“路线”的关系。一个巡检点可能在多条路线里复用比如某个消防设备既是站厅层路线的一站也是重点设备巡查路线的一站。所以我没有把巡检点直接挂在线路上而是用中间关联表来维护多对多关系。这样周末临时加一条检查路线时只需要新建路线并绑定原有巡检点不用重新生成设备清单。3.3 服务域核心表表名关键字段作用noticetitle, content, publish_time, publish_user_id, target_type, status公告信息发布时可指定对所有乘客或对指定车站lost_founditem_name, find_station, find_time, status, claimant_name, claim_time失物招领记录passenger_feedbackfeedback_type, content, contact, station_no, process_status, create_time乘客反馈支持投诉、建议、表扬等类型station_servicestation_no, service_name, service_desc, open_time, status车站服务设施信息如便利店、卫生间、无障碍电梯等服务域看起来简单但涉及一个跨模块问题乘客反馈需要转成巡检或维修工单。我在passenger_feedback表里预留了一个source_id字段和process_status字段当一条反馈被转成工单后process_status变成“已转工单”同时source_id填上生成的工单号。这样两端都能看到对应关系避免数据被重复处理。3.4 表关系如何避免冗余设计时最容易犯的错是把“站名”和“线路名”这种基础数据直接写到业务表里。比如dispatch_command里直接存一个line_name字符串好处是查询简单坏处是如果改线路名称所有历史数据都得跟着改。我采用的方式是业务表只存ID或编号查询时连表展示名称。虽然SQL多写一个join但数据一致性更稳。另一个容易忽略的点是统一编号规则。所有主键我都使用自增主键但对外暴露的业务编号如工单号、指令号、任务号单独生成格式类似WO20250607001里面包含年月日和后缀序号。这么做不光是好看还方便在日志和演示时一眼看出这条记录是什么时候产生的。4. 关键功能实战从登录到调度下发的完整链路4.1 Spring Security JWT 多角色登录系统里有三种主要角色系统管理员、调度员、巡检员。乘客端和管理后台分开管理后台统一走Spring Security认证。这里有个小经验不要自己手写拦截器去判断登录状态直接用Spring Security做安全过滤器代码更规范答辩时也能讲清楚。核心逻辑是用户登录成功后生成JWT令牌后面每个请求都会携带这个令牌后端通过过滤器解析令牌获取用户ID、角色列表和权限标识。我封装了一个自定义的PermissionService在Controller方法上使用PreAuthorize(hasPermission(dispatch:command:send))这样的注解控制访问权限。多角色登录的难点在于同一个用户可能既是调度员又是巡检员这时不能只返回一个角色而是要返回角色集合权限判断要遍历集合。PostMapping(/login) public Result login(RequestBody LoginRequest loginRequest) { User user userService.findByUsername(loginRequest.getUsername()); if (user null || !passwordEncoder.matches(loginRequest.getPassword(), user.getPassword())) { return Result.error(用户名或密码错误); } ListString roles userRoleService.findRoleCodesByUserId(user.getId()); ListString permissions permissionService.findPermissionCodesByRoleCodes(roles); String token JwtUtil.createToken(user.getId(), user.getUsername(), roles, permissions); return Result.success(new LoginResponse(token, user, roles)); }JWT的有效期建议设置成半天别设太长。如果演示过程中发现权限变更没生效直接让用户重新登录就行。4.2 调度指令下发与回写调度指令下发看着是个普通的插入接口关键在于“接收人”怎么确定。我在设计时不是让调度员手动选人而是通过“岗位”来匹配比如指令类型是“站台疏导”系统自动查询当前时段该车站所有站务员在线用户并推送提醒。这样即便调度员不清楚具体值班人员名单指令也能准确到达相关人。推送提醒我用的不是WebSocket实时在线推送因为那套方案在部署时要额外开长连接增加了复杂度。我的做法是双通道Redis的临时队列里存一条待办事件前台页面每隔30秒轮询一次待办接口同时如果用户当前在线并且浏览器支持WebSocket再补一条实时通知。轮询的延迟虽然有一点点但对地铁调度场景足够用了。关键是指令的状态要能回写接收人点击“接收”后指令状态从“待接收”变成“已接收”这比推送本身更重要。4.3 二维码巡检打卡与异常上报二维码巡检打卡是演示时最抓眼球的模块。原本的思路是巡检员用手机扫贴在设备上的二维码但毕设场景不可能真的打印二维码我就在每个巡检点上生成一个不易重复的编号利用Hutool工具生成QR码图片前端页面根据设备ID实时渲染出来。扫码之后会把deviceCode回传到后端后端生成打卡记录。打卡接口要防止重复提交。巡检员可能在两分钟内重复扫同一个点第一次是正常打卡第二次就应该提示“您已完成该点位巡检”。这里我用了Redis的键来标记某次任务下某个巡检点是否已经打卡键的格式是inspect:record:{taskId}:{pointId}过期时间设为24小时。如果用户要求重新打卡需要巡检组长人工重置状态。PostMapping(/checkpoint) public Result checkPoint(RequestBody CheckPointRequest request) { String key inspect:record: request.getTaskId() : request.getPointId(); Boolean firstCheck redisTemplate.opsForValue().setIfAbsent(key, 1, Duration.ofHours(24)); if (firstCheck ! null firstCheck) { inspectRecordService.createRecord(request); return Result.success(打卡成功); } return Result.error(该点位已完成巡检如需重新打卡请联系组长重置); }巡检异常上报则要联动工单上报时会要求填写故障描述并选择影响等级。等级为“高”时系统自动创建维修工单并给调度台推送一条提示。4.4 Redis缓存与接口性能优化地铁项目的数据量虽不像电商那样夸张但设备状态查询和调度指令列表如果每次都查数据库页面响应依然会慢。我的优化策略分三级基础字典数据放进Redis永久缓存并设置主动刷新设备台账列表做本地缓存设置5分钟过期核心的实时数据如当前指令状态、当前在线人数不做缓存保持查询最新。列表查询一定要用MyBatis-Plus的分页插件并且避免在循环里查数据库。比如加载巡检任务列表时需要显示任务关联的路线名称和巡检人姓名我会先查出任务列表收集路线ID和用户ID再用in批量查询最后在内存里组装。这个优化能把接口响应时间从几百毫秒压到几十毫秒在演示时效果特别明显。5. 那些我一踩就是一下午的坑5.1 SpringBoot版本和依赖冲突SpringBoot 2.7.x本身没太大问题但引入其他组件时版本匹配就是一个坑。我一开始给项目加了Spring Cloud提供的某个工具包结果启动时直接报NoSuchBeanDefinition查了半天发现是依赖传递把Spring Boot版本从2.7拉到了2.4。后来我养成一个习惯所有第三方依赖都在pom.xml的properties里显式声明版本号不让它自己传递。Spring Boot的每个starter都有自己的版本管理一般不要手动改但第三方包必须要锁定版本。properties java.version1.8/java.version spring-boot.version2.7.13/spring-boot.version mybatis-plus.version3.5.3.1/mybatis-plus.version hutool.version5.8.22/hutool.version /properties5.2 MyBatis-Plus分页插件不生效很多人写好分页代码后发现返回数据仍然是一整页全量数据很多情况下是没有配置分页插件。MyBatis-Plus在SpringBoot里使用分页功能时必须注入一个PaginationInnerInterceptor否则Page对象起不到拦截SQL的作用。我最初漏掉了这一步排查了很久才意识到是配置问题。Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }这个配置类很小但忘了它就会浪费一下午。5.3 前端日期与Jackson序列化时区问题前后端分离的项目时间字段的坑特别经典。数据库里存的LocalDateTime在Jackson序列化后默认是带T的ISO字符串前端Element-UI的el-date-picker不认这种格式直接显示成NaN。后来我在配置类里统一格式化spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8但只配这个还不够LocalDateTime类型需要额外加Java Time模块的序列化支持SpringBoot自动装配一般会处理但如果自定义了ObjectMapper很容易失效。所以我干脆在字段上用JsonFormat(pattern yyyy-MM-dd HH:mm:ss, timezone GMT8)一劳永逸。5.4 设备状态查询的N1与慢SQL设备管理页面要显示每台设备的最近维修时间和状态一开始我是先查设备列表再循环查维修记录结果一次列表接口愣是查了十几秒。后来改成SQL联表查询用LEFT JOIN一次把最近维修时间带出来。但这样又引入了新问题LEFT JOIN后设备列表重复了因为一台设备可能有多条维修记录。解决方案是用子查询取每个设备最新的维修时间SELECT d.*, r.last_maintain_date FROM device_info d LEFT JOIN ( SELECT device_id, MAX(create_time) AS last_maintain_date FROM repair_order WHERE status 已完成 GROUP BY device_id ) r ON d.id r.device_id这类优化在面试时很加分因为它体现了对真实数据量和SQL性能的思考。6. 让项目在演示和答辩时不翻车的细节6.1 真实感演示数据的构造很多人的系统功能没问题但演示效果不好原因是数据太假。比如巡检记录里每条记录都是同一天的同一个时间调度指令里所有内容都是“测试”。为了让演示有说服力我写了一个数据初始化工具类一次生成一个月的数据并且保证数据在时间上是连续的。比如生成巡检任务时规定工作日和节假日的巡检路线略有不同这样看到任务列表的人会觉得“确实符合实际”。数据量别太大也别太小。设备台账六十条左右、巡检任务每个任务带十条打卡记录、调度指令近五十条这样页面既有翻页效果又不会因为数据过多而卡顿。数据生成后建议把SQL脚本保存下来随时可以重建一套干净数据。6.2 大屏数据接口的设计如果系统带一个数据可视化大屏答辩时非常加分。大屏页面通常是只读的我在后端单独写了几个聚合接口比如当日客运量趋势、线路运行正点率、设备故障率、巡检完成情况。聚合接口用Mapper里的自定义SQL一次查出统计数据不要在Java内存里遍历计算。一个大屏接口大概返回这样的JSON结构{ line: [{lineNo: 1号线, onTimeRate: 98.2}, ...], inspection: { total: 120, finished: 108, abnormal: 5 }, feedback: { total: 45, unsolved: 8 } }大屏页面每5秒轮询一次接口刷新时注意给loading状态避免因为接口慢导致图表闪动。6.3 高频问题与应答思路答辩时老师大概率会问三类问题为什么选这个架构、某张表为什么这么设计、系统能扛住多大的并发。最后一个问题一定不要吹“高性能”地铁项目的真实场景并发量并不恐怖重点是数据准确和流程闭环。可以回答系统核心不在高并发而在调度指令和设备状态的一致性Redis缓存用于缓解热点查询数据库层面做了必要索引足够支撑单条线路级别的日常运维。还有一个高频问题是“你的系统和已有的人工管理流程相比最大的改进是什么”。建议回答“把调度、巡检、乘客反馈的数据孤岛打通了工单能自动联动异常事件能被追踪形成了闭环。”这句话比列十个功能点都有说服力。最后再分享一个实际操作心得这类管理系统项目代码量其实并不重要重要的是“把业务讲圆”。我在做的时候每完成一个模块都会自己扮演调度员、巡检员、乘客三个角色把整个流程走一遍。很多逻辑漏洞就是这么试出来的。比如有一次我发现巡检任务在国庆节那天没有自动生成就是因为没配置节假日规则。像这种小细节往往才是真正让项目脱胎换骨的地方。
基于SpringBoot的轨道交通智慧运维管理平台：从调度到巡检的闭环实践
搞这个项目之前我一直觉得“地铁综合服务管理系统”无非是几个增删改查页面堆在一起直到自己上手后才明白什么叫“综合”。运营调度、设备巡检、乘客服务这三块业务单独拎出来都不算复杂可一旦放进同一个SpringBoot项目里它们之间的状态联动、权限边界、数据一致性才是真正的重头戏。这篇文章是我完整跑通“基于SpringBoot的轨道交通智慧运维管理平台”之后的经验复盘覆盖了从需求拆解到表结构设计、从核心接口实现到答辩演示的整个链条。如果你正准备做类似的毕设项目或者刚入行想了解地铁运维系统的真实逻辑这篇内容应该能帮你少走不少弯路。我选择的技术底座是SpringBoot原因是它在毕设场景和真实项目中都足够“稳”。一方面SpringBoot的自动装配让我不用在配置上纠缠太久另一方面它的生态又很成熟安全认证有Spring Security数据持久化有MyBatis-Plus缓存可以上Redis前后端分离可以接Vue。但技术选型只是第一步真正拉开差距的是业务理解。所以这篇文章会花不少篇幅讲业务而不是只堆代码因为面试官和答辩老师更喜欢看到“你为什么要这么做”而不是“你怎么敲出来的”。1. 先讲清楚一套地铁综合服务系统到底在管什么很多人拿到这类题目后第一反应是去网上找一套通用后台管理系统模板然后套上“地铁”两个字就开始写代码。这么做不是不行但做完之后很容易被问到一句“你的调度逻辑在哪里体现”就卡壳。所以我会先把自己在项目启动前做的业务建模过程说清楚。1.1 运营调度不只是排班表运营调度是地铁系统的神经中枢但它不是一张简单的员工排班表。平时我们理解的调度至少包含三个层次列车运行计划的编排、车站值班人员的工作安排、突发情况下的应急调度指挥。在系统里这三个层次分别对应调度计划表、值班任务表和调度指令表。列车运行计划表记录了某条线路一天内的首末班时间、发车间隔、大小交路等信息值班任务表则把计划拆成具体的人比如某个站台在某时段需要几名站务员调度指令表更像是一个“事件驱动”的产物当列车晚点、设备故障或者客流激增时调度员手动下发指令系统把指令推送到相关岗位。我在设计时特意把“调度计划”和“调度指令”分成两张表而不是合并成一张。原因是它们的生命周期完全不同计划是静态的按天或按周生成指令是动态的只在异常时产生而且必须记录下发的操作人、下发时间、接收人和执行反馈方便事后追溯。表拆分后后续做统计报表也方便得多。1.2 设备巡检必须和调度联动的原因设备巡检看起来是纯线下工作为什么要和调度联动打个比方某站台A的闸机在早高峰前报修了按照巡检流程巡检员会上报故障并生成工单维修人员接单处理。但如果系统不和调度联动调度员可能根本不知道这个闸机停摆早高峰时还在按原计划引导乘客走这个闸机口结果现场乱成一团。所以我在设计里给故障设备加了一个“影响等级”字段一旦巡检员上报的故障等级是“紧急”系统会同时生成维修工单和调度提示事件调度员在调度台首页就能看到。另一个联动的点是巡检路线本身受运行时段影响。比如列车运行的高峰期巡检员不能进入轨行区只能进行站台层和站厅层巡检只有在非运营时段或者“天窗点”才能下轨行区。系统里就给巡检点做了时段属性巡检员扫码打卡时后台会校验当前时间是否允许巡检该位置不符合条件的打卡会被标记为异常并提醒调度员。1.3 “综合服务”四个字落在哪综合服务模块是面向乘客和运营管理人员双向的。乘客侧能看到线路公告、首末班时间、失物招领、投诉建议反馈管理侧则要维护这些公告、处理投诉、配置车站服务设施信息。这一块虽然不涉及实时调度但它有一个容易忽略的价值所有乘客反馈数据都能沉淀下来变成设备巡检和调度优化的输入。举个例子乘客多次反馈某站台自动扶梯声音异常系统在收集这些反馈后可以按车站、设备类型做热度统计运营人员就能把这条反馈转成一条“重点巡检任务”下发给巡检组。这就是综合服务和运维管理之间的一个闭环。我的项目里专门有一个“反馈转工单”的功能按钮就是用来体现这个闭环的。2. SpringBoot技术选型从“能跑”到“够用”的取舍2.1 为什么我把SpringBoot作为唯一后端底座后端框架可选的不算多老项目还在用SSM新项目往往直接SpringBoot也有用微服务套装的。但地铁运维这类项目单体应用完全够用强行上微服务只会让部署和调试变得更复杂。SpringBoot最大的价值在于它的自动配置和约定优于配置我只需要在pom.xml里引入对应场景的starter大部分基础组件就能直接工作不用手写一堆XML配置。我用的是SpringBoot 2.7.x版本而不是最新的3.x。原因有两个一是3.x从Java 17起步如果本机环境还停留在JDK 8切来切去很麻烦二是很多第三方组件对3.x的适配还没有完全跟上尤其是一些教程、示例代码大多基于2.x遇到问题网上能搜到的解决方案更多。对于毕设和项目实战来说稳定性优先。2.2 配套组件的选择与理由后端核心搭配是SpringBoot MyBatis-Plus MySQL Redis。MyBatis-Plus比较适合国内开发者的习惯它能在不写SQL的情况下完成大部分单表CRUD还提供了分页插件和条件构造器开发效率很高。Redis主要用来做三件事会话状态的缓存、调度指令的临时推送队列、巡检二维码的短时令牌。前端我没有用特别花哨的框架基础版选了Vue2 Element-UI因为网上资料多遇到问题容易解决。如果想在演示时更有冲击力可以在项目里单独拆一个页面用ECharts做数据可视化大屏。前后端通过RESTful接口通信用JWT做无状态认证这样就不需要依赖服务端Session部署也简单。2.3 项目结构分层逻辑和模块边界项目结构的坑在于“包路径乱”。我见过不少项目把controller、service、mapper三层分得清楚但业务模块之间互相乱调比如巡检模块的Service里直接去查调度模块的Mapper。刚开始开发会很快后面改需求时会痛苦到怀疑人生。我自己的做法是包结构先按技术分层再按业务模块归组com.metro.system ├── common // 通用工具、统一返回结果 ├── config // 配置类如Redis、跨域 ├── security // 认证授权 ├── module │ ├── dispatch // 运营调度 │ ├── inspect // 设备巡检 │ ├── service // 综合服务 │ └── system // 用户角色菜单业务模块之间只允许通过Service接口访问不允许Controller直接跨越。比如综合服务要把乘客反馈转成巡检工单我会在service模块里封装一个FeedbackConvertService它内部调用inspect模块的工单Service而不是在service的Controller里直接注入inspect的Mapper。这样每个模块的边界是清晰的后面单独取出来复用或者扩展都容易得多。3. 数据库与模型设计调度、巡检、服务三张网怎么织数据库设计是整个项目的定盘星。表如果设计得不好后面写业务代码时会被迫写出一堆奇怪的判断逻辑。我按领域拆分成三组核心表再加上用户权限相关的表总共二十多张。这里挑最关键的几张表讲一下。3.1 调度域核心表表名关键字段作用train_scheduleline_no, start_time, end_time, interval_min, is_holiday, status维护某条线路在某天的运行计划station_staff_taskschedule_id, station_no, shift_type, staff_id, task_date把车站人员的排班任务落到具体日期和班次dispatch_commandcommand_no, type, content, sender_id, receiver_id, status, create_time, feedback记录调度指令的完整下发链路station_incidentstation_no, incident_type, level, description, status记录站点突发事件并关联调度指令运营调度的核心需求是“人员和事件都能被追踪”。所以每张表里都尽量包含状态和时间的生命周期字段。比如dispatch_command的状态就有待接收、已接收、处理中、已完成、已超时后端通过定时任务扫描超时未完成指令并提醒。3.2 巡检域核心表表名关键字段作用device_infodevice_code, device_name, station_no, location, device_type, install_date, last_maintain_date设备台账统一管理所有设备的基础信息inspect_routeroute_name, route_desc, applicable_line, route_type定义巡检路线比如站厅层、站台层、轨行区inspect_pointroute_id, point_name, qr_code, sort_no, inspect_time_type巡检路线下的具体巡检点每个点有唯一的二维码编码inspect_tasktask_no, route_id, inspect_date, inspect_user_id, status按天生成的巡检任务inspect_recordrecord_no, inspect_task_id, point_id, inspect_time, is_normal, remark巡检打卡结果记录repair_orderorder_no, source_type, source_id, device_id, fault_desc, level, status维修工单可来源于巡检或乘客反馈巡检模块最容易忽略的是“点”和“路线”的关系。一个巡检点可能在多条路线里复用比如某个消防设备既是站厅层路线的一站也是重点设备巡查路线的一站。所以我没有把巡检点直接挂在线路上而是用中间关联表来维护多对多关系。这样周末临时加一条检查路线时只需要新建路线并绑定原有巡检点不用重新生成设备清单。3.3 服务域核心表表名关键字段作用noticetitle, content, publish_time, publish_user_id, target_type, status公告信息发布时可指定对所有乘客或对指定车站lost_founditem_name, find_station, find_time, status, claimant_name, claim_time失物招领记录passenger_feedbackfeedback_type, content, contact, station_no, process_status, create_time乘客反馈支持投诉、建议、表扬等类型station_servicestation_no, service_name, service_desc, open_time, status车站服务设施信息如便利店、卫生间、无障碍电梯等服务域看起来简单但涉及一个跨模块问题乘客反馈需要转成巡检或维修工单。我在passenger_feedback表里预留了一个source_id字段和process_status字段当一条反馈被转成工单后process_status变成“已转工单”同时source_id填上生成的工单号。这样两端都能看到对应关系避免数据被重复处理。3.4 表关系如何避免冗余设计时最容易犯的错是把“站名”和“线路名”这种基础数据直接写到业务表里。比如dispatch_command里直接存一个line_name字符串好处是查询简单坏处是如果改线路名称所有历史数据都得跟着改。我采用的方式是业务表只存ID或编号查询时连表展示名称。虽然SQL多写一个join但数据一致性更稳。另一个容易忽略的点是统一编号规则。所有主键我都使用自增主键但对外暴露的业务编号如工单号、指令号、任务号单独生成格式类似WO20250607001里面包含年月日和后缀序号。这么做不光是好看还方便在日志和演示时一眼看出这条记录是什么时候产生的。4. 关键功能实战从登录到调度下发的完整链路4.1 Spring Security JWT 多角色登录系统里有三种主要角色系统管理员、调度员、巡检员。乘客端和管理后台分开管理后台统一走Spring Security认证。这里有个小经验不要自己手写拦截器去判断登录状态直接用Spring Security做安全过滤器代码更规范答辩时也能讲清楚。核心逻辑是用户登录成功后生成JWT令牌后面每个请求都会携带这个令牌后端通过过滤器解析令牌获取用户ID、角色列表和权限标识。我封装了一个自定义的PermissionService在Controller方法上使用PreAuthorize(hasPermission(dispatch:command:send))这样的注解控制访问权限。多角色登录的难点在于同一个用户可能既是调度员又是巡检员这时不能只返回一个角色而是要返回角色集合权限判断要遍历集合。PostMapping(/login) public Result login(RequestBody LoginRequest loginRequest) { User user userService.findByUsername(loginRequest.getUsername()); if (user null || !passwordEncoder.matches(loginRequest.getPassword(), user.getPassword())) { return Result.error(用户名或密码错误); } ListString roles userRoleService.findRoleCodesByUserId(user.getId()); ListString permissions permissionService.findPermissionCodesByRoleCodes(roles); String token JwtUtil.createToken(user.getId(), user.getUsername(), roles, permissions); return Result.success(new LoginResponse(token, user, roles)); }JWT的有效期建议设置成半天别设太长。如果演示过程中发现权限变更没生效直接让用户重新登录就行。4.2 调度指令下发与回写调度指令下发看着是个普通的插入接口关键在于“接收人”怎么确定。我在设计时不是让调度员手动选人而是通过“岗位”来匹配比如指令类型是“站台疏导”系统自动查询当前时段该车站所有站务员在线用户并推送提醒。这样即便调度员不清楚具体值班人员名单指令也能准确到达相关人。推送提醒我用的不是WebSocket实时在线推送因为那套方案在部署时要额外开长连接增加了复杂度。我的做法是双通道Redis的临时队列里存一条待办事件前台页面每隔30秒轮询一次待办接口同时如果用户当前在线并且浏览器支持WebSocket再补一条实时通知。轮询的延迟虽然有一点点但对地铁调度场景足够用了。关键是指令的状态要能回写接收人点击“接收”后指令状态从“待接收”变成“已接收”这比推送本身更重要。4.3 二维码巡检打卡与异常上报二维码巡检打卡是演示时最抓眼球的模块。原本的思路是巡检员用手机扫贴在设备上的二维码但毕设场景不可能真的打印二维码我就在每个巡检点上生成一个不易重复的编号利用Hutool工具生成QR码图片前端页面根据设备ID实时渲染出来。扫码之后会把deviceCode回传到后端后端生成打卡记录。打卡接口要防止重复提交。巡检员可能在两分钟内重复扫同一个点第一次是正常打卡第二次就应该提示“您已完成该点位巡检”。这里我用了Redis的键来标记某次任务下某个巡检点是否已经打卡键的格式是inspect:record:{taskId}:{pointId}过期时间设为24小时。如果用户要求重新打卡需要巡检组长人工重置状态。PostMapping(/checkpoint) public Result checkPoint(RequestBody CheckPointRequest request) { String key inspect:record: request.getTaskId() : request.getPointId(); Boolean firstCheck redisTemplate.opsForValue().setIfAbsent(key, 1, Duration.ofHours(24)); if (firstCheck ! null firstCheck) { inspectRecordService.createRecord(request); return Result.success(打卡成功); } return Result.error(该点位已完成巡检如需重新打卡请联系组长重置); }巡检异常上报则要联动工单上报时会要求填写故障描述并选择影响等级。等级为“高”时系统自动创建维修工单并给调度台推送一条提示。4.4 Redis缓存与接口性能优化地铁项目的数据量虽不像电商那样夸张但设备状态查询和调度指令列表如果每次都查数据库页面响应依然会慢。我的优化策略分三级基础字典数据放进Redis永久缓存并设置主动刷新设备台账列表做本地缓存设置5分钟过期核心的实时数据如当前指令状态、当前在线人数不做缓存保持查询最新。列表查询一定要用MyBatis-Plus的分页插件并且避免在循环里查数据库。比如加载巡检任务列表时需要显示任务关联的路线名称和巡检人姓名我会先查出任务列表收集路线ID和用户ID再用in批量查询最后在内存里组装。这个优化能把接口响应时间从几百毫秒压到几十毫秒在演示时效果特别明显。5. 那些我一踩就是一下午的坑5.1 SpringBoot版本和依赖冲突SpringBoot 2.7.x本身没太大问题但引入其他组件时版本匹配就是一个坑。我一开始给项目加了Spring Cloud提供的某个工具包结果启动时直接报NoSuchBeanDefinition查了半天发现是依赖传递把Spring Boot版本从2.7拉到了2.4。后来我养成一个习惯所有第三方依赖都在pom.xml的properties里显式声明版本号不让它自己传递。Spring Boot的每个starter都有自己的版本管理一般不要手动改但第三方包必须要锁定版本。properties java.version1.8/java.version spring-boot.version2.7.13/spring-boot.version mybatis-plus.version3.5.3.1/mybatis-plus.version hutool.version5.8.22/hutool.version /properties5.2 MyBatis-Plus分页插件不生效很多人写好分页代码后发现返回数据仍然是一整页全量数据很多情况下是没有配置分页插件。MyBatis-Plus在SpringBoot里使用分页功能时必须注入一个PaginationInnerInterceptor否则Page对象起不到拦截SQL的作用。我最初漏掉了这一步排查了很久才意识到是配置问题。Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }这个配置类很小但忘了它就会浪费一下午。5.3 前端日期与Jackson序列化时区问题前后端分离的项目时间字段的坑特别经典。数据库里存的LocalDateTime在Jackson序列化后默认是带T的ISO字符串前端Element-UI的el-date-picker不认这种格式直接显示成NaN。后来我在配置类里统一格式化spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8但只配这个还不够LocalDateTime类型需要额外加Java Time模块的序列化支持SpringBoot自动装配一般会处理但如果自定义了ObjectMapper很容易失效。所以我干脆在字段上用JsonFormat(pattern yyyy-MM-dd HH:mm:ss, timezone GMT8)一劳永逸。5.4 设备状态查询的N1与慢SQL设备管理页面要显示每台设备的最近维修时间和状态一开始我是先查设备列表再循环查维修记录结果一次列表接口愣是查了十几秒。后来改成SQL联表查询用LEFT JOIN一次把最近维修时间带出来。但这样又引入了新问题LEFT JOIN后设备列表重复了因为一台设备可能有多条维修记录。解决方案是用子查询取每个设备最新的维修时间SELECT d.*, r.last_maintain_date FROM device_info d LEFT JOIN ( SELECT device_id, MAX(create_time) AS last_maintain_date FROM repair_order WHERE status 已完成 GROUP BY device_id ) r ON d.id r.device_id这类优化在面试时很加分因为它体现了对真实数据量和SQL性能的思考。6. 让项目在演示和答辩时不翻车的细节6.1 真实感演示数据的构造很多人的系统功能没问题但演示效果不好原因是数据太假。比如巡检记录里每条记录都是同一天的同一个时间调度指令里所有内容都是“测试”。为了让演示有说服力我写了一个数据初始化工具类一次生成一个月的数据并且保证数据在时间上是连续的。比如生成巡检任务时规定工作日和节假日的巡检路线略有不同这样看到任务列表的人会觉得“确实符合实际”。数据量别太大也别太小。设备台账六十条左右、巡检任务每个任务带十条打卡记录、调度指令近五十条这样页面既有翻页效果又不会因为数据过多而卡顿。数据生成后建议把SQL脚本保存下来随时可以重建一套干净数据。6.2 大屏数据接口的设计如果系统带一个数据可视化大屏答辩时非常加分。大屏页面通常是只读的我在后端单独写了几个聚合接口比如当日客运量趋势、线路运行正点率、设备故障率、巡检完成情况。聚合接口用Mapper里的自定义SQL一次查出统计数据不要在Java内存里遍历计算。一个大屏接口大概返回这样的JSON结构{ line: [{lineNo: 1号线, onTimeRate: 98.2}, ...], inspection: { total: 120, finished: 108, abnormal: 5 }, feedback: { total: 45, unsolved: 8 } }大屏页面每5秒轮询一次接口刷新时注意给loading状态避免因为接口慢导致图表闪动。6.3 高频问题与应答思路答辩时老师大概率会问三类问题为什么选这个架构、某张表为什么这么设计、系统能扛住多大的并发。最后一个问题一定不要吹“高性能”地铁项目的真实场景并发量并不恐怖重点是数据准确和流程闭环。可以回答系统核心不在高并发而在调度指令和设备状态的一致性Redis缓存用于缓解热点查询数据库层面做了必要索引足够支撑单条线路级别的日常运维。还有一个高频问题是“你的系统和已有的人工管理流程相比最大的改进是什么”。建议回答“把调度、巡检、乘客反馈的数据孤岛打通了工单能自动联动异常事件能被追踪形成了闭环。”这句话比列十个功能点都有说服力。最后再分享一个实际操作心得这类管理系统项目代码量其实并不重要重要的是“把业务讲圆”。我在做的时候每完成一个模块都会自己扮演调度员、巡检员、乘客三个角色把整个流程走一遍。很多逻辑漏洞就是这么试出来的。比如有一次我发现巡检任务在国庆节那天没有自动生成就是因为没配置节假日规则。像这种小细节往往才是真正让项目脱胎换骨的地方。
