基于SpringBoot的交叉路口行人非机动车流量统计分析系统

打开毕设选题表看到“基于SpringBoot的大数据交叉路口行人非机动车流量调查统计分析系统”这种题目，第一反应往往是：这到底算大数据还是普通管理系统？该不会要把Hadoop全家桶都装上吧？我这两年带学生做毕设，这类题被选中的频率很高，不是因为多难，而是因为它踩中了几个关键点：有明确的业务场景、有可展示的统计图表、有SpringBoot这个主流框架、也有能写进论文的“大数据”叙事。这篇就按一个能落地的完整项目来讲透：从选题拆解、表结构设计、后端统计逻辑，到前端可视化、部署答辩，给你一条可以直接照着走的路线。

1. 选题价值与整体方案设计

1.1 这个毕设题到底在做什么

先别急着写代码，把业务背景搞清楚，这个题才做得下去。交叉路口流量调查是城市交通治理里非常基础的一项工作，交通管理部门需要知道某个路口一天24小时里，行人、自行车、电动车的通过量大概是什么水平，早高峰晚高峰分别出现在几点，哪个方向压力最大。这些数据直接影响信号灯配时、非机动车道设置、路口渠化改造和安全隐患评估。放在毕设里，就是把这个“调查+统计+分析”的过程做成一款Web系统。

系统要解决的核心问题不是“存储数据”，而是“把零散的路口流量数据变成能辅助决策的统计结论”。所以它至少要有三块能力：第一，数据能录进来，手工录入、Excel批量导入、模拟数据自动生成都可以；第二，数据能按路口、方向、时段、类型多维度聚合，算总量、算占比、算高峰系数；第三，结果能以折线图、柱状图、饼图等直观展示出来，让用户一眼看出结论。答辩老师问你“系统解决了什么问题”，你就按这个逻辑回答，不要只背技术名词。

从实现角度看，这个题本质上是典型的“管理信息系统+统计分析”，技术难度适中，但业务完整度高，非常适合作为Java方向的毕业设计。你要做的不是研究算法，而是把一套具备数据采集、入库、统计、可视化的闭环流程跑通，再写清楚设计思路。

1.2 为什么是SpringBoot而不是微服务全家桶

很多学生看到“大数据”三个字，第一反应就是上Hadoop、Spark、Kafka这一套，结果光搭集群就搭了一个月，最后连业务代码都没写几行。这种思路在毕设场景里是最大的坑。毕设考察的是你能否独立完成一个完整系统，重点在业务逻辑、工程规范、文档能力，而不是你有没有把三台虚拟机做成高可用集群。

SpringBoot的价值在于快速构建、内嵌Tomcat、自动配置、生态成熟。用SpringBoot可以让你把精力集中在统计逻辑和业务实现上，而不是反复折腾环境。如果是微服务架构，你需要拆分服务、引入注册中心、处理分布式事务，这些问题是真实企业里才有意义的，放在毕设里反而会暴露你对分布式理解的不足。当然，如果你的课题明确要求微服务，另当别论。

我的建议组合很固定：SpringBoot 2.7.x + MyBatis-Plus + MySQL 5.7/8.0 + Redis（可选）+ ECharts + Vue 2/3。为什么用SpringBoot 2.7而不用3.x？因为3.x要求JDK17，很多学校机器上还是JDK8，而且网上能搜到的资料绝大多数基于2.x，遇到问题你能找到答案。选型上“稳”比“新”重要，这句话对毕设永不过时。

1.3 数据规模与存储方案选型

“大数据”在毕设里到底意味着多大？真要说数据量，绝大部分本科毕设的数据量连数据库的“零头”都算不上。做一个合理的估算：一个路口有4个方向，每个方向每15分钟记录一次行人、非机动车、电动车的数量，那就是4×96×3=1152条/天。如果做10个路口，连续存一年，大概是1152×10×365，约420万条。这个量级在MySQL里单表加索引完全扛得住。即便你做的是秒级明细数据，10个路口一天也只是350万条左右，MySQL分表后依旧没问题。

所以这里要明确：题目里的“大数据”更多是指“多维度、多粒度、长期积累的业务数据”，它强调分析价值，而不是分布式存储。存储方案我推荐先用MySQL单库单表，再把统计结果冗余到汇总表。如果答辩时老师问“数据量暴增怎么办”，你可以从分表、索引优化、Redis缓存、定期归档这几个角度回答，这才是合理的演进路线，而不是直接甩一个Hadoop集群出来。分布式那一套可以作为加分项在论文“展望”里写，但不要作为主体方案。

2. 系统核心模块拆解与数据模型设计

2.1 流量调查的业务场景与指标体系

流量调查这件事看着简单，实际想清楚指标会花不少时间，但这一块恰恰是论文里最好写的需求分析素材。一个交叉路口的流量数据，至少要区分五个维度：路口、方向、交通方式、时间、天气。方向通常分为东、南、西、北四个进口道，也可以细化到左转、直行、右转。交通方式在这个题目里明确是行人和非机动车，其中非机动车最好再细分自行车和电动车，两种车的速度、占道习惯、事故风险完全不同。

基于这些维度，系统要能输出一组有分析价值的指标：总流量、分方向流量、分时段流量、各交通方式占比、高峰小时流量、高峰小时系数、日平均流量、周同比/环比。其中高峰小时系数是交通工程里的常用概念，表示一天中流量最高的那个小时占全天流量的比例。这个指标面试和答辩都容易出彩，因为它说明你不只是在写CRUD，而是理解业务含义。

我建议系统设计里单独做一个“统计指标说明”的页面或文档，把每个指标的口径写清楚。答辩老师经常问“你这个统计结果怎么来的”，如果你能准确说出“某路口西口8:00-9:00非机动车流量占全天17%，说明该时段通勤特征明显”，这个项目的说服力就完全不一样了。

2.2 数据库表结构设计要点

数据库是这个项目的地基，表设计不做好，后面所有统计SQL都会写得痛苦。核心表建议至少四张：路口信息表、流量明细表、流量日汇总表、用户表，另外可以加数据字典表、操作日志表作为加分项。

路口信息表字段建议这样设计：

流量明细表是整个系统的核心，字段要覆盖统计所需的所有维度：

这里有两个踩过的坑必须提醒。第一，方向字段不要用“东”“西”这种中文字符做存储值，一是排序和比较不方便，二是容易在写SQL时出错，建议用E/S/W/N编码，展示时再转换。第二，count_value虽然只是一个int字段，但它是所有统计的基础，一定要加非空约束，并配合业务校验，否则后期统计会出现莫名为零的数据。索引方面，流量明细表必须建联合索引(crossing_id, direction, traffic_type, record_time)，这是我在实际项目中对比出来的结果：没有这个索引，百万级数据按天分组查询可能要2秒以上，加上之后能压到100毫秒以内。

日汇总表用于展示和导出，结构上可以复用明细表的维度，增加day字段，把明细聚合后的结果存下来。这样查询首页大屏、日报趋势时，直接查汇总表，速度会非常快。

2.3 接口功能清单与模块划分

模块划分建议按照业务功能拆成6个部分：登录认证、路口管理、流量数据管理、统计分析、数据导入导出、系统管理。对应后端的Controller设计如下：

前端页面按这六个模块对应开发，包括登录页、首页总览大屏、流量统计页、路口管理页、数据导入页、用户管理页。我强烈建议你在前端做一个“首页总览”，用四个核心数字卡片展示今日总流量、今日高峰时段、非机动车占比、监控路口数量，下方再配一张24小时曲线图。这种“数字卡片+图表”的布局视觉效果最直观，答辩时不需要讲解，老师一看就知道系统是干什么的。

接口统一返回结构也要提前设计好，不要一个接口返回JSON对象、另一个返回字符串。建议定义一个Result类，包含code、message、data三个字段，所有接口统一走这个结构。前端Axios拦截器里通过code判断请求是否成功，出了问题也方便排查。这是工程规范的体现，论文里可以直接写进“系统设计”章节。

3. 后端关键实现与数据处理细节

3.1 SpringBoot工程结构与分层规范

后端工程结构建议采用标准的四层结构：Controller层、Service层、Mapper层、Entity层，再加上config、common、dto、utils等辅助包。我见过太多毕设把几百行业务逻辑直接写在Controller里，虽然能跑，但论文和答辩都很难讲出亮点。分层不只是规范，更是一种可维护性，答辩时被问到“如果要加一个接口怎么改”，你可以很清晰地解释。

工程包名建议用com.example.traffic，下面分包如下：

• controller：接收请求、参数校验、调用service返回Result
• service：业务逻辑，接口+实现类Impl，事务控制写在这里
• mapper：MyBatis-Plus的Mapper接口，复杂统计SQL写在XML或@Select注解里
• entity：数据库表对应的实体类
• dto：前端传入参数的封装对象，比如查询条件DTO
• vo：返回给前端的视图对象，比如统计结果VO
• config：跨域配置、WebMvc配置、异步配置等
• common：统一返回结果、业务异常类、常量类
• utils：日期工具类、Excel工具类等

application.yml里最核心的配置是数据源和端口。端口选择要注意后端不要占用8080，建议用8090，给前端Vue留8080。MySQL连接串里一定加上useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai，少一个都可能出现中文乱码或者时间差8小时的问题。这在毕设里是高频故障。

pom.xml关键依赖我提供一个基础清单：spring-boot-starter-web、mybatis-plus-boot-starter、mysql-connector-java、lombok、hutool-all（工具集）、easyexcel（Excel导入导出）。Redis依赖看你自己时间，如果赶进度可以暂时不引入，把Redis缓存作为扩展点写进论文里。注意Lombok虽然省代码，但如果你对注解不熟，答辩时被问“@Data干了什么”卡住了很尴尬，建议提前把Lombok原理看一遍。

3.2 数据采集入库的几种方式

流量数据怎么进系统，是最容易被忽略但最影响使用体验的模块。调查数据如果全靠手工录入，效率很低，也不像真实系统。所以至少要支持三种方式。

第一种是页面手工录入。表单字段包括路口、方向、交通方式、数量、时间、天气，提交后端做校验再入库。这种适合小批量、临时补充数据。

第二种是Excel批量导入。用EasyExcel实现，比原生POI好用得多，核心是写一个监听器，逐行读取并转换成实体对象。这里有一个注意点：Excel模板的表头要和后端字段映射对应，读出来的日期可能是数字格式，需要手动转换。建议先下载模板再填写，避免格式问题。

第三种是模拟数据生成器。这是很多学生不知道的“作弊神器”。做毕设演示的时候，你不可能真的去路口蹲一天数车，但系统里必须要有足够的数据才能展示图表。写一个定时任务，每天凌晨自动生成“看起来合理”的流量数据。生成规则可以按真实规律设计：早高峰7:00-9:00流量是平峰的1.8倍，晚高峰17:00-19:00是1.5倍，天气下雨时非机动车流量下降30%，行人流量变化不大。用Random加这几个系数，就能生成一组逻辑自洽的数据。

代码示例逻辑如下：

Random random = new Random(); int hour = currentTime.getHour(); double factor = 1.0; if (hour >= 7 && hour < 9) { factor = 1.8; // 早高峰 } else if (hour >= 17 && hour < 19) { factor = 1.5; // 晚高峰 } int base = 80 + random.nextInt(40); int count = (int)(base * factor);

这段代码虽然简单，但能保证生成的数据在趋势上有明显的高峰起伏，图表展示效果会很真实。论文里可以把生成规则写成“测试数据构造方案”，也算合理。

3.3 流量统计聚合与定时任务

统计是这个系统的灵魂，所有复杂逻辑都在这里。基础统计逻辑不复杂，就是按维度分组求和，但SQL写得好不好，性能差距很大。以“按天分时段统计某个路口各类流量”为例，SQL可以这样写：

SELECT DATE_FORMAT(record_time, '%Y-%m-%d') AS stat_date, direction, traffic_type, SUM(count_value) AS total FROM traffic_record WHERE crossing_id = #{crossingId} AND record_time BETWEEN #{startTime} AND #{endTime} GROUP BY stat_date, direction, traffic_type ORDER BY stat_date, direction;

如果只要查某一天的24小时曲线，就把DATE_FORMAT改成'%Y-%m-%d %H:00:00'，按小时聚合。MySQL8.0支持窗口函数，可以做同比环比分析，比如计算某个时段相比上周同期的变化率。如果数据库是5.7版本，就老老实实用子查询或者在后端用Java分组计算，效果一样。

定时任务要承担两件事：每日汇总和自动生成测试数据。在SpringBoot启动类上加上@EnableScheduling注解，然后在具体任务方法上使用@Scheduled(cron = "0 30 1 * * ?")表示每天凌晨1点30分执行一次。任务一，把前一天的流量明细聚合写入日汇总表；任务二，为没数据的路口生成新一天模拟数据。这样做的好处是，展示系统时打开首页永远有最新数据，不会出现“今天没记录”的尴尬。

统计聚合还有一个精细点：计算“高峰时段”。不要硬编码成7点到9点，而是要从数据里算出来。思路是查出一天中流量最大的那个小时，用最大小时流量除以全天流量得到高峰小时系数。在代码里可以遍历24小时的统计数据，找到最大值和对应小时，然后返回给前端展示。答辩时这一套逻辑能讲出很多内容，因为你不再只是“查表”，而是基于统计推断业务规律。

3.4 性能优化：索引、缓存与并发控制

虽然数据量不算特别大，但性能优化是论文里体现思考深度的好地方，建议从三个层面做。

第一个层面是索引。前面提到联合索引必须建，另外如果经常按时间范围查询，record_time单列索引也建议加上。用MyBatis-Plus查询时不要去查不必要的大字段，比如remark如果很长，列表查询就不要select *。代码里尽量使用LambdaQueryWrapper配合select指定字段，性能更好，代码也更优雅。

第二个层面是Redis缓存。统计接口是读多写少，非常适合缓存。以“按小时统计”为例，设置Redis的key为“stats:hour:20250620:1:E:S”，value为统计结果JSON，过期时间设置成30分钟。数据被导入或修改后，主动删除对应的缓存key，下次查询自动回源数据库重建缓存。这里要注意Redis的key不要设计得太散，否则不方便统一清理。如果时间紧张，可以只缓存首页总览数据，其他接口暂不处理，在论文里说明“已预留缓存扩展点”。

第三个层面是导入接口的并发控制。Excel导入经常会有几百上千条数据，如果单条insert循环插入，速度会非常慢。正确做法是使用MyBatis-Plus的saveBatch批量插入，并且在JDBC连接串中加入rewriteBatchedStatements=true参数，让MySQL真正执行批量写入。实测下来，1000条数据批量插入只需要几百毫秒，循环单条插入可能要十几秒。同时，导入接口要加事务控制，一旦中间有数据格式错误，整个批次回滚，避免出现明细表只有一半数据入库的情况。

4. 前端可视化与前后端联调

4.1 页面结构与技术选型

前端这块，毕设界最主流、资料最多的组合是Vue2 + Element UI + Axios + ECharts。如果你熟悉Vue3，也可以用Vue3 + Element Plus，但Vue2的项目模板和报错解决方案更丰富，对于赶时间的学生更友好。我不建议前端使用React，不是说React不好，而是后续如果遇到问题，你自己查资料的成本会更高。技术栈选“自己最容易找到答案的”，这同样适用于毕设。

页面结构建议采用经典的管理后台布局：左侧侧边栏菜单，右侧顶部栏加内容区域。路由包含登录页、首页总览、流量统计、路口管理、数据导入、系统设置。登录逻辑要做判断：未登录状态下访问其他页面，路由守卫直接跳转到登录页；登录成功后把token存到localStorage，同时存一个用户信息对象。这部分是常见面试题，也是答辩老师喜欢问的点。

前端工程规范的另一个关键是封装请求模块。创建一个request.js文件，创建Axios实例，设置baseURL为/api（后端网关或代理地址），请求拦截器里从localStorage取token并加到Authorization头部，响应拦截器里判断返回状态。这样所有接口都走统一的请求逻辑，不会出现写10个接口重复10次配置的丑陋代码。联调阶段你会感谢这个封装，因为只要改一个地方就能全局生效。

4.2 ECharts图表选型与数据对接

图表展示是这个系统最直观的加分项，ECharts足够应付。我建议至少做四个图表：24小时流量折线图、各方向流量柱状图、行人/非机动车占比饼图、近7天趋势曲线图。不需要堆太多花哨的图表，四个就能把数据说明白。

以24小时流量折线图为例，一个比较稳妥的做法是后端提供接口返回当天按小时聚合的数据，结构为：

{ "hours": ["00:00", "01:00", "02:00", "……"], "pedestrian": [12, 8, 6, 20, ...], "bicycle": [30, 25, 20, 18, ...], "e_bike": [45, 38, 30, 22, ...] }

前端拿到数据后，循环塞进ECharts的series数组，再调用chart.setOption更新。这里有一个非常经典的坑：ECharts在联动筛选时，必须调用myChart.setOption(option, true)，第二个参数传true是强制刷新，否则图表会残留旧数据。尤其是切换路口、切换日期后，旧曲线不清空，看起来就像数据重叠，实际不是代码写错了，而是没传true。这个小细节很多教程不会讲。

柱状图和饼图的数据来源可以是同一个统计接口的不同聚合维度。比如柱状图统计“各方向总流量”，饼图统计“各交通方式占比”，前端只需要按返回的data字段分别填充。答辩时不要只讲“我用了ECharts”，要讲清楚“每个图表背后的数据是怎么查出来的”，这才能体现你理解前后端数据流转。

4.3 跨域、鉴权与联调避坑

前后端分离后，必然遇到跨域问题。通常是Vue跑在8080，后端跑在8090，浏览器会拦截跨域请求。解决方式是在后端写一个跨域配置类，继承WebMvcConfigurer，重写addCorsMappings方法，允许本地开发地址访问，并开放所有HTTP方法。代码示例如下：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

注意allowedOriginPatterns这种方式比allowedOrigins("*")更安全，配合allowCredentials(true)时也不会报错。如果用Spring Security，还需要在Security的配置里放行OPTIONS预检请求，否则前端会一直提示跨域失败。这个坑我见过很多次，本质是Spring Security拦截了预检请求，要单独在securityConfig中对OPTIONS请求做permitAll。

鉴权方面，毕设一般用JWT。登录成功后端生成token，前端每次请求放到Authorization请求头。后端用一个拦截器或Filter校验token，如果token无效直接返回401。建议写一个简单的AuthInterceptor，实现HandlerInterceptor接口，在preHandle方法里校验token，然后通过ThreadLocal传递当前用户信息。不要为了显得高大上去引入Spring Security加OAuth2那一套，除非你有十足的把握能驾驭，否则引入复杂框架只会拖慢进度，还容易在答辩时被追问细节。

联调阶段最常见的三个问题是：参数名不一致、日期格式对不上、后端返回的null被前端当成0渲染。这些问题的排查思路是打开浏览器开发者工具，看Network面板的请求载荷和响应体，对比接口文档逐一核对。我建议从一开始就准备一份接口文档，哪怕是写在Markdown里，联调时效率能提升一倍。

5. 项目部署、文档写作与答辩准备

5.1 本地环境搭建与一键启动

本地开发环境建议如下：JDK 1.8（具体版本用8u202或8u191都行）、Maven 3.6.3、MySQL 5.7或8.0、Redis可选、Node.js 14/16、IDEA 2021以上、Vue CLI 4/5。版本不要追新，越新越容易踩环境坑。

数据库初始化建议把SQL脚本直接放在项目根目录的sql文件夹下，包含建库语句、建表语句和默认用户数据。第一次运行后端的标准流程是：在Navicat里执行sql脚本，打开application.yml确认数据库名、用户名、密码正确，然后启动SpringBoot主类，日志出现Tomcat started on port 8090就代表启动成功。前端流程是npm install安装依赖（如果很慢可以配置国内镜像源），npm run serve启动，浏览器访问localhost:8080。

启动失败的高频原因，第一是MySQL版本和驱动不匹配；第二是端口占用导致后端启动失败，用netstat -ano | findstr 8090查端口，找到占用进程关掉；第三是Redis没有启动，如果代码里配置了Redis连接，连接失败会直接抛异常。我的建议是最初版本先不接Redis，把所有功能跑通后再加缓存，这样排错范围会小很多。

5.2 部署到服务器与jar包运行

如果需要部署到云服务器，后端打jar包的方式是mvn clean package -DskipTests，在target目录会生成一个可执行jar。此时要注意application.yml中的MySQL地址要改成服务器的内网或公网地址，数据库连接参数独立配置。更好的做法是使用多Profile配置，把开发环境和生产环境分开，部署时用java -jar traffic-system.jar --spring.profiles.active=prod指定配置文件。

前端构建命令是npm run build，生成dist静态目录。部署方案最简单的是用Nginx托管dist目录，并把/api开头的请求反向代理到后端。我的Nginx配置片段如下：

server { listen 80; server_name your-domain-or-ip; root /usr/share/nginx/html; index index.html; location /api/ { proxy_pass http://127.0.0.1:8090; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location / { try_files $uri $uri/ /index.html; } }

注意前端打包后的路由不能直接刷新，否则会404，try_files那一行就是解决History模式路由的刷新问题。部署完如果发现后端日志没有输出，多半是jar包没有写日志文件，建议在启动命令里加nohup java -jar traffic-system.jar > app.log 2>&1 &，这样所有日志都会写进app.log，排查问题能少走很多弯路。

5.3 论文与说明文档的写作重点

这类题目写论文很有优势，因为“流量调查统计分析”天然自带需求分析和系统设计的完整素材。论文结构上最关键的不是系统实现，而是“需求分析”和“数据库设计”两章。需求分析要有数据流图或用例图，说明系统参与者有谁、各自做什么操作；数据库设计要有ER图、表结构说明和字段含义解释。这些图可以用PowerDesigner或Draw.io画，不用追求多精美，但一定要画清楚。

写“系统实现”这一章时，不要只贴代码或截图。我最常跟学生说的一句话是：论文里至少要有一段话解释“为什么要这么实现”。比如为什么选择Redis缓存统计结果，为什么流量明细表要按时间聚合日汇总表，这些“为什么”比“做了什么”更有学术分量，也更容易让评阅老师给出高分。

说明文档和LW交付物一般包含开题报告、任务书、中期检查表、毕业论文、答辩PPT、演示视频。如果你的项目目录里已经有完整的LW模板，记得把每个章节标题对应填写，不要出现模板里“请在此处填写XX内容”的字样。建议在开发过程中就同步截图，不要最后一天再从成品里补截图，那样很多过程性材料是补不出来的。

5.4 答辩时的高频问题与应对

答辩现场老师最爱问的不是代码细节，而是“设计决策”。我用过的应对思路可以给你参考。第一个高频问题“这个系统的大数据体现在哪”，你可以这么答：这个系统面向多路口多年份的流量数据建模，单表可支撑百万级数据量，通过索引优化、聚合汇总和缓存机制来保证统计性能，并且预留了分布式计算扩展接口。不说假大空，也不否认大数据的含义，重点在“数据治理和分析链路”。

第二个高频问题“为什么选择SpringBoot”，回答要点是：SpringBoot简化了Spring的配置过程，内嵌Tomcat方便独立部署，生态完善、社区活跃，适合快速构建业务系统；同时它支持与后续大数据组件集成，例如SpringBoot可以方便地对接Spark或Flink的JavaAPI。这个回答把当前工作和未来扩展串起来了。

第三个高频问题“统计结果怎么保证准确”，你可以从三个方面答：数据入库前做了格式校验和唯一性校验；统计SQL通过SQL脚本做了单元验证，拿手工计算样本对比过；日汇总表在每日凌晨统一重新生成，避免数据更新导致不一致。能说出来验证过程，老师基本就不会再追问了。

还有一个问题经常出其不意：“如果数据量变大，项目里什么模块会先崩？”这个问题没有标准答案，但你应该有逻辑。常规答法是：单表查询会变慢，所以要先做分表和索引优化；后端同步统计会阻塞线程，所以要把统计任务改为异步执行。提前想好这种问题，能展示你的系统设计能力，也能体现你对扩展性的思考。

6. 常见问题速查与扩展方向

6.1 常见问题速查表

我整理了开发这个系统过程中最容易遇到的故障，按“现象-原因-解决方案”列了个速查表，你调试时可以直接对照。

6.2 加分扩展方向

如果主体功能已经稳定，还有精力想冲高分的，我给你几条扩展思路，按性价比排序。第一，接入实时流数据模拟，通过Kafka往系统推送流量数据，再用一个WebSocket接口把实时流量推送给前端，做一个“实时流量监测”小模块，这能直接呼应“大数据实时计算”的方向。第二，在统计结果上加入一个简单的趋势预测，比如用线性回归基于历史7天数据预测明天的总流量，算法代码量不大，但答辩时足够新颖。第三，为路口信息表增加经纬度后，用高德地图或ECharts地图展示多个路口的流量热力分布，视觉冲击力很强。

不过要提醒一点：扩展功能要量力而行，不要在主体还没有完成时就去加实时模块。毕设评分的前提是系统完整可用，扩展是锦上添花。你先把登录、录数、图表、导出这段闭环跑顺，再考虑加料。

我个人在实际操作中的体会是，这类系统最怕的不是技术难，而是数据流没打通。数据从Excel到数据库，从数据库到统计接口，再从统计接口到ECharts，任意一环断了，整个项目看起来都是残缺的。所以建议你开发时按“一条完整链路”来走：先手工录入几条数据，再写统计接口，先不做图表，用Swagger或Postman验证返回结果，最后接前端。链路通了之后一切都会顺很多。还有一个小技巧是，开发阶段一定要保留一批“有故事”的测试数据，比如某路口工作日的早高峰明显高于周末，这段数据分析可以在答辩时拿来当案例讲，比空讲功能强太多。