基于SpringBoot的高校防诈骗宣传平台:从需求到部署的完整实战

发布时间:2026/10/14 13:12:45
基于SpringBoot的高校防诈骗宣传平台:从需求到部署的完整实战
做毕设这些年我见过不少同学选高校防诈骗宣传平台这类题目。题目看着不新但真能把它做扎实的人不多。大多数版本就是一套普通的增删改查——后台录几条案例、前台列个列表答辩时演示五分钟老师问一句你的平台和一份Excel表格有什么区别人就开始卡壳。这其实是好题目因为校园反诈宣传这件事本身有真实痛点。学校天天发防骗推文、组织班会但学生真正看进去的没几个。所以一个基于SpringBoot的高校防诈骗宣传平台核心价值不在于能做管理后台而在于它是把教育内容案例—知识检测测评—用户互动社区串起来的闭环产品。这篇文章我按自己的实际开发经验把这个项目的需求拆解、技术选型、数据库设计、核心实现、实测演示到部署上线完整梳理一遍。准备做类似题目的同学可以直接照着走。1. 立项前的需求打样反诈平台到底解决校园里的什么问题1.1 校园反诈宣传的真实困境高校反诈不是没宣传而是宣传形式和学生的接收习惯完全错位。我接触过的某高校曾经组织所有新生下载反诈App、签承诺书一个月后后台数据显示活跃率不到三成。班会课上辅导员念PPT里的诈骗案例学生坐在下面刷手机效果可以预见。这背后的原因主要有三个。第一宣传内容单向输出学生只是被通知的接收者没有参与感。第二案例内容大多是来自公安通报的官方文本语言严肃、篇幅长学生没有耐心看完。第三没有反馈闭环——学生到底有没有看懂、能不能识别骗局学校完全不知道。所以这个平台在设计需求时就不能只做案例列表详情页。核心设计逻辑应该是让学生愿意看、看完能检验、检验后能交流学校能通过数据知道宣传到底有没有效果。1.2 平台的功能闭环设计思路我把这个项目定义为一个内容驱动行为反馈的知识教育社区。从业务上分成三条线内容线管理员和宣传员录入防诈骗案例按冒充客服、刷单返利、注销校园贷、裸聊敲诈、钓鱼链接等分类设置危险等级维护案例库。学习线学生浏览案例、完成防骗知识测评、查看学习进度。测评不是简单对答案而是模拟真实诈骗场景让学生做判断。互动线学生在社区发帖提问、分享自己遇到的疑似诈骗经历其他同学可以评论和点赞形成同学之间的互助预警氛围。这样一套逻辑下来平台的定位就清楚了不是学校发通知的工具而是一个有内容沉淀、有学习行为、有社交属性的安全教育平台。这也是答辩时最有说服力的地方——你设计的不只是一个CRUD系统而是一套教育运营机制。1.3 目标用户与角色权限模型系统的用户角色要简洁不要搞五六种角色把自己绕晕。我最终采用的是三类角色学生、宣传员内容运营者、系统管理员。角色核心职责权限边界学生浏览案例、参与测评、社区互动只能查看已发布的案例和参与答题不能维护内容宣传员录入案例、编辑题目、管理社区帖子可以维护内容但不能管理用户和系统配置管理员用户管理、角色分配、数据统计、内容审核全权限三类角色的划分对应了平台的三块核心业务也方便在Spring Security里做权限配置。后面的RBAC权限模型、菜单动态渲染都是基于这个角色表来做的。2. 技术选型的取舍为什么SpringBoot是这个项目最稳妥的答案2.1 框架选型与理由用SpringBoot做这个题的毕业设计是目前最合理的选择。我从三个维度说明开发效率Spring Boot的starter机制省去了大量繁琐配置。内嵌Tomcat意味着不用单独部署WAR包一个jar包直接跑对没有服务器运维经验的毕业生非常友好。生态成熟Spring Boot搭配MyBatis-Plus做数据访问、搭配Spring Security做登录认证网上资料非常充足遇到问题基本都能搜到解决方案。答辩好讲老师通常熟悉Java技术栈你用的每个组件他都能接上话。相比用一些冷门框架Spring Boot背后的Spring生态本身就是你答辩时的知识筹码。2.2 核心依赖清单与关键说明我建的Spring Boot项目版本是2.7.xJava用的是1.8很多学校机房老电脑上装的是JDK8用高版本容易没人给你改环境。Maven核心依赖如下parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version /parent dependencies !-- Web层 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency !-- 安全认证 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-security/artifactId /dependency !-- ORM持久层 -- dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency !-- 工具类 -- dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency dependency groupIdcom.github.xiaoymin/groupId artifactIdknife4j-spring-boot-starter/artifactId version2.0.9/version /dependency /dependencies这里有个细节值得说knife4j是接口文档工具就是升级版的Swagger。我在开发阶段靠它调试接口省了很多事。但注意如果机器内存不够启动会比较慢建议在application.yml里根据自己情况决定是否开启。2.3 分层架构与包结构规划项目包结构直接影响代码可读性和答辩观感我给出一套规范的结构com.school.antifraud ├── controller # 接口层接收请求、参数校验 ├── service # 业务层核心逻辑处理 │ ├── impl ├── mapper # 数据访问层MyBatis-Plus的Mapper接口 ├── entity # 数据库实体类 ├── dto # 前端交互的数据传输对象 ├── vo # 返回给前端的视图对象 ├── config # 配置类安全配置、跨域、MyBatisPlus分页 ├── common # 通用返回结果、异常处理、常量 └── utils # 工具类Controller只做参数接收和结果包装Service层处理业务逻辑Mapper层只做数据操作。我见过不少同学把所有逻辑堆在Controller里一个方法写两百行这样后期改一个功能得翻半天代码答辩时被问你这个模块的职责边界是什么也很难回答。3. 数据库设计五张核心表撑起整个平台业务3.1 用户与角色表用户表设计得简单直接字段都是后面登录、展示、权限控制需要用到的CREATE TABLE user ( id bigint(20) NOT NULL AUTO_INCREMENT, username varchar(50) NOT NULL COMMENT 登录账号学号/工号, password varchar(100) NOT NULL COMMENT BCrypt加密后的密码, real_name varchar(50) DEFAULT NULL COMMENT 真实姓名, role tinyint(4) NOT NULL DEFAULT 1 COMMENT 角色1学生 2宣传员 3管理员, college varchar(100) DEFAULT NULL COMMENT 所在学院, phone varchar(20) DEFAULT NULL COMMENT 手机号, status tinyint(4) NOT NULL DEFAULT 1 COMMENT 状态1正常 0封禁, create_time datetime DEFAULT NULL, update_time datetime DEFAULT NULL, PRIMARY KEY (id) ) ENGINEInnoDB AUTO_INCREMENT2 DEFAULT CHARSETutf8mb4;密码存的是BCrypt加密串不是明文。这一点在答辩时一定要主动提属于安全设计的加分项。明文密码在真实项目中就是灾难老师看到你用了Spring Security的BCryptPasswordEncoder基本不会在这个点上刁难你。3.2 案例表与测评表案例表是内容线的核心我设计的字段比较完整CREATE TABLE case_info ( id bigint(20) NOT NULL AUTO_INCREMENT, title varchar(200) NOT NULL COMMENT 案例标题, type varchar(50) DEFAULT NULL COMMENT 诈骗类型冒充客服/刷单返利/注销校园贷等, risk_level tinyint(4) DEFAULT 2 COMMENT 危险等级1低 2中 3高, content text COMMENT 案例详细内容, cover_image varchar(255) DEFAULT NULL COMMENT 封面图URL, author_id bigint(20) DEFAULT NULL COMMENT 录入人宣传员ID, status tinyint(4) DEFAULT 0 COMMENT 审核状态0待审 1已发布 2已下线, view_count bigint(20) DEFAULT 0 COMMENT 浏览量, create_time datetime DEFAULT NULL, update_time datetime DEFAULT NULL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;防骗测评表我拆成了两张一张题目表一张学生答题记录表。题目表里关键字段是正确答案选项和答案解析。注意解析字段很重要学生答完题必须看到解释否则测评就失去了教育意义。答题记录表的设计要点是每题一答明细记录学生每个题目的答案对错。这样之后做数据统计时能分析出学生在哪个类型的题目上错误率最高为宣传员调整内容方向提供依据。3.3 社区表与评论表社区部分包含主题帖和评论两级内容。主题帖表主要字段有帖子标题、正文内容、发布人ID、帖子类型求助/分享/预警、浏览数、回复数、点赞数、置顶状态、删除状态。评论表则记录评论内容、评论人、所属帖子ID、是否作者回复等。这里有个实操经验帖子列表页需要显示回复数和点赞数这个数字如果实时count很浪费资源我直接在帖子表里维护两个冗余字段reply_count和like_count每次有新评论或点赞就update一次。对毕业设计规模的数据量来说这种空间换时间的思路完全够用而且接口响应会更快。4. 核心功能实现案例审核状态机与防骗测评的组卷逻辑4.1 案例内容的结构化录入与状态流转案例录入不是简单插一条记录而是要控制内容质量。我在Service层实现了状态流转逻辑宣传员录入案例后状态为待审0管理员审核通过后状态变为已发布1前台可见管理员发现内容有问题可以操作下线2用状态枚举类维护状态值避免魔法数字到处飞。核心的审核方法实现思路如下Override public Boolean auditCase(Long caseId, Boolean pass) { CaseInfo caseInfo caseInfoMapper.selectById(caseId); if (caseInfo null) { throw new ServiceException(案例不存在); } if (caseInfo.getStatus() ! 0) { throw new ServiceException(只有待审核状态的案例才能审核); } caseInfo.setStatus(pass ? 1 : 2); return caseInfoMapper.updateById(caseInfo) 0; }这里特别注意审核操作前必须判断当前状态是否为待审核状态。如果不判断就会出现已下线的案例又被审核通过的bug。这种状态机校验在答辩时讲出来比单纯演示功能有说服力得多。另一个重点是内容安全。案例详情页渲染的是富文本内容如果不过滤脚本存在存储型XSS风险。我的处理方式是录入时对富文本内容做白名单过滤只保留p、img、a、strong等安全标签其他script、iframe等标签全部去掉。虽然这个过滤逻辑不复杂但体现了你考虑安全问题是加分项。4.2 防骗测评的随机组卷与判分机制测评模块的核心竞争力在于题型贴近真实诈骗话术、每次出卷尽可能不同防止同学互相传答案。我用账号A同学的实际身份来设计这个模块。实现随机组卷的思路如下public QuizVO generatePaper(Long userId) { // 1. 查询所有已上线的题目 ListQuestion allQuestions questionMapper.selectList( new LambdaQueryWrapperQuestion() .eq(Question::getStatus, 1) ); // 2. 按题目类型分组 MapString, ListQuestion grouped allQuestions.stream() .collect(Collectors.groupingBy(Question::getType)); // 3. 每种类型随机抽取固定数量 ListQuestion paper new ArrayList(); grouped.forEach((type, list) - { Collections.shuffle(list); paper.addAll(list.stream().limit(2).collect(Collectors.toList())); }); // 4. 保存试卷快照返回前端 return buildQuizVO(paper); }这样设计的原因很实际如果每次都是同一套题有的学生直接把正确答案背下来测评就完全失去检测意义。每个诈骗类别抽两题既能保证覆盖面又能让试卷数量变得非常多相邻同学拿到的题也大概率不同。判分逻辑不是简单的每题一分而是按类别统计正确率。比如刷单返利类题目共5题答对3题就认为该类型掌握度60%。系统会在测评结果页给出雷达图直观展示学生在哪类诈骗上最薄弱。这个结果页是让老师眼前一亮的点因为它体现了教育数据分析的深度而不是普通测验。4.3 进度追踪与积分激励为了让学习行为有持续性我加了积分机制。学生浏览一篇案例2分完成一次测评且及格10分发布一条有价值的求助帖3分。积分累计后在个人中心展示反诈学习等级初入江湖、谨慎小白、反诈达人、安全卫士。积分机制不是核心需求但性价比极高。它不增加太多开发量却能把整个平台的学习闭环串起来——学生为了升级会主动看案例、做测评、参与互动。答辩时提问平台如何提高学生参与度这个模块就是答案。5. 互动社区与用户隐私帖子发布、审核与敏感信息脱敏处理5.1 社区发帖与智能提醒学生在社区发帖后系统会对文本进行敏感词检测和诈骗关键词扫描。比如帖子里出现转账验证码京东白条屏幕共享等关键词时系统会自动在帖子下面附加一条安全提醒提示本帖子内容涉及敏感转账操作请注意核实对方身份。这个功能的实现不难用一个关键词词库做contains匹配即可但效果非常出彩。我给出的实现思路public Post publish(PostDTO dto) { // 敏感词检测 ListString hitKeywords sensitiveWordUtil.scan(dto.getContent()); Post post new Post(); post.setContent(dto.getContent()); post.setAuthorId(getCurrentUserId()); post.setStatus(hitKeywords.isEmpty() ? 1 : 0); post.setWarning(hitKeywords.size() 0 ? 该内容疑似涉及诈骗话术请谨慎对待 : ); postMapper.insert(post); return post; }这里涉及一个业务决策帖子命中敏感词时是直接拦截还是放行加提醒我的做法是放行但自动附加安全提示。原因很简单——学生分享自己被骗经历时必然会出现转账验证码这些词如果你直接拦截最真实的案例反而发不出来。自动加提醒既保留了内容又对其他浏览者起到了警示作用。这个细节建议大家写进设计文档是能体现思考深度的点。5.2 匿名展示与个人隐私保护学生实名发布求助帖可能担心隐私问题。我在用户隐私设置上做了一个开关默认开启匿名展示。开启后帖子作者显示为匿名同学只保留学院信息。后台管理人员仍可看到发布人ID方便管理。这个功能实现很简单就是在组装帖子的VO对象时根据发布者的匿名设置决定是否展示真实姓名。但你主动做这个设计说明你想到了真实用户在平台上的心理顾虑这一点在需求分析中非常重要。反诈平台本身涉及诈骗案例很多人并不想让别人知道自己差点被骗的经历。5.3 点赞防刷与热门推荐点赞功能如果不做任何限制存在刷票可能。我的做法是用Redis存储用户对某篇帖子的点赞状态key为like:{userId}:{postId}同一用户对同一帖子只能点赞一次再点就是取消。Redis的存取开销非常小同时天然支持过期时间比查数据库判断是否点过赞性能好很多。首页的热门推荐排序规则我用了一个加权公式热门分 浏览量 * 0.3 点赞数 * 0.5 评论数 * 0.2 - 发布时间衰减。这样新发布的高质量内容有机会靠互动量顶上来老内容会随时间慢慢下沉避免推荐区永远被早期几条热门霸占。6. 接口设计与前后端联调从登录鉴权到数据展示6.1 统一返回结果与全局异常处理前后端联调最烦的事情就是接口返回格式不统一。一会儿返回数组一会儿返回对象前端根本没法写。我在项目里设计了统一的返回结构public class ResultT { private Integer code; // 200成功 401未登录 500服务器异常 private String message; private T data; }同时用RestControllerAdvice做了全局异常处理。业务异常统一返回code500和友好提示参数校验失败返回具体字段错误信息。这样前端只需要统一处理Result的code字段不需要每个接口单独写一套逻辑。6.2 基于Spring Security的登录与权限管理登录认证用的是Spring Security JWT方案。流程是用户提交账号密码服务端校验通过后生成JWT令牌前端把令牌存在本地每次请求在Header中携带Authorization字段。Spring Security的过滤器会在请求到达Controller前解析令牌判断用户身份和角色权限。这里有一个新手很容易踩的坑Spring Security默认会拦截所有请求你如果没配置放行规则静态资源、登录接口、注册接口全都会被拦。正确配置如下protected void configure(HttpSecurity http) throws Exception { http.csrf().disable() .authorizeRequests() .antMatchers(/api/auth/login, /api/auth/register).permitAll() .antMatchers(/api/case/list, /api/case/detail).permitAll() .antMatchers(/api/admin/**).hasRole(ADMIN) .antMatchers(/api/operator/**).hasAnyRole(ADMIN, OPERATOR) .anyRequest().authenticated(); }配置权限时我踩过一次比较深的坑/api/operator/**需要管理员或宣传员角色访问但Spring Security的hasAnyRole要求角色名不带前缀地传入而我数据库里存的是ROLE_ADMIN导致权限匹配一直失败。后来统一改成角色表只存ADMIN、OPERATOR、STUDENT在框架层加前缀立即就通了。这类排错过程建议记录在开发日志里后期写项目总结用得上。6.3 跨域问题与联调配置前端部署在Vite服务默认端口5173后端跑在8080端口这属于跨域请求必须处理后端跨域。我用的CorsFilter配置如下Configuration public class CorsConfig { Bean public CorsFilter corsFilter() { CorsConfiguration config new CorsConfiguration(); config.addAllowedOriginPattern(*); config.addAllowedHeader(*); config.addAllowedMethod(*); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration(/**, config); return new CorsFilter(source); } }关于跨域有几句经验第一种方式是服务端加跨域配置第二种是前端通过Vite的proxy代理转发路径以/api开头实际请求转发到后端8080这种方式浏览器看到的请求是同源的不需要后端做跨域。我项目中两种都研究过最终选用了后端CorsFilter方案因为将来项目打包后前端是静态文件后端是独立jar包代理方式反而麻烦。7. 演示准备、数据初始化与上线部署毕业设计最容易被忽略的三件事7.1 用SQL脚本一键造出漂亮的演示数据我做演示数据有个深刻体会空的系统在答辩时非常难看你要现场填数据更是灾难。我的做法是写了一个>java -jar antifraud-platform.jar --spring.profiles.activeprod我建议配置多环境profilesapplication-dev.yml对应本地开发application-prod.yml对应生产环境数据库地址、日志级别、文件上传路径可能不同。用一个启动参数切换非常干净。7.3 答辩演示时的操作路线与常见问题应对演示环节怎么演是有讲究的。我的推荐路线是先演示学生端从登录开始浏览案例库打开一条高危险等级案例展示案例详情和防骗启示。做一次防骗测评故意答错一两题展示测评结果页的数据分析。发一条包含转账关键词的帖子展示系统自动附加的安全提示。切换到宣传员账号演示案例录入流程提交到后台。切换到管理员账号审核通过刚才提交的案例然后打开数据统计页面展示各类型案例浏览量和测评正确率。每个环节之间要能讲清楚为什么这么设计而不是单纯点按钮。答辩老师最常问的问题一般是这几个同一用户重复提交测评怎么办案例审核为什么会设计待审状态密码是怎么加密的帖子审核为什么不是强制拦截这些问题在前面章节的设计里基本都有答案你只要把为什么讲透就很有说服力。8. 写在最后这个项目还能往哪些方向延伸从稳定性和实际开发时间来看我建议后续可以补充的功能还有三个方向一是消息通知模块学生关注的诈骗类型有高危险新案例时通过邮件或站内信推送二是数据可视化优化把各学院测评参与率、各诈骗类型高发趋势做成大屏效果用于学校安全宣传会议展示三是导入真实警方预警数据的接口让案例库内容动态更新。我个人的建议是毕业设计不必追求功能数量而是把一条主线做深做透。这个平台的主线就是案例—学习—测评—互动的教育闭环。你把每个环节的细节打磨到位设计文档里写清楚每个决策的依据答辩表现自然不会差。做这个项目的过程中我对反诈宣传不能靠单项灌输必须让用户参与进来这一点有了很直观的体会这个思路甚至比代码本身更值得你带走。