基于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.x，Java用的是1.8（很多学校机房老电脑上装的是JDK8，用高版本容易没人给你改环境）。Maven核心依赖如下：

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.18</version> </parent> <dependencies> <!-- Web层 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <!-- 安全认证 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-security</artifactId> </dependency> <!-- ORM持久层 --> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <!-- 工具类 --> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> <dependency> <groupId>com.github.xiaoymin</groupId> <artifactId>knife4j-spring-boot-starter</artifactId> <version>2.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`) ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8mb4;

密码存的是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`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

防骗测评表我拆成了两张：一张题目表，一张学生答题记录表。题目表里关键字段是正确答案选项和答案解析。注意解析字段很重要，学生答完题必须看到解释，否则测评就失去了教育意义。

答题记录表的设计要点是"每题一答"，明细记录学生每个题目的答案对错。这样之后做数据统计时，能分析出学生在哪个类型的题目上错误率最高，为宣传员调整内容方向提供依据。

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. 查询所有已上线的题目 List<Question> allQuestions = questionMapper.selectList( new LambdaQueryWrapper<Question>() .eq(Question::getStatus, 1) ); // 2. 按题目类型分组 Map<String, List<Question>> grouped = allQuestions.stream() .collect(Collectors.groupingBy(Question::getType)); // 3. 每种类型随机抽取固定数量 List<Question> 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) { // 敏感词检测 List<String> 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 Result<T> { private Integer code; // 200成功 401未登录 500服务器异常 private String message; private T data; }

同时用@RestControllerAdvice做了全局异常处理。业务异常统一返回code=500和友好提示，参数校验失败返回具体字段错误信息。这样前端只需要统一处理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.active=prod

我建议配置多环境profiles：application-dev.yml对应本地开发，application-prod.yml对应生产环境（数据库地址、日志级别、文件上传路径可能不同）。用一个启动参数切换，非常干净。

7.3 答辩演示时的操作路线与常见问题应对

演示环节怎么演，是有讲究的。我的推荐路线是：

1. 先演示学生端，从登录开始，浏览案例库，打开一条高危险等级案例，展示案例详情和防骗启示。
2. 做一次防骗测评，故意答错一两题，展示测评结果页的数据分析。
3. 发一条包含"转账"关键词的帖子，展示系统自动附加的安全提示。
4. 切换到宣传员账号，演示案例录入流程，提交到后台。
5. 切换到管理员账号，审核通过刚才提交的案例，然后打开数据统计页面，展示各类型案例浏览量和测评正确率。

每个环节之间要能讲清楚"为什么这么设计"，而不是单纯点按钮。答辩老师最常问的问题一般是这几个：同一用户重复提交测评怎么办？案例审核为什么会设计待审状态？密码是怎么加密的？帖子审核为什么不是强制拦截？这些问题在前面章节的设计里基本都有答案，你只要把"为什么"讲透，就很有说服力。

8. 写在最后：这个项目还能往哪些方向延伸

从稳定性和实际开发时间来看，我建议后续可以补充的功能还有三个方向：一是消息通知模块，学生关注的诈骗类型有高危险新案例时，通过邮件或站内信推送；二是数据可视化优化，把各学院测评参与率、各诈骗类型高发趋势做成大屏效果，用于学校安全宣传会议展示；三是导入真实警方预警数据的接口，让案例库内容动态更新。

我个人的建议是：毕业设计不必追求功能数量，而是把一条主线做深做透。这个平台的主线就是"案例—学习—测评—互动"的教育闭环。你把每个环节的细节打磨到位，设计文档里写清楚每个决策的依据，答辩表现自然不会差。做这个项目的过程中，我对"反诈宣传不能靠单项灌输，必须让用户参与进来"这一点有了很直观的体会，这个思路甚至比代码本身更值得你带走。