基于SpringBoot的反诈科普平台：从表结构到答题闭环的设计实践

每年毕业设计季节，我都会收到一批“反诈平台”源码的求助消息，搜索记录里最常出现的标题之一就是：springboot反诈科普与宣传平台-计算机毕业设计源码62170。很多同学的想法是找一个能跑的SpringBoot项目，改改页面、换换数据库名，能演示就算完成。但实际上，反诈科普与宣传平台这类题目，核心难点根本不在CRUD，而在“科普内容如何触达用户”“反诈知识如何检验效果”“举报线索如何形成闭环”这几个业务问题上。如果你能把这个链路想清楚，再落到表结构和接口设计里，这件“看起来普通”的毕设，反而比一堆花哨但不实用的商城项目更容易拿高分。

这篇内容我打算直接以反诈科普平台的完整设计思路为主线来拆解，从业务定位、数据库设计、后端关键模块，到前端演示动线、部署避坑，把一套能真正落地、能应付答辩追问的实现路径给梳理出来。不管你是刚拿到这个题目，还是已经在改造网上那个千篇一律的SpringBoot源码，这篇文章都值得你花十分钟看完。

1. 反诈科普平台不是文章系统：先想清楚业务闭环

很多同学拿到这个标题，第一反应就是“做一个科普文章展示站”，分类、列表、详情、后台发布，完了。这确实是最省事的做法，模板也多，复制粘贴就能跑。但我建议你先停下来想一想：如果仅仅是文章发布，为什么要叫“平台”？和普通内容管理系统的区别在哪里？

1.1 反诈宣传的核心矛盾是“知道了但记不住”

如果做过实际的反诈宣传就会发现，发传单、放视频、推文章，用户当时觉得有道理，几天后遇到改头换面的诈骗话术，照样不认识。这中间的断层在于：用户只完成了信息接收，没有完成认知转化。

所以这个平台不应该只有单向的内容输出，还要有双向的交互验证。比较合理的最小闭环是：用户浏览科普内容后，可以做一套场景化答题；答错的题目会展示对应类型的真实骗局拆解；答题结果形成个人风险画像，推送专项内容；如果用户在现实里遇到了可疑情况，还能通过平台快速提交举报线索，后台管理人员处理后反馈结果。

这个闭环听起来不难，但它需要系统里至少有内容管理、题库管理、答题记录、线索上报、后台处置、用户反馈这几块联动。毕业设计的“设计感”，就是从这些跨模块的数据流里体现出来的。

1.2 角色划分：两个前端加一个后台就够了

反诈科普与宣传平台，面向的人群主要有两类：普通公众和宣传管理人员。绝大多数情况下，做三个端就够了：

• 用户端（H5或响应式网页）：浏览科普文章、看骗局案例库、参与答题闯关、提交举报线索、查看个人答题记录。
• 管理后台（Web端）：内容管理、题库维护、线索处置、数据统计。
• 系统管理员（内置角色）：管理后台账号、分配管理角色、查看操作日志。

一个常见的错误是把这个题目做成“纯管理员后台版文章CMS”，用户侧就是普通的列表页，没有任何用户行为数据沉淀。这样的项目展示起来非常干，答辩老师问“你这个平台有什么实际效果”时，你只能回答“能发布反诈文章”，这显然撑不起一篇合格的计算机专业毕业设计。

1.3 从“功能能不能演示”反推模块边界

在规划模块时，可以倒着推：如果答辩现场只能演示一个功能，你会演示哪个？我的建议是演示“答题闯关后生成测评结果，再根据结果推荐反诈内容”这条线，因为它把内容、题库、用户行为、推荐筛选全串起来了。这会逼着你把功能边界规划得更清楚。

表格里的每一项，映射到数据库里都会产生至少一张表。你在开题报告里把这些交互逻辑写清楚，后面写代码就不会乱。切记：不要急着写Controller，先花一天确定角色关系和界面流程图，这才是整个项目真正的前期设计部分。

2. 表结构设计决定了答辩上限：核心表字段与关系拆解

SpringBoot项目的代码框架大多千篇一律，真正能让你的项目在答辩时“扛住提问”的，是数据库设计里体现的思考深度。反诈平台的表结构，我建议核心业务表控制在12张左右，太少了没有工作量，太多了容易顾此失彼。

2.1 用户与权限表：尽量简洁但要留扩展位

如果直接用Spring Security + 数据库角色，配置写起来会非常啰嗦。对于毕设项目，我更建议用“用户表 + 角色字段 + 登录拦截器”的组合，既保留扩展性，又让代码逻辑足够清晰。

用户表设计如下：

sql复制CREATE TABLE sys_user (
    id             BIGINT AUTO_INCREMENT PRIMARY KEY,
    username       VARCHAR(64)  NOT NULL COMMENT '登录账号',
    password       VARCHAR(128) NOT NULL COMMENT 'BCrypt加密后的密码',
    phone          VARCHAR(20)  DEFAULT NULL COMMENT '手机号',
    nickname       VARCHAR(64)  DEFAULT NULL COMMENT '用户昵称',
    role_code      VARCHAR(32)  NOT NULL DEFAULT 'USER' COMMENT '角色：ADMIN/OPERATOR/USER',
    status         TINYINT      NOT NULL DEFAULT 1 COMMENT '1启用，0禁用',
    register_time  DATETIME     DEFAULT NULL,
    last_login_time DATETIME    DEFAULT NULL,
    PRIMARY KEY (id),
    UNIQUE KEY uk_username (username)
) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4 COMMENT = '系统用户表';

这里的注意点是：密码一定不要用MD5明文存储，哪怕项目只在本机跑。用 BCryptPasswordEncoder 加密后，即使数据库被翻出来，也没法反推出明文。很多同学交源码时不改默认密码，用 123456 直接跑，这一点在论文上写出来非常不专业。

2.2 科普内容与反诈案例库：内容型平台的门面

科普内容和案例库是运营侧最重要的两张表。文章表可以做得中规中矩，但案例库表要充分考虑“场景化标签”：

sql复制CREATE TABLE fraud_case (
    id               BIGINT AUTO_INCREMENT PRIMARY KEY,
    case_title       VARCHAR(200) NOT NULL COMMENT '案例标题',
    fraud_type       VARCHAR(50)  NOT NULL COMMENT '诈骗类型：刷单/杀猪盘/冒充客服等',
    scene_tag        VARCHAR(100) DEFAULT NULL COMMENT '场景标签：网购/理财/社交/招聘等',
    case_desc        TEXT COMMENT '案件过程描述',
    fraud_chain      TEXT COMMENT '诈骗链条步骤拆分',
    analysis_content TEXT COMMENT '专业分析',
    prevention_advice TEXT COMMENT '防范建议',
    source_platform  VARCHAR(100) COMMENT '来源渠道，如短信/电话/App',
    cover_image      VARCHAR(255) DEFAULT NULL,
    view_count       INT DEFAULT 0,
    publish_status   TINYINT NOT NULL DEFAULT 0 COMMENT '0草稿，1已发布',
    create_time      DATETIME DEFAULT NULL,
    update_time      DATETIME DEFAULT NULL,
    PRIMARY KEY (id)
) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4 COMMENT = '反诈案例库';

案例表为什么要单独拆 fraud_chain 和 analysis_content 两个长文本字段？因为反诈案例的展示逻辑和普通文章不同：用户最关心的是“骗子是怎么一步步骗我的”和“我应该怎么防”。前端做详情页时，案例过程、链条拆解、防范建议应该分别渲染在不同的板块里，这样视觉上更清晰，也更符合实际宣传逻辑。

2.3 答题系统与测评结果：平台最具区分度的部分

答题模块建议设计三张表：题库表、答题记录表和答题明细表。题库表我建议使用“选项用JSON存储”的方案，而不是拆成题目选项关联表。原因很实际：反诈题目大多是单选和判断题，把选项放成JSON字段，编程简单、查询方便、也方便Excel导入解析。

sql复制CREATE TABLE quiz_question (
    id            BIGINT AUTO_INCREMENT PRIMARY KEY,
    question_type TINYINT NOT NULL COMMENT '1判断，2单选，3情景分析',
    scene_type    VARCHAR(50) COMMENT '关联场景标签',
    question_text TEXT,
    option_json   TEXT COMMENT '选项JSON，如[{"key":"A","text":"..."}]',
    answer        VARCHAR(10) NOT NULL COMMENT '正确答案',
    analysis      TEXT COMMENT '答案解析',
    difficulty    TINYINT DEFAULT 1 COMMENT '1-5',
    create_time   DATETIME DEFAULT NULL,
    PRIMARY KEY (id)
) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4 COMMENT = '反诈题目表';

答题记录表用于保存每次测评的主记录：

sql复制CREATE TABLE quiz_record (
    id            BIGINT AUTO_INCREMENT PRIMARY KEY,
    user_id       BIGINT NOT NULL,
    total_score   INT DEFAULT 0,
    correct_count INT DEFAULT 0,
    total_count   INT DEFAULT 0,
    risk_level    VARCHAR(20) COMMENT '风险等级：低/中/高',
    duration      INT DEFAULT 0 COMMENT '答题用时（秒）',
    create_time   DATETIME DEFAULT NULL,
    PRIMARY KEY (id),
    KEY idx_user_time (user_id, create_time)
) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4 COMMENT = '答题测评记录表';

再配合一张 quiz_record_detail 表记录每道题用户选的答案和是否正确。这个设计能在后面支持很漂亮的“错题薄弱类型分布”统计。比如用户连续在“冒充公检法”场景下答错三题，系统就可以给用户打上“该类场景高风险”的标签，前端在个人中心展示这个画像时，答辩是非常有效的亮点。

2.4 线索上报表与运营统计表：让平台具备“处置能力”

举报线索表是这个项目和普通内容平台区别最明显的地方。我建议字段包括：

sql复制CREATE TABLE report_clue (
    id            BIGINT AUTO_INCREMENT PRIMARY KEY,
    user_id       BIGINT,
    report_type   VARCHAR(50) COMMENT '可疑电话/短信/App/网站/线下',
    target_number VARCHAR(200) COMMENT '对方账号、电话号码或网址',
    report_content TEXT,
    evidence_urls TEXT COMMENT '截图证据，多个用逗号分隔',
    clue_status   TINYINT DEFAULT 0 COMMENT '0待处理，1已处置，2无效线索',
    handle_remark VARCHAR(500),
    handler_id    BIGINT,
    handle_time   DATETIME,
    create_time   DATETIME DEFAULT NULL,
    PRIMARY KEY (id)
) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4 COMMENT = '举报线索表';

新增线索后，管理员界面应当有红色的待办角标提示。这种“待办数字变化”对演示来说比静态列表更动感，还能体现前后端交互。

关于统计报表，我不建议用实时SQL反复count，可以用一张 daily_platform_stat 汇总表，每天凌晨由定时任务统计前一日的注册数、内容浏览量、答题人次、举报量。这样后台的图表展示时数据稳定，也能顺畅引出SpringBoot里的定时任务话题。

3. SpringBoot核心编码：鉴权、内容管理、答题上报怎么写出工作量

数据库设计完成后，开始写SpringBoot代码时，很多人会陷入“骨架生成器一键生成CRUD，然后不知道怎么加肉”的情况。这里我挑几个最能在源码里体现工作量、也最容易在答辩时被问到的点，展开讲一讲。

3.1 登录鉴权：用拦截器 + JWT 代替复杂安全框架

选型之前先想明白：反诈科普平台需要复杂的权限表达式吗？大概率不需要。系统只有管理员和普通用户两类角色，用Spring Security会把大量精力耗在过滤器链配置上，性价比不高。我建议使用 HandlerInterceptor + JWT 的轻量方案，理由有三个：

• 代码可读性强，拦截器里如何校验、如何放行白名单，逻辑一目了然；
• JWT无状态，前后端联调时只需要在请求头里带 Authorization 即可；
• 答辩时你能清晰讲出token过期、续签、无状态鉴权的原理，这是加分项。

定义一个简单的拦截器：

java复制public class AuthInterceptor implements HandlerInterceptor {

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        // 放行跨域预检请求
        if ("OPTIONS".equalsIgnoreCase(request.getMethod())) {
            return true;
        }
        String token = request.getHeader("Authorization");
        if (token == null || !token.startsWith("Bearer ")) {
            response.setStatus(401);
            return false;
        }
        // 解析、校验，这里可抽出JwtUtil
        Claims claims = JwtUtil.parseToken(token.substring(7));
        if (claims == null) {
            response.setStatus(401);
            return false;
        }
        request.setAttribute("userId", claims.get("userId"));
        request.setAttribute("roleCode", claims.get("roleCode"));
        return true;
    }
}

在注册拦截器时，要特别注意放行路径。/api/auth/login、/api/articles/**、/api/cases/** 这类公开内容应允许匿名访问，而 /api/admin/**、/api/user/**、/api/report/** 必须经过鉴权。如果你的前端页面使用了静态资源，还要为 /upload/**、/assets/** 设置静态资源映射，否则上传图片会404。

注意：反诈答题记录属于用户个人行为数据，前端页面在请求 /api/quiz/record 时，拦截器里拿到的 userId 不能由前端传入，必须从token中解析。这样能防止用户篡改参数查看他人记录，也是安全设计的体现。

3.2 管理端内容维护：引入Excel批量导入

反诈案例库单靠后台手工录入效率太低，实际运营场景中一定涉及批量数据导入。这里不需要引入很重的中间件，直接用 EasyExcel 就能处理。例如，后台管理员上传一个包含案例标题、诈骗类型、案件过程、防范建议等列的Excel文件，就能快速生成一批草稿数据。

代码结构简述如下：

java复制@PostMapping("/api/admin/cases/import")
public Result<String> importCases(@RequestParam("file") MultipartFile file) {
    if (file.isEmpty()) {
        return Result.fail("文件为空");
    }
    List<FraudCaseImportVO> list = EasyExcel.read(file.getInputStream())
            .head(FraudCaseImportVO.class)
            .sheet()
            .doReadSync();
    fraudCaseService.batchSaveFromImport(list);
    return Result.success("成功导入 " + list.size() + " 条案例");
}

这个功能看起来简单，但要注意三个细节。第一，校验Excel表头字段，空模板要有可下载入口。第二，导入的原始数据应该先进入“草稿”状态，而不是直接“已发布”，防止脏数据直接展示。第三，如果导入失败，要返回具体是哪一行哪一列格式不对，不能整个事务回滚后让人慢慢猜。

3.3 情景答题核心逻辑：顺序抽题、实时判分、结果分级

答题模块的后端逻辑通常是：按场景或题目难度，从题库中随机抽取10道题给用户作答，用户提交答案后，后端编译并返回得分和风险等级。

具体的核心伪代码如下：

java复制public QuizSubmitVO submitQuiz(QuizSubmitDTO dto, Long userId) {
    List<UserAnswerDTO> answers = dto.getAnswers();
    // 1. 批量查询题目
    List<QuizQuestion> questions = questionMapper.selectBatchIds(
        answers.stream().map(UserAnswerDTO::getQuestionId).collect(Collectors.toList())
    );
    // 2. 判分
    int correctCount = 0;
    List<QuizAnswerDetail> details = new ArrayList<>();
    for (QuizQuestion q : questions) {
        UserAnswerDTO dtoItem = 根据题目id匹配;
        boolean correct = q.getAnswer().equalsIgnoreCase(dtoItem.getSelectedAnswer());
        // 记录用户答案、是否正确、正确答案、解析
    }
    // 3. 根据正确率计算风险等级
    String riskLevel = evaluateRiskLevel(correctCount, questions.size());
    // 4. 保存主记录和明细记录
}

有几个问题非常容易踩坑。一个是题目答案比较时，用户答“A”和“a”应视为一致，需要统一转大写。另一个是前端传来的题目数可能大于题库里的已发布数量，后端一定要加校验，比如未发布、已删除的题不能出现在答题范围内。

答题结束后的“推荐内容”其实不需要复杂的推荐算法，写成SQL查询就行：根据答错的题目的 scene_type，去案例库或文章表里查询同场景已发布且浏览量最高的几条记录。在毕业设计里，这种“根据行为做关联推荐”的实现方式很说明问题，不一定要强行套用协同过滤。

3.4 定时任务用于统计和“防遗忘提醒”

不少反诈宣传平台会设计“每日推送一条反诈日历”的功能。这功能可以用SpringBoot自带的 @Scheduled 来实现，比如每天早上9点查询表里今天需要推送的内容，插入到用户的站内信或者集中推送记录。

使用定时任务时注意，生产环境最好不要把所有定时任务都写在启动类中直接调度。可以把任务逻辑沉淀在 service 层，然后在定时任务类里调用，并给每个定时任务加独立的日志记录。这样你在论文里能写“系统配置了定时统计任务，每晚凌晨对平台核心运营指标进行汇总”，比空口说“做了数据统计”有说服力多了。

如果你在项目需求文档里看到了多级审核发布流程，也就是“宣传员提交内容、主管审核、管理员发布”这种状态机结构，再去考虑集成Flowable工作流引擎。如果只是自己一个人管理后台，那强行上Flowable属于自找麻烦，演示一旦卡住很难圆场。

4. 前端交互与数据可视化：演示动线怎么设计不冷场

聊完了后端，来说说前端。很多毕业设计源码里的前端页面都是从模板网站上临时扒下来的，虽然能显示数据，但页面之间缺乏递进关系，演示时老师并不知道你项目的核心价值在哪里。我个人建议，不管你用Vue还是Thymeleaf模板，页面设计都要围绕一条“演示动线”来做。

4.1 技术选型：模板渲染还是前后端分离？

如果一个人的工期只有两到三周，并且前端基础一般，用 Thymeleaf + Bootstrap 是最稳妥的。它不需要考虑跨域，不需要搭前端构建环境，服务端渲染出来的页面刷新就是最新数据，部署也很简单。但如果你已经决定用Vue + Element Plus做后台，用户端再用响应式页面，那么前后端分离方案虽然工作量大一些，做出来的界面质感和交互效果通常会更好。

这里我给一个折中建议：管理后台必须用Vue + Element Plus，这是目前毕设项目的常态，模板多，表格和表单组件齐全，开发效率高。用户端可以考虑两种情况：如果主要展示场景是电脑浏览器，做一个响应式网站就够了；如果想法是“反诈宣传进社区”，那用户端更适合做成手机端H5的形态，导航尽量少，核心入口突出“答题测试”和“案例库”。

4.2 重点页面：答题闯关页和结果报告页

答题闯关页是整个平台交互最重的页面。设计原则是“一屏一题”，顶部显示进度条，底部只有“上一题/下一题/提交”按钮。选项不要用标准的radio原样呈现，最好做成整块可点击的卡片，点击后高亮当前选项，这样答题体验会好很多。

提交答案后跳转到结果报告页，这个页面直接决定用户会不会留下来。报告页要展示几个信息：

• 总分、正确题数、答题用时；
• 风险等级，如果高风险，用更明显的颜色提示；
• 错题列表，每道错题附带“案件还原”的引导入口；
• 针对薄弱场景的推荐内容。

比如某用户在做题时答错了“冒充物流客服退款”场景下的题目，报告页下方就推荐近期关于冒充客服类骗局的案例和反诈文章。用户在报告页完成浏览后，这些浏览行为又会被记录到每天统计表里。这个设计在论文的“系统测试”章节里非常出彩，因为你能写出“测试用户完成一轮测评后，首页推荐内容发生变化”这样具体可验证的结果。

数据可视化部分，我建议别贪多。管理后台首页展示三张核心图足够：近7天文章浏览量和答题量走势、诈骗类型占比饼图、最近一周举报线索处置状态。如果要展示地域趋势，可以用ECharts加载中国地图，但地图GeoJSON文件体积通常在数百KB以上，首次加载会明显卡顿，毕设演示时尽量提前加载好或直接用柱状图替代。

4.3 页面权限控制与操作日志

前端页面权限不一定必须用动态路由，但要让不同角色登录后看到不同菜单。我的做法是登录接口返回用户信息和角色编码，前端根据角色编码在路由守卫里做跳转判断。

同时管理端的每一项敏感操作，比如发布文章、删除案例、处置举报，都要调后端接口记录到操作日志表里。关于操作日志的实现，网络上常推荐AOP方式，实际上在毕业设计里更简单直接的办法是写一个 OperationLogService，在管理员操作的方法内部调用一次。这样做虽然少了一点“高级感”，但可读性和可维护性更强，答辩时也不会被问倒。

5. 部署、源码整理与答辩前的避坑清单

最后说一个很多同学不太重视但至关重要的问题：项目能不能在别人电脑上快速跑起来。如果你买到的源码或自己写的项目，别人按照README操作半小时还启动不了，那不管界面多好看，对答辩来说都是减分项。

5.1 版本选型是第一道坎

最近两年我看到的典型问题是SpringBoot版本选得太高。SpringBoot 3.0以后要求JDK 17，很多老机器或实验室电脑装的是JDK 8，两边一冲突，各种包找不到。

如果你没有特殊要求，我的建议是直接锁定 JDK 1.8 + SpringBoot 2.7.x。原因很简单：市面大部分教程、依赖解决方案都基于这个组合，MyBatis-Plus、Druid、Hutool、EasyExcel这些库对SpringBoot 2.x的兼容性更稳定。你写的代码放上去不容易出现“网上搜不到原因”的环境问题。

application.yml 里几个关键先检查一下：

yaml复制server:
  port: 8080

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/fanzha_platform?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai
    username: root
    password: 123456
  servlet:
    multipart:
      max-file-size: 20MB
      max-request-size: 20MB
  mvc:
    static-path-pattern: /**

mybatis-plus:
  mapper-locations: classpath*:mapper/**/*.xml
  configuration:
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

注意 serverTimezone=Asia/Shanghai 必须要加，否则MySQL 8.0和驱动之间关于时区的警告能烦死你。另外，MySQL 8.0以上还需要在pom里引入对应的驱动依赖，用 com.mysql.cj.jdbc.Driver。这些细节看似小，实际很多源码跑不起来就是栽在它们头上。

5.2 运行源码的常规步骤，缺一不可

拿到一个毕设源码，正常跑起来要经过的步骤大概是：

1. 新建数据库，执行项目sql目录下的初始化脚本；
2. 修改application配置中的数据库账号密码；
3. 使用IDEA打开项目，等待Maven导入依赖；
4. 如果是前后端分离，进入前端目录执行 npm install，然后 npm run dev；
5. 后端启动成功后，先访问登录接口测试连通性；
6. 用管理员账号登录后台，查看文章、案例、轮播图等基础数据。

如果你发现自己拿到的源码没有 sql 目录或初始化脚本，只有一句“请导入数据库”，那你需要警惕，这不是一份完整的源码。缺少数据初始化的项目，即使代码能启动，登录后也是空页面，远达不到演示效果。

5.3 项目里建议初始化的数据

不要在答辩时现场手工录入内容。一个合格的项目应该内置一批演示数据，包括：

• 1个管理员账号、1个运营账号、若干普通用户账号；
• 5个左右文章分类，每个分类下至少2篇已发布文章；
• 至少10条以上反诈案例，覆盖刷单返利、冒充客服、杀猪盘、冒充公检法等主要类型；
• 每类场景配3至5道题目，整体题库量不能低于20道；
• 少量历史答题记录和举报线索，让后台图表看起来有数据。

初始化管理员密码不能明文写“123456”就完事。因为密码字段需要存入BCrypt密文，你得先写一个临时接口或在测试类里调用加密方法生成密文，然后把密文写进SQL脚本。例如“123456”加密后是类似 $2a$10$... 的字符串，绝对不能把原始密码直接塞到password列里。

5.4 质量差的源码会有哪些“身份证特征”

我接触过不少打包出售或开源的SpringBoot毕设项目，质量差异极大。你可以用下面几个信号快速判断一个源码值不值得作为基础来改：

拿到源码后第一件事不是改代码，而是做一次完整的“空库启动测试”。从创建一个新数据库开始，按README执行全部步骤，如果半小时内能登录后台且页面有数据，再考虑在此基础上做二次开发。如果连启动都办不到，后面的一切优化都是浪费时间。

5.5 演示前做好这四件事，现场基本不会翻车

经验之谈，答辩演示翻车大多不是功能本身的问题，而是现场操作节奏导致的。建议按下面几个步骤准备：

第一，准备一个专用演示账号，密码不要现场输入，用浏览器记住密码。很多同学在台上手忙脚乱把密码输错三次被锁定IP，状态非常尴尬。

第二，把网络通路的依赖降到最低。前端资源尽量本地打包，不要依赖外网CDN。如果答辩现场断网，而你前端引用的Element Plus和ECharts是远程CDN，页面会白屏到只剩文字。

第三，提前把浏览器缩放到合适比例。管理后台的表单和图表在投影仪上展示时，字体默认可能偏小，建议开发时字体最小不小于14px，图表标题不小于18px，让最后一排的评委也能看清。

第四，准备好一条“核心演示路径”：管理员登录 → 查看首页数据统计 → 进入答题管理确认题目数量 → 切换普通用户登录 → 完成一次答题 → 生成结果报告 → 在报告页点击推荐内容 → 回到管理后台查看最新答题统计和一条举报处置记录。如果时间紧张，只走这条路径就够了，不要东点一下西点一下。

另一个很实用的小技巧是，在浏览器按F12打开开发者工具，切到手机模拟模式，然后演示用户端答题页面。这会让老师直观感受到你考虑了移动端访问场景。毕竟反诈宣传面对的普通公众大多用手机看页面，而不是在电脑上打开一个后台地址。

最后，在所有功能里我建议在“个人中心”增加一个“我的错题”模块，记录用户每次答错的题目及解析，用户可以随时回看。这个功能不复杂，但它在答辩时可以这样表述：平台不是考完就结束，而是通过错题回顾和针对性内容推荐，让反诈宣传产生持续效果。实际项目中，这个模块也正好串起了题库、答题记录、错题明细、内容推荐四张表，是一次很完整的业务逻辑展示。把这条线讲顺，你这个反诈科普与宣传平台就不再只是一个能跑的SpringBoot模板，而是一个真的有设计思想的作品。