把一套前后端分离的校车调度管理系统从零跑到线上看标题感觉模块就那么几个——线路、班次、车辆、司机——真开工后才发现难点全在“调”和“度”这两个字上同一辆车能不能同时排两条线临时换车怎么让乘客第一时间知道Nginx配不好前端一刷新就404这套基于SpringBootVueMyBatisMySQL的模拟项目X是我按真实需求梳理出来的完整落地版本适合正在做毕业设计、想拿管理类项目练手、或者准备独立把一套前后端分离系统部署上线的同学参考。这篇不堆概念直接把业务边界、建表思路、核心接口、部署命令和实测排坑一条龙讲清楚。1. 校车调度的业务真相为什么一张排班表远远不够1.1 校车场景里的常见突发状况模拟项目X的第一版需求用户方只提了三个字“排个班”。但实际走访下来校车调度根本不是静态排班而是一套动态协调问题。早期高峰几条线路同时发车站点排队晚自习下课所有班次扎堆返程临时调课导致某条线晚上多出一批学生司机临时请假班次空窗没人顶车辆中途抛锚可能还要临时换车。任何一个环节出错受影响的就是几十上百人。这些场景意味着两件事第一系统必须有清晰的班次计划和车辆/司机绑定关系第二系统必须支持“发车前变更”的操作并且把变更结果传递给司机端和乘客端而不是改完就完。1.2 功能边界与角色定义在梳理需求时模拟项目X共划分了四类角色学生/教职工是乘客使用端是查询班次、发起乘车申请驾驶员查看当日排班、签收调度变更调度员是核心角色负责排班、调度调整、冲突处理管理员管线路、站点、车辆、司机的基础信息维护。功能模块我拆成了六块用户与权限、线路与站点管理、班次计划、车辆与司机档案、调度变更与日志、乘车申请与统计报表。这个拆分不是随手分的而是按“基础数据、计划数据、过程数据”三层来划的后面建表时这个分层会直接映射到表结构上。1.3 非功能需求同样需要写在前面除了业务功能这类系统对部署和稳定性有明确要求并发量不大校园场景峰值也就几十到几百请求但要求服务可靠、重启快、备份简单。数据层面班次日期一定涉及时区问题时段字段需要支持“按周几循环排班”低峰期发车密度小需要支持批量复制工作日班次。这些细节后面都会影响表设计。2. 技术栈选型的取舍这套组合为什么会成为主流配置2.1 后端选SpringBoot的现实理由先说后端。SpringBoot不是性能最强、代码最少的技术但在“快速落地、好招人、出问题有大量案例”这个维度上它是最稳妥的选择。尤其对于毕设或中小型团队生态成熟度比炫技重要得多。模拟项目X里后端只做了一件事把数据模型暴露成RESTful接口替前端把权限、校验、事务、日志处理干净。SpringBoot的Starter机制让这些能力都在起步阶段各就各位不需要额外拼装。要说真正省时间的是项目结构。Controller只管接收参数和返回统一结构Service负责业务规则Mapper负责SQL三层一拆后面加功能、加接口都是复制粘贴的节奏。而Spring 的声明式事务在调度变更这类“先校验再写入”的操作里尤其方便加一个Transactional注解就避免了中间步骤出错导致的数据不完整。2.2 Vue生态为什么比模板引擎更适合这类系统前端选Vue关键是看中了组件化和生态。校园系统在移动端的访问量不小。司机看排班用的是手机浏览器学生查询班次大概率也是手机端。如果用后端模板引擎前后端强行耦合在一个工程里移动端适配和接口复用都会很别扭。而Vue脚手架起的单页应用天然就是后端提供API、前端只管渲染接口对Web、对移动端完全一致改一套接口三端复用。组件库层面模拟项目X选了Element UIVue 2.7版本表格、表单、日期选择器、弹窗这些管理后台高频组件都有现成的省掉大量手写样式的时间。统计页面的图表用的是ECharts它拿后端返回的简单JSON就能画出线路热度、班次状态分布、乘车申请趋势可视化需求全覆盖。2.3 MyBatis在组合查询场景里的存在感MyBatis常被拿来和JPA比。JPA在单表增删改查上确实方便但这类调度系统里最频繁的查询差不多都是多条件组合查某条线路状态为“运行中”且发车时间在某个区间内的班次查某个司机最近7天已经分配了多少个班次查一辆车在某时段是否已经被占用。这类查询SQL一写就明白难点在条件动态拼接。MyBatis的 、 标签让动态SQL在XML里清晰可控多表联查也完全在能力范围内。而且Hibernate和教材里的“纯ORM”概念在国产团队中接受度一般MyBatis直白、透明、可控出问题排查也快。模拟项目X选择它的原因就一句话数据库优化是在SQL层面可控的情况下才谈得上。补充一点很多同学用MyBatis时有个误区——生成器一键生成代码后就只增不改。实际上生成器只是建立基础CRUD真正复杂查询一定要自己写XML把索引、字段别名、JOIN条件控制在手里这是MyBatis的价值所在。2.4 前后端分离的代价与收益最后说说为什么坚持前后端分离而不是直接上JSP或Thymeleaf。收益是并行开发、动静分离、接口复用。但代价也有涉及跨域、两套部署链路、以及PWA或单页路由刷新404这类后端模板时代不会遇到的问题。这笔账要算清楚——如果项目只有三五个页面、几乎没有移动端需求模板引擎反而更省事一旦功能模块超过八个需要多人并行开发前后端分离就是正确选择。模拟项目X最终采用这套方案后整个开发周期的效率提升非常明显我把它推荐给所有类似规模的管理类系统项目。3. 数据库设计把调度逻辑翻译成表结构3.1 核心表清单与职责划分数据库设计是整个项目的骨架表结构一旦定偏后面所有功能都要跟着返工。模拟项目X最终保留了八张核心表表名职责核心字段摘要sys_user用户与登录信息id, username, password, role_type, real_namebus_line线路基础信息id, line_no, name, start_station, end_stationbus_station站点信息id, line_id, station_name, sort_orderbus_vehicle车辆档案id, plate_no, capacity, statusbus_driver司机档案id, driver_name, phone, license_no, statusbus_schedule班次计划核心id, line_id, vehicle_id, driver_id, depart_time, ride_date, statusbus_schedule_log调度变更日志id, schedule_id, operator_id, before_json, after_json, operate_typebus_reservation乘车申请/座位预约id, schedule_id, user_id, apply_status其中bus_schedule是全场核心几乎所有页面都在围绕它查询、写入和变更。bus_schedule_log则是容易被新手漏掉的表但它承担了“追溯”这个极关键的职责调度员改了什么、为什么改、谁改的全都记录在案出了问题能查、能对账。3.2 班次表的字段设计与索引规划班次表要注意的字段细节不少。日期和发车时间我分开存ride_date只存日期depart_time只存时间不要拼成一个datetime。原因是校车班次存在循环排班场景——同一趟线每天同一时间发车如果拼成datetime每次生成都要去算日期偏移而分开存配合“周几规则”可以很优雅地批量生成。模拟项目X的班次表核心SQL示例如下CREATE TABLE bus_schedule ( id BIGINT PRIMARY KEY AUTO_INCREMENT, line_id BIGINT NOT NULL COMMENT 线路ID, vehicle_id BIGINT COMMENT 车辆ID, driver_id BIGINT COMMENT 司机ID, ride_date DATE NOT NULL COMMENT 发车日期, depart_time TIME NOT NULL COMMENT 发车时间, status TINYINT NOT NULL DEFAULT 0 COMMENT 0未发车,1运行中,2已完成,3停运,4异常, total_seats INT NOT NULL COMMENT 核定座位数, booked_seats INT NOT NULL DEFAULT 0 COMMENT 已预约座位数, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_line_ride (line_id, ride_date), KEY idx_status_time (status, ride_date, depart_time), KEY idx_driver_time (driver_id, ride_date, depart_time), KEY idx_vehicle_time (vehicle_id, ride_date, depart_time) ) COMMENT 班次计划表;索引设计要配合实际查询习惯。调度员最常用的查询是“某线路某天所有班次”所以idx_line_ride必须建未来功能会支持“按状态和时间筛选”idx_status_time是高频组合idx_driver_time和idx_vehicle_time用于冲突检测司机或车辆在同一个时间段只能绑定一个班次这两条索引在后面检查冲突时就是SQL的判断利器。时间字段和当前时间比较时建议用 NOW()不要用 MySQL 的 CURRENT_TIMESTAMP 隐式转换踩坑这个后面会展开讲。3.3 调度变更日志与乘车申请的设计思路bus_schedule_log 的设计思路来源于“事件的不可变追溯”理念。调度员不可能永远不犯错系统要的不是阻止犯错而是给每一个变更留下记录。表的字段里我存了before_json和after_json把修改前后的整条班次信息各自序列化存储。这个设计的妙处在于哪怕以后班次表改了结构日志依然保留了一份当时的数据快照。查问题时直接解析JSON就能对比“改了什么”不需要JOIN多张表。bus_reservation则记录学生/教职工的乘车申请apply_status有已申请、已确认、已取消。这里埋了一个关键逻辑申请通过后要回写bus_schedule的booked_seats。回写时一定要在同一个事务里更新同时校验booked_seats不能超过total_seats这其实就是后面要说的高并发冲突问题在数据层面的第一道防线。4. 核心接口与前端实现从登录到发车调整4.1 JWT登录、鉴权拦截与动态菜单登录模块是所有管理系统的入口。模拟项目X用的方案是拦截器JWT没有引入完整的Spring Security框架原因是角色数量少权限模型简单Security反而增加学习成本。用户输入账号密码后后端校验用户表通过则签发一个JWT里边带上userId和roleType。此后前端所有请求都在Header里带上Authorization: Bearer token。后端拦截器统一解析拿不到有效token直接返回401。这里有个非常重要的小细节拦截器必须放行OPTIONS预检请求。前后端分离部署在不同的域名或端口时浏览器跨域请求先发OPTIONS如果你在拦截器里把OPTIONS也拦了前端会一直报CORS错误后面第6章我会专门讲这个坑。前端的动态菜单实现依据是角色类型。学生端只显示班次查询和申请司机端只显示我的排班调度员才有排班管理、调度调整菜单。实现时登录接口返回roleType前端路由守卫在跳转前做角色判断渲染时用v-if控制菜单项。4.2 排班管理的前后端交互流程排班管理页面是调度员使用频率最高的界面。页面上方是筛选区线路、日期、状态下方是表格。排班操作分成三步第一步选择线路和日期系统会根据“循环规则”批量生成基础班次第二步表格中选出班次点击“编辑”去绑定车辆和司机第三步点击“发布”该日期的班次变为对乘客可见。后端核心接口设计如下PostMapping(/api/schedule/create) public Result createBatch(RequestBody ScheduleBatchDTO dto) { // 1. 校验线路存在且启用 // 2. 根据 rule_type 生成多天班次 // 3. 循环中执行 vehicle/driver 冲突校验 // 4. 批量插入 bus_schedule }前端用一个对话框承载创建表单日期区间、线路、发车时段、循环规则全部在一个表单里提交。批量创建里的冲突校验是重点如果3天里某辆车被重复排到同一时段哪怕INSERT成功后续上线后调度员也会被乘客投诉。所以Service层一定要加车辆和司机的占用校验。4.3 调度调整与司机端、乘客端感知调度调整是系统的“动态能力”所在。已发布的班次如果因车辆故障或老师临时换课需要换车、换司机、调整发车时间调度员在表格里直接点击“调整”修改后提交。接口定义如下PutMapping(/api/schedule/adjust/{id}) public Result adjustSchedule(PathVariable Long id, RequestBody ScheduleAdjustDTO dto) { // 1. 校验班次状态必须为“未发车” // 2. 重新校验车辆/司机冲突 // 3. 写入 bus_schedule_log 变更日志 // 4. 更新 bus_schedule // 5. 给司机/乘客端发送变更通知 }司机端如何感知变更在校园规模下我选择了最轻量的方式消息表轮询。变更通知写入一张notice表司机端每次进入“我的排班”页面时拉取一遍有变更则弹横幅提示。要不要上WebSocket我认为在宿主环境不可控的前提下轮询足够而且无状态、易部署没有连接管理的麻烦。4.4 统计仪表盘的数据实现仪表盘是管理员的“驾驶舱”。页面放了三个核心图表班次状态分布饼图按未发车、运行中、已完成、异常统计当日总量线路热度排行柱状图统计近七天每条线路的乘车预约人数乘车申请趋势折线图展示近三十天每日申请量。后端不需要额外造轮子三个分组查询SQL就能完成。比如线路热度排行SELECT l.line_no, COUNT(r.id) AS apply_count FROM bus_reservation r JOIN bus_schedule s ON r.schedule_id s.id JOIN bus_line l ON s.line_id l.id WHERE r.create_time DATE_SUB(NOW(), INTERVAL 7 DAY) GROUP BY l.id ORDER BY apply_count DESC;前端拿到数组后直接传给ECharts数据格式保持简单页面的表现力就交给组件库处理。5. 部署落地从源码到线上服务的完整命令链路5.1 本地环境与三份配置文件部署教程是很多人拿到源码后卡住的第一步。模拟项目X的部署我建议在Linux服务器上操作这里把完整命令链路整理出来照着走基本一遍过。本地环境要求JDK 1.8或以上、Node 14或以上、Maven 3.6、MySQL 5.7或8.0。后端资源目录里有三份配置文件application-dev.yml本地开发库、application-prod.yml生产库和端口、application-test.yml测试环境。环境切换靠打包参数指定。生产配置核心就两处数据库连接和端口server: port: 8080 spring: datasource: url: jdbc:mysql://127.0.0.1:3306/bus_schedule?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: bus_user password: 你的数据库密码重点强调serverTimezoneAsia/Shanghai一定不能漏。漏掉的后果是Java程序读到的时间比MySQL里存的时间晚8小时国内很多系统上线后时间对不上的根因就在这一行参数上。5.2 后端打包与systemd守护进程在项目根目录执行mvn clean package -Dmaven.test.skiptrue打包产物在target/目录下是一个可执行的jar包通常几十兆。把它上传到服务器mkdir -p /opt/bus-schedule/backend scp target/bus-schedule-1.0.0.jar root服务器IP:/opt/bus-schedule/backend/之后使用systemd让jar包以服务方式常驻运行创建/etc/systemd/system/bus-schedule.service[Unit] DescriptionBus Schedule Backend Service Afternetwork.target mysql.service [Service] ExecStart/usr/bin/java -Xms512m -Xmx512m -jar /opt/bus-schedule/backend/bus-schedule-1.0.0.jar Restarton-failure RestartSec10 [Install] WantedBymulti-user.target然后执行systemctl daemon-reload systemctl enable bus-schedule systemctl start bus-schedule用systemd而不是裸跑nohup java -jar的好处是进程挂了自动拉起、开机自启、日志统一交给journald管理。哪天系统崩溃重启了后端服务也会自己起来不用人工干预。5.3 前端构建、Nginx路由与反向代理前端部署前注意vue.config.js里的publicPath。如果你的系统是挂在域名根路径下设置为/如果挂在子路径下设置为子路径如/bus/否则静态资源全是404。执行构建npm install npm run build生成目录是dist/把dist传到服务器:scp -r dist root服务器IP:/opt/bus-schedule/frontend/接下来写Nginx配置。这里要同时干两件事托管静态文件、反向代理API请求。典型配置如下server { listen 80; server_name 你的域名或IP; root /opt/bus-schedule/frontend/dist; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }try_files $uri $uri/ /index.html这一行是单页应用刷新不404的关键。没有它前端路由切到/schedule-list后一刷新Nginx会去找这个物理路径找到不就直接返回404。加了这条规则刷新时自动回退到index.html由前端路由接管页面。重新加载配置nginx -t nginx -s reload5.4 数据库初始化与日常备份数据库初始化在部署时手动执行一次。先把SQL文件传到服务器mysql -u root -p init.sql为了避免应用使用root账号连接建议创建专用账号CREATE USER bus_userlocalhost IDENTIFIED BY 一个强密码; GRANT ALL PRIVILEGES ON bus_schedule.* TO bus_userlocalhost; FLUSH PRIVILEGES;日常备份是最容易被忽略但必须做的事情。我习惯用crontab凌晨跑一次mysqldump0 2 * * * mysqldump -u root -p密码 bus_schedule | gzip /backup/bus_schedule_$(date \%Y\%m\%d).sql.gz恢复备份的命令gunzip /backup/bus_schedule_20250101.sql.gz | mysql -u root -p bus_schedule6. 实测中最常见的五个坑及完整排查链路6.1 刷新页面就404Nginx路由背后的问题现象是页面内点击跳转一切正常但只要在二级路由页面按F5页面就白屏控制台显示“Cannot GET /schedule-manage”。排查链路先在浏览器Network里看刷新请求的响应状态确认是404接着去服务器看Nginx错误日志tail -f /var/log/nginx/error.log发现Nginx在尝试找物理路径/opt/bus-schedule/frontend/dist/schedule-manage。根因明确了Vue Router用了history模式刷新时浏览器向服务器请求了虚拟路径而Nginx没有回退规则。解决方案就是刚才部署配置里写的try_files $uri $uri/ /index.html。这个坑凡是用history模式跑单页应用几乎绕不开。6.2 能登录但后续请求全部401或CORS报错现象登录接口返回token正常但之后的请求要么干脆不出去要么明明在Header里带了token后端仍然返回401。排查过程打开浏览器Network找到第一个失败请求发现类型是OPTIONS。根因有两层第一前后端跨域浏览器先发送预检请求第二后端拦截器处理了OPTIONS但没放行或者后端根本没有开启CORS配置。逐层排除后在后端拦截器里加一条if (OPTIONS.equalsIgnoreCase(request.getMethod())) { response.setStatus(HttpServletResponse.SC_OK); return true; // 放行预检请求 }同时在后端统一配置跨域支持允许前端域名提交Authorization头问题即刻消失。这个坑代码层面很小但顺序错一步光看前端报错能折腾一下午。6.3 数据库时间差八小时MySQL连接参数引发的时区问题现象前端时间选择器选的是早上8点保存后再看数据库里存的是凌晨0点差了整整8小时。排查链路先去MySQL里执行SELECT NOW()发现服务器时间正常再查JDBC连接日志发现Java应用拿到的ResultSet时间就是偏移后的。根因是MySQL连接串没带serverTimezoneAsia/Shanghai而MySQL驱动默认按服务器时区解析。补齐参数、重启服务时间恢复正常。6.4 并发冲突检测失败同一辆车被两条线同时排中这个问题只在多人同时操作时出现。两个调度员一人开一个浏览器窗口同一天、同一时间段把同一辆车排给了两条不同线路数据库里出现了两条记录。排查链路起初以为Service层的校验逻辑写的没问题因为单独操作时不会复现。后来开两个事务同时模拟提交发现MyBatis的查询校验语句里用的是普通SELECT两个事务在同一时刻都能读到“车辆空闲”于是都执行了INSERT。根因是典型的并发读一致性问题。解决方案是在事务入口对请求做串行化处理或者直接用数据库条件更新代替“先查后插”UPDATE bus_schedule SET vehicle_id ? WHERE id ? AND vehicle_id IS NULL把冲突检测下沉到SQL条件里让数据库的行锁和唯一约束来兜底这是最可靠的方式。6.5 Java进程突然消失或被端口占用现象服务器重启后后端服务没了或者有一天启动jar包提示Port 8080 was already in use。排查链路systemctl status bus-schedule看服务是否activejournalctl -u bus-schedule | tail -50看退出原因如果提示内存不足用free -m确认服务器内存然后调整systemd配置里的JVM参数比如-Xms512m -Xmx512m如果是端口占用ss -lntp | grep 8080找出占用进程区分是旧jar还是其他服务kill掉旧的再启动。我个人的体会是这类坑多半发生在部署阶段手忙脚乱的时候最好的办法是部署文档里把每条命令、每个端口、每个目录都固定下来形成一套自己的标准操作流程。每次上线照着走慢慢就不会再踩了。这套模拟项目X跑完一遍回看整个链路最值钱的部分不是代码量而是那些在数据模型和部署细节里被验证过的判断。如果你也想自己动手做一遍同类系统我的建议很直接先花时间把表结构和冲突规则想透再动手写代码部署相关的配置不要等开发完才碰中期就按生产环境跑一次。调度系统真正的复杂度永远不在增删改查而在变化发生时的协调与记录抓住了这一点整个系统的骨架就不会歪。
把一套前后端分离的校车调度管理系统从零跑到线上看标题感觉模块就那么几个——线路、班次、车辆、司机——真开工后才发现难点全在“调”和“度”这两个字上同一辆车能不能同时排两条线临时换车怎么让乘客第一时间知道Nginx配不好前端一刷新就404这套基于SpringBootVueMyBatisMySQL的模拟项目X是我按真实需求梳理出来的完整落地版本适合正在做毕业设计、想拿管理类项目练手、或者准备独立把一套前后端分离系统部署上线的同学参考。这篇不堆概念直接把业务边界、建表思路、核心接口、部署命令和实测排坑一条龙讲清楚。1. 校车调度的业务真相为什么一张排班表远远不够1.1 校车场景里的常见突发状况模拟项目X的第一版需求用户方只提了三个字“排个班”。但实际走访下来校车调度根本不是静态排班而是一套动态协调问题。早期高峰几条线路同时发车站点排队晚自习下课所有班次扎堆返程临时调课导致某条线晚上多出一批学生司机临时请假班次空窗没人顶车辆中途抛锚可能还要临时换车。任何一个环节出错受影响的就是几十上百人。这些场景意味着两件事第一系统必须有清晰的班次计划和车辆/司机绑定关系第二系统必须支持“发车前变更”的操作并且把变更结果传递给司机端和乘客端而不是改完就完。1.2 功能边界与角色定义在梳理需求时模拟项目X共划分了四类角色学生/教职工是乘客使用端是查询班次、发起乘车申请驾驶员查看当日排班、签收调度变更调度员是核心角色负责排班、调度调整、冲突处理管理员管线路、站点、车辆、司机的基础信息维护。功能模块我拆成了六块用户与权限、线路与站点管理、班次计划、车辆与司机档案、调度变更与日志、乘车申请与统计报表。这个拆分不是随手分的而是按“基础数据、计划数据、过程数据”三层来划的后面建表时这个分层会直接映射到表结构上。1.3 非功能需求同样需要写在前面除了业务功能这类系统对部署和稳定性有明确要求并发量不大校园场景峰值也就几十到几百请求但要求服务可靠、重启快、备份简单。数据层面班次日期一定涉及时区问题时段字段需要支持“按周几循环排班”低峰期发车密度小需要支持批量复制工作日班次。这些细节后面都会影响表设计。2. 技术栈选型的取舍这套组合为什么会成为主流配置2.1 后端选SpringBoot的现实理由先说后端。SpringBoot不是性能最强、代码最少的技术但在“快速落地、好招人、出问题有大量案例”这个维度上它是最稳妥的选择。尤其对于毕设或中小型团队生态成熟度比炫技重要得多。模拟项目X里后端只做了一件事把数据模型暴露成RESTful接口替前端把权限、校验、事务、日志处理干净。SpringBoot的Starter机制让这些能力都在起步阶段各就各位不需要额外拼装。要说真正省时间的是项目结构。Controller只管接收参数和返回统一结构Service负责业务规则Mapper负责SQL三层一拆后面加功能、加接口都是复制粘贴的节奏。而Spring 的声明式事务在调度变更这类“先校验再写入”的操作里尤其方便加一个Transactional注解就避免了中间步骤出错导致的数据不完整。2.2 Vue生态为什么比模板引擎更适合这类系统前端选Vue关键是看中了组件化和生态。校园系统在移动端的访问量不小。司机看排班用的是手机浏览器学生查询班次大概率也是手机端。如果用后端模板引擎前后端强行耦合在一个工程里移动端适配和接口复用都会很别扭。而Vue脚手架起的单页应用天然就是后端提供API、前端只管渲染接口对Web、对移动端完全一致改一套接口三端复用。组件库层面模拟项目X选了Element UIVue 2.7版本表格、表单、日期选择器、弹窗这些管理后台高频组件都有现成的省掉大量手写样式的时间。统计页面的图表用的是ECharts它拿后端返回的简单JSON就能画出线路热度、班次状态分布、乘车申请趋势可视化需求全覆盖。2.3 MyBatis在组合查询场景里的存在感MyBatis常被拿来和JPA比。JPA在单表增删改查上确实方便但这类调度系统里最频繁的查询差不多都是多条件组合查某条线路状态为“运行中”且发车时间在某个区间内的班次查某个司机最近7天已经分配了多少个班次查一辆车在某时段是否已经被占用。这类查询SQL一写就明白难点在条件动态拼接。MyBatis的 、 标签让动态SQL在XML里清晰可控多表联查也完全在能力范围内。而且Hibernate和教材里的“纯ORM”概念在国产团队中接受度一般MyBatis直白、透明、可控出问题排查也快。模拟项目X选择它的原因就一句话数据库优化是在SQL层面可控的情况下才谈得上。补充一点很多同学用MyBatis时有个误区——生成器一键生成代码后就只增不改。实际上生成器只是建立基础CRUD真正复杂查询一定要自己写XML把索引、字段别名、JOIN条件控制在手里这是MyBatis的价值所在。2.4 前后端分离的代价与收益最后说说为什么坚持前后端分离而不是直接上JSP或Thymeleaf。收益是并行开发、动静分离、接口复用。但代价也有涉及跨域、两套部署链路、以及PWA或单页路由刷新404这类后端模板时代不会遇到的问题。这笔账要算清楚——如果项目只有三五个页面、几乎没有移动端需求模板引擎反而更省事一旦功能模块超过八个需要多人并行开发前后端分离就是正确选择。模拟项目X最终采用这套方案后整个开发周期的效率提升非常明显我把它推荐给所有类似规模的管理类系统项目。3. 数据库设计把调度逻辑翻译成表结构3.1 核心表清单与职责划分数据库设计是整个项目的骨架表结构一旦定偏后面所有功能都要跟着返工。模拟项目X最终保留了八张核心表表名职责核心字段摘要sys_user用户与登录信息id, username, password, role_type, real_namebus_line线路基础信息id, line_no, name, start_station, end_stationbus_station站点信息id, line_id, station_name, sort_orderbus_vehicle车辆档案id, plate_no, capacity, statusbus_driver司机档案id, driver_name, phone, license_no, statusbus_schedule班次计划核心id, line_id, vehicle_id, driver_id, depart_time, ride_date, statusbus_schedule_log调度变更日志id, schedule_id, operator_id, before_json, after_json, operate_typebus_reservation乘车申请/座位预约id, schedule_id, user_id, apply_status其中bus_schedule是全场核心几乎所有页面都在围绕它查询、写入和变更。bus_schedule_log则是容易被新手漏掉的表但它承担了“追溯”这个极关键的职责调度员改了什么、为什么改、谁改的全都记录在案出了问题能查、能对账。3.2 班次表的字段设计与索引规划班次表要注意的字段细节不少。日期和发车时间我分开存ride_date只存日期depart_time只存时间不要拼成一个datetime。原因是校车班次存在循环排班场景——同一趟线每天同一时间发车如果拼成datetime每次生成都要去算日期偏移而分开存配合“周几规则”可以很优雅地批量生成。模拟项目X的班次表核心SQL示例如下CREATE TABLE bus_schedule ( id BIGINT PRIMARY KEY AUTO_INCREMENT, line_id BIGINT NOT NULL COMMENT 线路ID, vehicle_id BIGINT COMMENT 车辆ID, driver_id BIGINT COMMENT 司机ID, ride_date DATE NOT NULL COMMENT 发车日期, depart_time TIME NOT NULL COMMENT 发车时间, status TINYINT NOT NULL DEFAULT 0 COMMENT 0未发车,1运行中,2已完成,3停运,4异常, total_seats INT NOT NULL COMMENT 核定座位数, booked_seats INT NOT NULL DEFAULT 0 COMMENT 已预约座位数, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_line_ride (line_id, ride_date), KEY idx_status_time (status, ride_date, depart_time), KEY idx_driver_time (driver_id, ride_date, depart_time), KEY idx_vehicle_time (vehicle_id, ride_date, depart_time) ) COMMENT 班次计划表;索引设计要配合实际查询习惯。调度员最常用的查询是“某线路某天所有班次”所以idx_line_ride必须建未来功能会支持“按状态和时间筛选”idx_status_time是高频组合idx_driver_time和idx_vehicle_time用于冲突检测司机或车辆在同一个时间段只能绑定一个班次这两条索引在后面检查冲突时就是SQL的判断利器。时间字段和当前时间比较时建议用 NOW()不要用 MySQL 的 CURRENT_TIMESTAMP 隐式转换踩坑这个后面会展开讲。3.3 调度变更日志与乘车申请的设计思路bus_schedule_log 的设计思路来源于“事件的不可变追溯”理念。调度员不可能永远不犯错系统要的不是阻止犯错而是给每一个变更留下记录。表的字段里我存了before_json和after_json把修改前后的整条班次信息各自序列化存储。这个设计的妙处在于哪怕以后班次表改了结构日志依然保留了一份当时的数据快照。查问题时直接解析JSON就能对比“改了什么”不需要JOIN多张表。bus_reservation则记录学生/教职工的乘车申请apply_status有已申请、已确认、已取消。这里埋了一个关键逻辑申请通过后要回写bus_schedule的booked_seats。回写时一定要在同一个事务里更新同时校验booked_seats不能超过total_seats这其实就是后面要说的高并发冲突问题在数据层面的第一道防线。4. 核心接口与前端实现从登录到发车调整4.1 JWT登录、鉴权拦截与动态菜单登录模块是所有管理系统的入口。模拟项目X用的方案是拦截器JWT没有引入完整的Spring Security框架原因是角色数量少权限模型简单Security反而增加学习成本。用户输入账号密码后后端校验用户表通过则签发一个JWT里边带上userId和roleType。此后前端所有请求都在Header里带上Authorization: Bearer token。后端拦截器统一解析拿不到有效token直接返回401。这里有个非常重要的小细节拦截器必须放行OPTIONS预检请求。前后端分离部署在不同的域名或端口时浏览器跨域请求先发OPTIONS如果你在拦截器里把OPTIONS也拦了前端会一直报CORS错误后面第6章我会专门讲这个坑。前端的动态菜单实现依据是角色类型。学生端只显示班次查询和申请司机端只显示我的排班调度员才有排班管理、调度调整菜单。实现时登录接口返回roleType前端路由守卫在跳转前做角色判断渲染时用v-if控制菜单项。4.2 排班管理的前后端交互流程排班管理页面是调度员使用频率最高的界面。页面上方是筛选区线路、日期、状态下方是表格。排班操作分成三步第一步选择线路和日期系统会根据“循环规则”批量生成基础班次第二步表格中选出班次点击“编辑”去绑定车辆和司机第三步点击“发布”该日期的班次变为对乘客可见。后端核心接口设计如下PostMapping(/api/schedule/create) public Result createBatch(RequestBody ScheduleBatchDTO dto) { // 1. 校验线路存在且启用 // 2. 根据 rule_type 生成多天班次 // 3. 循环中执行 vehicle/driver 冲突校验 // 4. 批量插入 bus_schedule }前端用一个对话框承载创建表单日期区间、线路、发车时段、循环规则全部在一个表单里提交。批量创建里的冲突校验是重点如果3天里某辆车被重复排到同一时段哪怕INSERT成功后续上线后调度员也会被乘客投诉。所以Service层一定要加车辆和司机的占用校验。4.3 调度调整与司机端、乘客端感知调度调整是系统的“动态能力”所在。已发布的班次如果因车辆故障或老师临时换课需要换车、换司机、调整发车时间调度员在表格里直接点击“调整”修改后提交。接口定义如下PutMapping(/api/schedule/adjust/{id}) public Result adjustSchedule(PathVariable Long id, RequestBody ScheduleAdjustDTO dto) { // 1. 校验班次状态必须为“未发车” // 2. 重新校验车辆/司机冲突 // 3. 写入 bus_schedule_log 变更日志 // 4. 更新 bus_schedule // 5. 给司机/乘客端发送变更通知 }司机端如何感知变更在校园规模下我选择了最轻量的方式消息表轮询。变更通知写入一张notice表司机端每次进入“我的排班”页面时拉取一遍有变更则弹横幅提示。要不要上WebSocket我认为在宿主环境不可控的前提下轮询足够而且无状态、易部署没有连接管理的麻烦。4.4 统计仪表盘的数据实现仪表盘是管理员的“驾驶舱”。页面放了三个核心图表班次状态分布饼图按未发车、运行中、已完成、异常统计当日总量线路热度排行柱状图统计近七天每条线路的乘车预约人数乘车申请趋势折线图展示近三十天每日申请量。后端不需要额外造轮子三个分组查询SQL就能完成。比如线路热度排行SELECT l.line_no, COUNT(r.id) AS apply_count FROM bus_reservation r JOIN bus_schedule s ON r.schedule_id s.id JOIN bus_line l ON s.line_id l.id WHERE r.create_time DATE_SUB(NOW(), INTERVAL 7 DAY) GROUP BY l.id ORDER BY apply_count DESC;前端拿到数组后直接传给ECharts数据格式保持简单页面的表现力就交给组件库处理。5. 部署落地从源码到线上服务的完整命令链路5.1 本地环境与三份配置文件部署教程是很多人拿到源码后卡住的第一步。模拟项目X的部署我建议在Linux服务器上操作这里把完整命令链路整理出来照着走基本一遍过。本地环境要求JDK 1.8或以上、Node 14或以上、Maven 3.6、MySQL 5.7或8.0。后端资源目录里有三份配置文件application-dev.yml本地开发库、application-prod.yml生产库和端口、application-test.yml测试环境。环境切换靠打包参数指定。生产配置核心就两处数据库连接和端口server: port: 8080 spring: datasource: url: jdbc:mysql://127.0.0.1:3306/bus_schedule?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: bus_user password: 你的数据库密码重点强调serverTimezoneAsia/Shanghai一定不能漏。漏掉的后果是Java程序读到的时间比MySQL里存的时间晚8小时国内很多系统上线后时间对不上的根因就在这一行参数上。5.2 后端打包与systemd守护进程在项目根目录执行mvn clean package -Dmaven.test.skiptrue打包产物在target/目录下是一个可执行的jar包通常几十兆。把它上传到服务器mkdir -p /opt/bus-schedule/backend scp target/bus-schedule-1.0.0.jar root服务器IP:/opt/bus-schedule/backend/之后使用systemd让jar包以服务方式常驻运行创建/etc/systemd/system/bus-schedule.service[Unit] DescriptionBus Schedule Backend Service Afternetwork.target mysql.service [Service] ExecStart/usr/bin/java -Xms512m -Xmx512m -jar /opt/bus-schedule/backend/bus-schedule-1.0.0.jar Restarton-failure RestartSec10 [Install] WantedBymulti-user.target然后执行systemctl daemon-reload systemctl enable bus-schedule systemctl start bus-schedule用systemd而不是裸跑nohup java -jar的好处是进程挂了自动拉起、开机自启、日志统一交给journald管理。哪天系统崩溃重启了后端服务也会自己起来不用人工干预。5.3 前端构建、Nginx路由与反向代理前端部署前注意vue.config.js里的publicPath。如果你的系统是挂在域名根路径下设置为/如果挂在子路径下设置为子路径如/bus/否则静态资源全是404。执行构建npm install npm run build生成目录是dist/把dist传到服务器:scp -r dist root服务器IP:/opt/bus-schedule/frontend/接下来写Nginx配置。这里要同时干两件事托管静态文件、反向代理API请求。典型配置如下server { listen 80; server_name 你的域名或IP; root /opt/bus-schedule/frontend/dist; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }try_files $uri $uri/ /index.html这一行是单页应用刷新不404的关键。没有它前端路由切到/schedule-list后一刷新Nginx会去找这个物理路径找到不就直接返回404。加了这条规则刷新时自动回退到index.html由前端路由接管页面。重新加载配置nginx -t nginx -s reload5.4 数据库初始化与日常备份数据库初始化在部署时手动执行一次。先把SQL文件传到服务器mysql -u root -p init.sql为了避免应用使用root账号连接建议创建专用账号CREATE USER bus_userlocalhost IDENTIFIED BY 一个强密码; GRANT ALL PRIVILEGES ON bus_schedule.* TO bus_userlocalhost; FLUSH PRIVILEGES;日常备份是最容易被忽略但必须做的事情。我习惯用crontab凌晨跑一次mysqldump0 2 * * * mysqldump -u root -p密码 bus_schedule | gzip /backup/bus_schedule_$(date \%Y\%m\%d).sql.gz恢复备份的命令gunzip /backup/bus_schedule_20250101.sql.gz | mysql -u root -p bus_schedule6. 实测中最常见的五个坑及完整排查链路6.1 刷新页面就404Nginx路由背后的问题现象是页面内点击跳转一切正常但只要在二级路由页面按F5页面就白屏控制台显示“Cannot GET /schedule-manage”。排查链路先在浏览器Network里看刷新请求的响应状态确认是404接着去服务器看Nginx错误日志tail -f /var/log/nginx/error.log发现Nginx在尝试找物理路径/opt/bus-schedule/frontend/dist/schedule-manage。根因明确了Vue Router用了history模式刷新时浏览器向服务器请求了虚拟路径而Nginx没有回退规则。解决方案就是刚才部署配置里写的try_files $uri $uri/ /index.html。这个坑凡是用history模式跑单页应用几乎绕不开。6.2 能登录但后续请求全部401或CORS报错现象登录接口返回token正常但之后的请求要么干脆不出去要么明明在Header里带了token后端仍然返回401。排查过程打开浏览器Network找到第一个失败请求发现类型是OPTIONS。根因有两层第一前后端跨域浏览器先发送预检请求第二后端拦截器处理了OPTIONS但没放行或者后端根本没有开启CORS配置。逐层排除后在后端拦截器里加一条if (OPTIONS.equalsIgnoreCase(request.getMethod())) { response.setStatus(HttpServletResponse.SC_OK); return true; // 放行预检请求 }同时在后端统一配置跨域支持允许前端域名提交Authorization头问题即刻消失。这个坑代码层面很小但顺序错一步光看前端报错能折腾一下午。6.3 数据库时间差八小时MySQL连接参数引发的时区问题现象前端时间选择器选的是早上8点保存后再看数据库里存的是凌晨0点差了整整8小时。排查链路先去MySQL里执行SELECT NOW()发现服务器时间正常再查JDBC连接日志发现Java应用拿到的ResultSet时间就是偏移后的。根因是MySQL连接串没带serverTimezoneAsia/Shanghai而MySQL驱动默认按服务器时区解析。补齐参数、重启服务时间恢复正常。6.4 并发冲突检测失败同一辆车被两条线同时排中这个问题只在多人同时操作时出现。两个调度员一人开一个浏览器窗口同一天、同一时间段把同一辆车排给了两条不同线路数据库里出现了两条记录。排查链路起初以为Service层的校验逻辑写的没问题因为单独操作时不会复现。后来开两个事务同时模拟提交发现MyBatis的查询校验语句里用的是普通SELECT两个事务在同一时刻都能读到“车辆空闲”于是都执行了INSERT。根因是典型的并发读一致性问题。解决方案是在事务入口对请求做串行化处理或者直接用数据库条件更新代替“先查后插”UPDATE bus_schedule SET vehicle_id ? WHERE id ? AND vehicle_id IS NULL把冲突检测下沉到SQL条件里让数据库的行锁和唯一约束来兜底这是最可靠的方式。6.5 Java进程突然消失或被端口占用现象服务器重启后后端服务没了或者有一天启动jar包提示Port 8080 was already in use。排查链路systemctl status bus-schedule看服务是否activejournalctl -u bus-schedule | tail -50看退出原因如果提示内存不足用free -m确认服务器内存然后调整systemd配置里的JVM参数比如-Xms512m -Xmx512m如果是端口占用ss -lntp | grep 8080找出占用进程区分是旧jar还是其他服务kill掉旧的再启动。我个人的体会是这类坑多半发生在部署阶段手忙脚乱的时候最好的办法是部署文档里把每条命令、每个端口、每个目录都固定下来形成一套自己的标准操作流程。每次上线照着走慢慢就不会再踩了。这套模拟项目X跑完一遍回看整个链路最值钱的部分不是代码量而是那些在数据模型和部署细节里被验证过的判断。如果你也想自己动手做一遍同类系统我的建议很直接先花时间把表结构和冲突规则想透再动手写代码部署相关的配置不要等开发完才碰中期就按生产环境跑一次。调度系统真正的复杂度永远不在增删改查而在变化发生时的协调与记录抓住了这一点整个系统的骨架就不会歪。
