1. 项目概览这个问卷调查系统到底能做什么做技术这么多年我接触过不少“看起来很基础、做起来全是细节”的系统网上问卷调查系统就是其中典型的一个。很多朋友一开始觉得它就是“问卷CRUD 答题页面”真上手之后才发现从题目类型设计、动态表单渲染、答卷校验到统计报表每一环都能踩出不同的坑。这篇文章我想围绕一个基于 SpringBoot 的网上问卷调查系统展开把我从项目设计、数据库建模、核心代码实现到部署排查的完整链路都拆开讲讲顺便把源码里值得关注的部分挑出来逐段说明。这套系统的定位非常明确面向中小规模调研场景比如企业内部员工满意度调查、学校课程评价、产品上线前的用户反馈收集等。它需要支持管理员创建问卷、维护题库、发布问卷、查看回收数据同时还要支持参与者打开链接答题、提交答卷、事后查看结果。从业务复杂度来看它不像电商系统那样有复杂的交易链路也不像后台管理系统那样全是表格和权限配置它真正的难点在于“问卷是一种高度动态的数据结构”——每份问卷的题目数量不同、题型不同、选项不同答卷数据又是一对多关联的这就要求在设计阶段就把数据的灵活性和统计的可用性同时考虑进去。这个项目适合谁来参考呢如果你正在学习 SpringBoot 整合 MyBatis Plus想找一个能覆盖“增删改查 多表关联 数据统计 前端渲染”的完整案例那它很合适。如果你要做毕业设计或者个人作品集那它同样值得一看因为问卷系统的业务闭环非常完整既能体现数据库设计能力也能体现接口设计能力和业务建模能力。我这里会按实际的开发顺序来讲不是那种只贴代码不解释的教程每一步尽量说清楚“为什么这么做”。你哪怕之前没见过问卷系统的代码照着我这个思路也能把整个项目的脉络捋明白。2. 整体设计思路与技术选型背后的考量2.1 为什么用 SpringBoot而不是传统 SSM很多老项目还在用 SpringMVC MyBatis XML 那一套能在里面游刃有余的开发者确实基本功扎实但是新项目再用 SSM 纯属自己给自己上强度。SpringBoot 的价值不在于“功能多”而在于它把那些固定套路全部收敛成了约定内嵌 Tomcat、自动装配数据源、Starter 一键引入依赖再加上application.yml统一管理配置开发阶段只需要关注业务本身。我见过不少朋友纠结“SpringBoot 是不是太傻瓜化了学不到底层原理”这个担心其实没必要——SpringBoot 只是把框架的装配过程自动化了你用到的 Spring IOC、AOP、事务传播机制、MyBatis 映射原理一样不少只是省掉了那堆web.xml和spring-mvc.xml而已。还有一个容易被忽略的点是测试和部署成本。问卷调查系统的迭代速度不慢经常要加题型、加统计口径SpringBoot 的spring-boot-devtools支持热重启配合spring-boot-maven-plugin打包出一个可执行 Jar扔到服务器上java -jar就能跑。对于中小型团队来说这种“低摩擦”的交付方式比传统 SSM 要顺滑得多。另外后续如果要引入 Spring Security 做登录鉴权、引入 Redis 做答题防刷SpringBoot 生态的整合成本也低得多。2.2 数据库建模问卷、题目、选项、答卷的关联设计这一节是整个系统最核心的部分。我见过很多初学者把问卷设计成一张大表题目和选项全塞在 JSON 字段里这么做原型阶段确实爽但到了“统计某道题有多少人选了某个选项”的时候就傻眼了Java 代码里要解析 JSON、要手写聚合逻辑性能差还容易出 bug。所以在这套系统里我采用了一套经典的“四层模型”问卷表questionnaire记录问卷基础信息包括标题、描述、状态草稿/发布/结束、开始时间、结束时间、是否匿名、每日答题次数限制。题目表question通过questionnaire_id关联问卷每个题目包含题型、题干、是否必填、排序号等字段。选项表option通过question_id关联题目用于单选、多选、下拉等题型。填空和评分题没有选项取决于题型标记。答卷结果表answer主要记录用户对某道题目的作答内容选项型题目存选项ID填空型题目存文本内容。这里有一个关键点值得展开考试系统里的答题记录通常用“一次提交一行主记录 明细子表”的方式但问卷系统我不建议套用同一套模型。因为问卷的题目是动态的今天创建的问卷可能只有 5 道题明天创建的问卷可能就有 30 道题如果用固定字段去存每一题的答案表结构就得频繁变更。把这层逻辑放在明细表里让每一行记录都带着question_id才能让系统具备“任何问卷都能存”的扩展能力。代价是查询时需要多一次 JOIN但以问卷系统的数据量级来看这个代价可以忽略不计。2.3 业务模块划分不要把所有代码堆在一个 Controller 里我接手过一些所谓的“快速开发”项目三个 Controller 搞定一切Service 层几乎没有业务SQL 全写在 Mapper 注解里看起来代码量很少但后续每加一个功能都要动老代码。这套问卷系统我把模块拆成五个部分问卷管理模块负责问卷的 CRUD、发布、结束、复制。题目管理模块在问卷下维护题目和选项支持拖拽排序源码里用排序号实现前端可选。答题模块面向参与者包括问卷可见性校验、题目渲染数据获取、答卷提交和校验。统计模块按问卷聚合回收数据计算选项占比、答题人数、平均分评分题型。用户模块这里做了精简采用基于 Session 的简单登录管理员和普通参与者共用一张用户表通过角色字段区分。这五个模块拆完之后每个 Mapper 都只对自己负责的数据表进行操作Controller 层只做参数接收和结果封装Service 层承载具体的业务流程。这样的结构不复杂又给后续扩展留了余地。比如你要加一个“答卷导出 Excel”的功能只需要在统计模块里加一个导出接口完全不用动答题模块的代码。3. 核心功能详解从题目类型设计到数据统计3.1 题目类型的抽象让不同的题型共用一套渲染逻辑问卷调查系统的“灵魂”在于题目类型。你可以把题型抽象成三类基础能力选项型单选、多选、下拉它们本质上都是“从预置选项集合中选一个或多个”区别只在于选择数量和 UI 控件的不同。文本型单项填空、多项填空它们需要用户输入文本校验规则可能是长度限制或正则匹配如邮箱格式。评分型评分题通常是 1~5 星和矩阵题前者的本质是一组单选题后者的本质是多行单选但在界面上要展示成表格。在设计数据库的时候我建议用question_type字段存数字枚举而不是直接存“radio”、“checkbox”这类前端名词。原因是后端关心的是“这个是单选还是多选决定我如何校验答案”前端关心的才是“我该渲染成单选按钮还是复选框”。如果数据库直接存前端名词一旦前端 UI 层改名数据结构就要跟着改耦合度太高。合理的做法是后端用稳定枚举值返回给前端时再做一次映射给出前端认识的类型标识。在实际开发中我定义了一个 Light 枚举类包含单选、多选、下拉、填空、评分、矩阵这几种类型。每种题型至少有两个核心方法一个是“如何校验提交答案”另一个是“如何格式化答案用于存储”。比如单选题提交值必须是题目下某个选项的 ID 且不能重复多选题则是一个数组需要校验数组中的每个元素都是合法选项 ID且不能有重复项。这些校验逻辑放在 Service 层统一处理不要分散在 Controller 里。3.2 答卷提交策略校验、入库与防重复答卷提交是整个系统里最容易出错的地方。我先说一个反例有人把答案数组直接序列化成 JSON 字符串存到一个叫answer_content的字段里然后在统计的时候解析这个 JSON。这么做开发效率确实高但属于“用代码复杂度换取表结构简单度”等数据量上来之后统计分析的效率会非常糟糕而且一旦某个答案的格式变了老数据的解析就可能出错。这套系统的答题模块采用的是“明文结构化存储”策略。参与者提交时后端收到的是[{questionId: 1, optionIds: [2,3]}, {questionId: 2, content: 不错}]这样的结构体Service 层会做以下几步根据questionnaire_id加载问卷校验状态是否为“发布中”校验当前时间是否在开始时间和结束时间之间。加载问卷下的全部题目构建一个MapLong, Question便于后续按题校验。逐题校验提交的答案。比如必填题没有提交值要报错判断题干和题目 ID 是否匹配防止使用者篡改参数提交不存在的题目。通过校验后以“一次提交生成一条总答卷记录 每题答案一条明细记录”的方式批量插入。总答卷记录里存问卷 ID、参与者 ID、提交时间、IP 地址可选明细记录里存题目 ID、题目类型、选项 ID 集合逗号拼接或文本内容。关于“是否匿名”这里有个设计细节如果问卷开启了匿名模式那么总答卷记录里的user_id置空只保留一条由随机字符串生成的标识用于区分“同一份答卷中的多条明细记录”。这样既能做到匿名又能在统计时区分不同的答卷。防重复提交方面我在源码里用了简单的“Session 问卷 ID”标记同一个 Session 对同一份问卷只能提交一次。如果要更严格一些可以改成基于 IP 和问卷 ID 的 Redis 标记但中小型项目用 Session 方案已经足够毕竟问卷系统的并发量不太高。3.3 统计报表用 SQL 聚合而不是在 Java 中循环统计功能最能体现一个开发的 SQL 功底。以“单选题各选项占比”为例最直观的思路是查出所有答卷明细然后在 Java 里循环计数。这个方案在数据量几百条的时候没问题但如果问卷参与人数上万就很容易引发性能问题——你会在内存里维护一个巨大的 List然后循环、分组、计数既浪费内存又拖慢响应速度。正确的思路是让数据库去做聚合。比如统计“题目ID为 123 的单选题各选项被选择的次数”可以用一条类似这样的 SQLSELECT answer_detail.option_value, COUNT(*) AS cnt FROM answer_detail WHERE answer_detail.question_id 123 AND answer_detail.questionnaire_id 456 GROUP BY answer_detail.option_value这里option_value字段存储的是逗号拼接的选项 ID 字符串比如“2,5”。GROUP BY 之后就能得到每个选项组合的计数。对于单选题一个选项 ID 不会出现两次所以直接按它分组是没问题的但对于多选题一份答案里可能同时选了 2 和 5这时候想要“选项 2 被选了多少次”就需要额外的处理。我的做法是给选项表增加一个“编号”的概念在统计时将多选答案的字符串拆开后与选项表关联再按选项 ID 分组。具体可以放在一个自定义 Mapper 方法里写一小段 SQL 来完成。如果要统计评分题的平均分就直接取对应题目明细里的数值字段做 AVG 聚合。统计结果最终封装成一个MapInteger, Long或ListOptionStat对象返回给前端前端用图表库渲染成饼图或条形图。我在本地调试的时候用 5000 份模拟答卷跑过一遍整条统计链路耗时在 200 毫秒以内完全够用。4. 配置、启动与部署从零跑通整个项目4.1 需要准备的环境清单在动手跑这个项目之前先检查一下本机环境。我建议的版本组合如下软件推荐版本说明JDK1.8 或 11SpringBoot 2.7.x 对这两个版本兼容性最好Maven3.6用于依赖下载和项目打包MySQL5.7 或 8.0注意驱动和时区配置差异Navicat / DataGrip任意用于导入 SQL 脚本和查看数据前端开发者工具任意便于调试接口返回结构这里要重点提醒一个容易踩的坑如果你用 MySQL 8.0pom.xml里的mysql-connector-java版本别太老否则会报Public Key Retrieval is not allowed的错误。解决方式是升级驱动版本或者在数据库连接 URL 上加上allowPublicKeyRetrievaltrueuseSSLfalse。4.2 核心配置文件解读application.yml是 SpringBoot 项目的枢纽。我拿这个项目里最关键的几个配置来说server: port: 8080 servlet: context-path: / spring: datasource: url: jdbc:mysql://localhost:3306/survey_system?useUnicodetruecharacterEncodingutf-8useSSLfalseserverTimezoneAsia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8 mybatis-plus: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: id-type: autoserverTimezoneAsia/Shanghai和time-zone: GMT8这两个配置是一对的少一个都可能导致日期时间字段差 8 小时。这个问题我在本地出现过看起来是数据写入时间不对实际上是连接时区没对齐。map-underscore-to-camel-case: true让数据库字段questionnaire_id自动映射为 Java 属性questionnaireId写 Mapper XML 时就不用反复起别名。log-impl: StdOutImpl会在控制台打印 SQL 日志开发阶段建议开着方便排查问题上线前记得改成org.apache.ibatis.logging.nologging.NoLoggingImpl或者删掉避免日志刷屏。4.3 数据初始化一份 SQL 脚本能省多少事源码里附带的sql文件夹下有建库建表脚本包括用户表、问卷表、题目表、选项表、答卷表、答卷明细表以及少量初始数据。我第一次拿到这个项目的时候是直接在 MySQL 里手动建表的结果因为字段类型和 MyBatis Plus 的映射对不上花了不少时间排查。后来我建议的做法是直接导入 SQL 脚本把表结构和初始管理员账号一次性建好。导入之后先确认几件事表前缀是否和 MyBatis Plus 的全局配置一致。如果表名有前缀如t_questionnaire需要在配置里指定table-prefix: t_或者让实体类加TableName(t_questionnaire)注解。检查初始密码的加密方式。如果源码里用的 MD5 加盐确保你的登录逻辑和数据库里存的密文格式一致否则会出现“账号密码都对但登录失败”的诡异问题。确认问卷状态字段的默认值。数据库里建议给status字段加默认值 0并加上注释说明 0 草稿、1 发布、2 结束。这样开发期不容易误操作。4.4 本地启动的完整步骤整个启动流程其实非常标准步骤如下用 Maven 执行clean package或者直接在 IDEA 里Reload All Maven Projects确保所有依赖都下载完毕。本地 MySQL 中创建数据库survey_system设置字符集为utf8mb4导入 SQL 脚本。修改application.yml中的数据库账号密码为你本机的实际配置。启动SurveyApplication.java的主方法。浏览器访问http://localhost:8080用脚本里初始化的管理员账号登录后台。在问卷管理页面创建一份问卷添加几道题单选、多选、填空然后点击“发布”复制答题链接用无痕窗口打开答卷页面完成一次完整答题。第 6 步非常重要我建议每位拿这套源码去改的朋友都完整走一遍“创建问卷→发布→答题→查看统计”的闭环而不是直接改代码。只有先跑通主线流程你才知道哪块是正常的、哪块是你改坏的。我之前带过一位实习生一上来就改数据库字段结果问卷发布后答题页面怎么都渲染不出来最后发现是题目表的question_type字段值枚举对不上。先跑通一遍就是给自己建立一个“正常基线”。5. 前端交互与渲染动态问卷表单是怎么做到的5.1 接口设计和数据协议约定很多朋友在学后端的时候会忽略接口设计但问卷系统的接口设计直接决定了前端渲染的复杂度。在这套系统里问卷答题页面的核心接口就一个根据问卷 ID 获取完整的问卷内容。返回的 JSON 结构大致如下{ code: 200, data: { questionnaireId: 19, title: 2024年度员工满意度调查, description: 本问卷共10题预计耗时2分钟, status: 1, deadline: 2024-12-31 23:59:59, questions: [ { questionId: 101, questionType: 1, required: true, stem: 你所在部门是, options: [ {optionId: 1001, text: 技术部}, {optionId: 1002, text: 市场部} ] } ] } }这个结构的特点是问卷、题目、选项一次性全量返回前端拿到后直接遍历渲染即可。对于题库量最大的问卷这种方式的响应体积也就在几十 KB 左右完全没必要做成分页加载。如果后续问卷题目数量特别多比如超过 100 题再考虑分步加载或者按页加载初期不必过度设计。5.2 动态渲染的关键代码思路前端在拿到数据结构后需要根据questionType字段渲染不同的控件。核心是一个条件判断映射单选题渲染成 radio 组多选题渲染成 checkbox 组下拉题渲染成 select填空题渲染成 input/textarea评分题渲染成一排星形按钮矩阵题渲染成表格。以 Vue 为例大致的渲染逻辑是这样的div v-forquestion in questions :keyquestion.questionId div classquestion-title {{ question.required ? * : }}{{ question.stem }} /div !-- 单选题 -- el-radio-group v-ifquestion.questionType 1 v-modelanswerMap[question.questionId] el-radio v-foropt in question.options :keyopt.optionId :labelopt.optionId{{ opt.text }}/el-radio /el-radio-group !-- 多选题 -- el-checkbox-group v-else-ifquestion.questionType 2 v-modelanswerMap[question.questionId] el-checkbox v-foropt in question.options :keyopt.optionId :labelopt.optionId{{ opt.text }}/el-checkbox /el-checkbox-group !-- 下拉题 -- el-select v-else-ifquestion.questionType 3 v-modelanswerMap[question.questionId] el-option v-foropt in question.options :keyopt.optionId :labelopt.text :valueopt.optionId/el-option /el-select !-- 填空题 -- el-input v-else-ifquestion.questionType 4 v-modelanswerMap[question.questionId] typetextarea placeholder请输入你的答案/el-input /div提交时前端的answerMap已经是一个“题目 ID → 答案”的映射比如{101: 1001, 102: [1003, 1005], 103: 挺好的}。把它转成后端需要的列表格式后 POST 给提交接口即可。这个环节有一个容易被忽略的点填空题如果用户什么都没填但题目标了必填后端一定要再次校验不能只依赖前端。因为前端校验被绕过实在太容易了这是安全性的基本功。5.3 后端 XSS 防护和参数合法性校验问卷系统允许用户输入文本那就必然要考虑 XSS跨站脚本攻击。如果有人在填空题里输入一段scriptalert(xss)/script不处理的话这段内容很可能在管理员查看答卷时被浏览器执行。虽然答题入口是内部的但这种教育成本很低的问题没必要赌。我的建议是分两层处理后端入库前对文本类字段做 HTML 标签过滤把和转义为lt;和gt;。前端显示时使用 Vue/React 默认的文本插值而不是v-html来渲染用户提交的内容。这一步是最重要的只要不用v-html渲染用户输入XSS 的风险就会大幅降低。参数合法性校验方面除了前面提到的题目 ID 和选项 ID 匹配之外还要注意文本型答案的长度限制比如单题答案不能超过 500 字。评分题的范围限制必须是 1 到 5 之间的整数。邮箱题如果有要校验邮箱格式。这些校验写起来不复杂但要养成习惯。别觉得“内部系统不用管安全”等到有人拿着你系统的链接刷问卷、灌垃圾数据的时候再回头补这些校验就晚了。6. 统计模块实战数据可视化与导出6.1 统计页面的数据和图表对接问卷管理的后台通常会有一个“查看统计”的入口。点击之后页面会展示这个问卷的回收概况总答卷数、有效答卷数、各题作答率即有多少人答了这道题以及每个选项的选择人数和占比。统计接口的设计思路是按问卷聚合{ questionnaireId: 19, totalCount: 1280, questionStats: [ { questionId: 101, stem: 你所在部门是, type: 1, answerCount: 1275, optionStats: [ {optionId: 1001, text: 技术部, count: 520, rate: 40.8}, {optionId: 1002, text: 市场部, count: 755, rate: 59.2} ] } ] }前端拿到这个结构后用 ECharts 画饼图或者条形图非常直接。一个值得推荐的小技巧是不要在前端计算占比让后端直接返回 rate 字段。这样前端做展示更简单同时后端可以在取数时统一处理精度和格式化逻辑避免不同页面算出来的比例对不上。6.2 统计性能优化索引、缓存、异步导出问卷系统在统计层面的数据量通常不会大到需要引入 Elasticsearch但有几条优化策略是很实用的第一给外键字段建索引。answer_detail表的questionnaire_id和question_id字段在多表 JOIN 时是高频过滤条件建立普通索引就能大幅度加快 GROUP BY 和 WHERE 的查询效率。我建议在初始化 SQL 脚本里就加上这层索引而不是等数据量大了再补。第二统计接口开启 Spring Cache 缓存。同一份问卷在短时间内被多次查看统计结果其实是一样的。用Cacheable注解把统计结果缓存 5 分钟能显著降低数据库压力。注意问卷一旦有新答卷提交需要主动调用CacheEvict清掉对应问卷的缓存否则统计结果会一直不变。第三Excel 导出采用异步生成。当后台需要导出全部答卷明细时同步导出可能会导致请求超时。更好的做法是提交导出任务后返回一个任务 ID后台线程生成 Excel 文件再通过前端轮询或 WebSocket 通知下载完成。这一步在初期可以不做但如果你的系统面向的问卷经常有几千人参与导出功能几乎是必须的。6.3 一道题教会你多选题统计的拆分逻辑多选题的统计是新手最容易懵的地方。假设一道题有 5 个选项用户选了“A、C”我们在answer_detail.option_value字段里存储的是1,3。现在想统计“选项 AID1被选了多少次”如果用GROUP BY option_value只能统计出“同时选 A 和 C 的人有多少”得不出“选 A 的人有多少”。拆分的方式有几种。一种是在 Java 中循环读取后再统计适合数据量小的场景另一种是直接在 SQL 层面用FIND_IN_SET或LIKE处理比如SELECT COUNT(*) FROM answer_detail WHERE question_id 102 AND FIND_IN_SET(1, option_value) 0如果统计所有选项的分布可以用一条 JOIN 把选项表和答题明细表按 FIND_IN_SET 关联起来再分组计数。不过需要留意的是FIND_IN_SET写法简单但当数据量很大时无法走索引。所以在实际项目中我更推荐“冗余统计表”的策略每次答卷提交后异步更新一张question_option_stat统计表每个问卷、每个题目、每个选项一行直接累加计数。这样统计接口永远只查这张小表性能又快又稳定代价仅仅是提交时多一点更新开销。对于中小型问卷系统这是性价比最高的方案。7. 常见问题排查与避坑实录7.1 问题速查表这套系统在开发和部署过程中有几类问题出现的频率特别高我整理了一个速查表方便你直接定位现象可能原因解决方案启动时报Unknown database还没有创建数据库或库名拼写错误在 MySQL 中执行CREATE DATABASE survey_system DEFAULT CHARACTER SET utf8mb4;登录失败账号密码正确但进不去密码加密方式和数据库密文不一致检查登录 Service 中使用的加密算法MD5/SHA与初始数据的密文格式对齐问卷发布后答题页 404问卷状态字段未设置为“发布”或接口路径错误确认status1并检查后端 Controller 的RequestMapping路径时间字段差 8 小时数据库连接 URL 缺少时区配置在url中加入serverTimezoneAsia/Shanghai统计接口响应很慢没有对questionnaire_id建索引给answer_detail表的questionnaire_id字段添加普通索引提交答卷后提示参数错误题型枚举值和实际不符检查前端渲染用的题型映射和后端枚举定义保持一致多选答案统计不准没有处理多选拆分改用“统计表冗余”或FIND_IN_SET拆分逻辑7.2 踩过的坑从一个拼接 SQL 导致的 Bug 说起有一次我在统计模块里为了省事直接拼接了选项 ID 的字符串去查询数据库结果某个选项 ID 是两位数时LIKE %1%把 ID 为 11、21 的选项也匹配进去了统计结果直接翻倍。从那以后我给自己定了一条规矩能用参数化的写法和FIND_IN_SET就不要用字符串 LIKE 匹配数字 ID。这条原则不只适用于问卷系统任何涉及 ID 过滤的场景都一样数据格式规范化永远比“写起来快”更重要。还有个常见的坑是在“复制问卷”功能上。很多系统支持一键复制已有问卷实现时如果只是把问卷表记录复制一份而忘记同时复制题目和选项就会出现“问卷存在但打开编辑时一片空白”的诡异问题。正确做法是在事务里完成三步复制问卷主记录遍历原问卷下的所有题目为新问卷创建新题目和新选项同时维护好新旧 ID 的映射关系。这个逻辑不难但容易漏。7.3 关于并发提交的思考问卷系统有一个特殊场景同一个用户、同一份问卷在多个标签页同时提交。如果系统不做任何限制就可能产生重复答卷。处理方案我在前面提过 Session Redis 的标记方式但更彻底的做法是在数据库层面加一层唯一约束。比如在总答卷表里增加一个unique_key字段存储user_id questionnaire_id 某次会话的随机标识在数据库层面设置唯一索引。这样即使前端重复提交、后端并发处理数据库最终也只会保留一条有效记录。这个方案比单纯依赖后端逻辑要可靠得多因为它是最后一道物理防线。8. 个人体会与几点额外建议回到这个 SpringBoot 网上问卷调查系统本身我个人的体会是它的代码量不算大但覆盖的知识点非常全面。从 SpringBoot 自动配置到 MyBatis Plus 的 ActiveRecord 模式从 REST 接口设计到前端动态渲染从 SQL 聚合统计到部署排查每一个环节都能在真实项目中找到对应场景。对正处于学习阶段的朋友来说把它“吃透”比急着上手微服务更有价值。最后分享一个小技巧做完这套问卷系统后你可以自己给自己提需求比如“支持删除问卷前二次确认”“支持统计结果导出 PNG”“支持答题进度条”然后逐个实现。这些需求单独看都不难但把它们一个个加进去的过程就是对这套代码最有效的巩固方式。你在动手的过程中会遇到“如何改表结构而不影响老数据”“如何加接口而不破坏原有协议”这些真实问题而这些经验恰恰是只读一遍代码学不到的。希望这篇文章能帮你少走一些弯路。 基于SpringBoot的网上问卷调查系统：从数据库建模到统计报表实战解析
1. 项目概览这个问卷调查系统到底能做什么做技术这么多年我接触过不少“看起来很基础、做起来全是细节”的系统网上问卷调查系统就是其中典型的一个。很多朋友一开始觉得它就是“问卷CRUD 答题页面”真上手之后才发现从题目类型设计、动态表单渲染、答卷校验到统计报表每一环都能踩出不同的坑。这篇文章我想围绕一个基于 SpringBoot 的网上问卷调查系统展开把我从项目设计、数据库建模、核心代码实现到部署排查的完整链路都拆开讲讲顺便把源码里值得关注的部分挑出来逐段说明。这套系统的定位非常明确面向中小规模调研场景比如企业内部员工满意度调查、学校课程评价、产品上线前的用户反馈收集等。它需要支持管理员创建问卷、维护题库、发布问卷、查看回收数据同时还要支持参与者打开链接答题、提交答卷、事后查看结果。从业务复杂度来看它不像电商系统那样有复杂的交易链路也不像后台管理系统那样全是表格和权限配置它真正的难点在于“问卷是一种高度动态的数据结构”——每份问卷的题目数量不同、题型不同、选项不同答卷数据又是一对多关联的这就要求在设计阶段就把数据的灵活性和统计的可用性同时考虑进去。这个项目适合谁来参考呢如果你正在学习 SpringBoot 整合 MyBatis Plus想找一个能覆盖“增删改查 多表关联 数据统计 前端渲染”的完整案例那它很合适。如果你要做毕业设计或者个人作品集那它同样值得一看因为问卷系统的业务闭环非常完整既能体现数据库设计能力也能体现接口设计能力和业务建模能力。我这里会按实际的开发顺序来讲不是那种只贴代码不解释的教程每一步尽量说清楚“为什么这么做”。你哪怕之前没见过问卷系统的代码照着我这个思路也能把整个项目的脉络捋明白。2. 整体设计思路与技术选型背后的考量2.1 为什么用 SpringBoot而不是传统 SSM很多老项目还在用 SpringMVC MyBatis XML 那一套能在里面游刃有余的开发者确实基本功扎实但是新项目再用 SSM 纯属自己给自己上强度。SpringBoot 的价值不在于“功能多”而在于它把那些固定套路全部收敛成了约定内嵌 Tomcat、自动装配数据源、Starter 一键引入依赖再加上application.yml统一管理配置开发阶段只需要关注业务本身。我见过不少朋友纠结“SpringBoot 是不是太傻瓜化了学不到底层原理”这个担心其实没必要——SpringBoot 只是把框架的装配过程自动化了你用到的 Spring IOC、AOP、事务传播机制、MyBatis 映射原理一样不少只是省掉了那堆web.xml和spring-mvc.xml而已。还有一个容易被忽略的点是测试和部署成本。问卷调查系统的迭代速度不慢经常要加题型、加统计口径SpringBoot 的spring-boot-devtools支持热重启配合spring-boot-maven-plugin打包出一个可执行 Jar扔到服务器上java -jar就能跑。对于中小型团队来说这种“低摩擦”的交付方式比传统 SSM 要顺滑得多。另外后续如果要引入 Spring Security 做登录鉴权、引入 Redis 做答题防刷SpringBoot 生态的整合成本也低得多。2.2 数据库建模问卷、题目、选项、答卷的关联设计这一节是整个系统最核心的部分。我见过很多初学者把问卷设计成一张大表题目和选项全塞在 JSON 字段里这么做原型阶段确实爽但到了“统计某道题有多少人选了某个选项”的时候就傻眼了Java 代码里要解析 JSON、要手写聚合逻辑性能差还容易出 bug。所以在这套系统里我采用了一套经典的“四层模型”问卷表questionnaire记录问卷基础信息包括标题、描述、状态草稿/发布/结束、开始时间、结束时间、是否匿名、每日答题次数限制。题目表question通过questionnaire_id关联问卷每个题目包含题型、题干、是否必填、排序号等字段。选项表option通过question_id关联题目用于单选、多选、下拉等题型。填空和评分题没有选项取决于题型标记。答卷结果表answer主要记录用户对某道题目的作答内容选项型题目存选项ID填空型题目存文本内容。这里有一个关键点值得展开考试系统里的答题记录通常用“一次提交一行主记录 明细子表”的方式但问卷系统我不建议套用同一套模型。因为问卷的题目是动态的今天创建的问卷可能只有 5 道题明天创建的问卷可能就有 30 道题如果用固定字段去存每一题的答案表结构就得频繁变更。把这层逻辑放在明细表里让每一行记录都带着question_id才能让系统具备“任何问卷都能存”的扩展能力。代价是查询时需要多一次 JOIN但以问卷系统的数据量级来看这个代价可以忽略不计。2.3 业务模块划分不要把所有代码堆在一个 Controller 里我接手过一些所谓的“快速开发”项目三个 Controller 搞定一切Service 层几乎没有业务SQL 全写在 Mapper 注解里看起来代码量很少但后续每加一个功能都要动老代码。这套问卷系统我把模块拆成五个部分问卷管理模块负责问卷的 CRUD、发布、结束、复制。题目管理模块在问卷下维护题目和选项支持拖拽排序源码里用排序号实现前端可选。答题模块面向参与者包括问卷可见性校验、题目渲染数据获取、答卷提交和校验。统计模块按问卷聚合回收数据计算选项占比、答题人数、平均分评分题型。用户模块这里做了精简采用基于 Session 的简单登录管理员和普通参与者共用一张用户表通过角色字段区分。这五个模块拆完之后每个 Mapper 都只对自己负责的数据表进行操作Controller 层只做参数接收和结果封装Service 层承载具体的业务流程。这样的结构不复杂又给后续扩展留了余地。比如你要加一个“答卷导出 Excel”的功能只需要在统计模块里加一个导出接口完全不用动答题模块的代码。3. 核心功能详解从题目类型设计到数据统计3.1 题目类型的抽象让不同的题型共用一套渲染逻辑问卷调查系统的“灵魂”在于题目类型。你可以把题型抽象成三类基础能力选项型单选、多选、下拉它们本质上都是“从预置选项集合中选一个或多个”区别只在于选择数量和 UI 控件的不同。文本型单项填空、多项填空它们需要用户输入文本校验规则可能是长度限制或正则匹配如邮箱格式。评分型评分题通常是 1~5 星和矩阵题前者的本质是一组单选题后者的本质是多行单选但在界面上要展示成表格。在设计数据库的时候我建议用question_type字段存数字枚举而不是直接存“radio”、“checkbox”这类前端名词。原因是后端关心的是“这个是单选还是多选决定我如何校验答案”前端关心的才是“我该渲染成单选按钮还是复选框”。如果数据库直接存前端名词一旦前端 UI 层改名数据结构就要跟着改耦合度太高。合理的做法是后端用稳定枚举值返回给前端时再做一次映射给出前端认识的类型标识。在实际开发中我定义了一个 Light 枚举类包含单选、多选、下拉、填空、评分、矩阵这几种类型。每种题型至少有两个核心方法一个是“如何校验提交答案”另一个是“如何格式化答案用于存储”。比如单选题提交值必须是题目下某个选项的 ID 且不能重复多选题则是一个数组需要校验数组中的每个元素都是合法选项 ID且不能有重复项。这些校验逻辑放在 Service 层统一处理不要分散在 Controller 里。3.2 答卷提交策略校验、入库与防重复答卷提交是整个系统里最容易出错的地方。我先说一个反例有人把答案数组直接序列化成 JSON 字符串存到一个叫answer_content的字段里然后在统计的时候解析这个 JSON。这么做开发效率确实高但属于“用代码复杂度换取表结构简单度”等数据量上来之后统计分析的效率会非常糟糕而且一旦某个答案的格式变了老数据的解析就可能出错。这套系统的答题模块采用的是“明文结构化存储”策略。参与者提交时后端收到的是[{questionId: 1, optionIds: [2,3]}, {questionId: 2, content: 不错}]这样的结构体Service 层会做以下几步根据questionnaire_id加载问卷校验状态是否为“发布中”校验当前时间是否在开始时间和结束时间之间。加载问卷下的全部题目构建一个MapLong, Question便于后续按题校验。逐题校验提交的答案。比如必填题没有提交值要报错判断题干和题目 ID 是否匹配防止使用者篡改参数提交不存在的题目。通过校验后以“一次提交生成一条总答卷记录 每题答案一条明细记录”的方式批量插入。总答卷记录里存问卷 ID、参与者 ID、提交时间、IP 地址可选明细记录里存题目 ID、题目类型、选项 ID 集合逗号拼接或文本内容。关于“是否匿名”这里有个设计细节如果问卷开启了匿名模式那么总答卷记录里的user_id置空只保留一条由随机字符串生成的标识用于区分“同一份答卷中的多条明细记录”。这样既能做到匿名又能在统计时区分不同的答卷。防重复提交方面我在源码里用了简单的“Session 问卷 ID”标记同一个 Session 对同一份问卷只能提交一次。如果要更严格一些可以改成基于 IP 和问卷 ID 的 Redis 标记但中小型项目用 Session 方案已经足够毕竟问卷系统的并发量不太高。3.3 统计报表用 SQL 聚合而不是在 Java 中循环统计功能最能体现一个开发的 SQL 功底。以“单选题各选项占比”为例最直观的思路是查出所有答卷明细然后在 Java 里循环计数。这个方案在数据量几百条的时候没问题但如果问卷参与人数上万就很容易引发性能问题——你会在内存里维护一个巨大的 List然后循环、分组、计数既浪费内存又拖慢响应速度。正确的思路是让数据库去做聚合。比如统计“题目ID为 123 的单选题各选项被选择的次数”可以用一条类似这样的 SQLSELECT answer_detail.option_value, COUNT(*) AS cnt FROM answer_detail WHERE answer_detail.question_id 123 AND answer_detail.questionnaire_id 456 GROUP BY answer_detail.option_value这里option_value字段存储的是逗号拼接的选项 ID 字符串比如“2,5”。GROUP BY 之后就能得到每个选项组合的计数。对于单选题一个选项 ID 不会出现两次所以直接按它分组是没问题的但对于多选题一份答案里可能同时选了 2 和 5这时候想要“选项 2 被选了多少次”就需要额外的处理。我的做法是给选项表增加一个“编号”的概念在统计时将多选答案的字符串拆开后与选项表关联再按选项 ID 分组。具体可以放在一个自定义 Mapper 方法里写一小段 SQL 来完成。如果要统计评分题的平均分就直接取对应题目明细里的数值字段做 AVG 聚合。统计结果最终封装成一个MapInteger, Long或ListOptionStat对象返回给前端前端用图表库渲染成饼图或条形图。我在本地调试的时候用 5000 份模拟答卷跑过一遍整条统计链路耗时在 200 毫秒以内完全够用。4. 配置、启动与部署从零跑通整个项目4.1 需要准备的环境清单在动手跑这个项目之前先检查一下本机环境。我建议的版本组合如下软件推荐版本说明JDK1.8 或 11SpringBoot 2.7.x 对这两个版本兼容性最好Maven3.6用于依赖下载和项目打包MySQL5.7 或 8.0注意驱动和时区配置差异Navicat / DataGrip任意用于导入 SQL 脚本和查看数据前端开发者工具任意便于调试接口返回结构这里要重点提醒一个容易踩的坑如果你用 MySQL 8.0pom.xml里的mysql-connector-java版本别太老否则会报Public Key Retrieval is not allowed的错误。解决方式是升级驱动版本或者在数据库连接 URL 上加上allowPublicKeyRetrievaltrueuseSSLfalse。4.2 核心配置文件解读application.yml是 SpringBoot 项目的枢纽。我拿这个项目里最关键的几个配置来说server: port: 8080 servlet: context-path: / spring: datasource: url: jdbc:mysql://localhost:3306/survey_system?useUnicodetruecharacterEncodingutf-8useSSLfalseserverTimezoneAsia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8 mybatis-plus: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: id-type: autoserverTimezoneAsia/Shanghai和time-zone: GMT8这两个配置是一对的少一个都可能导致日期时间字段差 8 小时。这个问题我在本地出现过看起来是数据写入时间不对实际上是连接时区没对齐。map-underscore-to-camel-case: true让数据库字段questionnaire_id自动映射为 Java 属性questionnaireId写 Mapper XML 时就不用反复起别名。log-impl: StdOutImpl会在控制台打印 SQL 日志开发阶段建议开着方便排查问题上线前记得改成org.apache.ibatis.logging.nologging.NoLoggingImpl或者删掉避免日志刷屏。4.3 数据初始化一份 SQL 脚本能省多少事源码里附带的sql文件夹下有建库建表脚本包括用户表、问卷表、题目表、选项表、答卷表、答卷明细表以及少量初始数据。我第一次拿到这个项目的时候是直接在 MySQL 里手动建表的结果因为字段类型和 MyBatis Plus 的映射对不上花了不少时间排查。后来我建议的做法是直接导入 SQL 脚本把表结构和初始管理员账号一次性建好。导入之后先确认几件事表前缀是否和 MyBatis Plus 的全局配置一致。如果表名有前缀如t_questionnaire需要在配置里指定table-prefix: t_或者让实体类加TableName(t_questionnaire)注解。检查初始密码的加密方式。如果源码里用的 MD5 加盐确保你的登录逻辑和数据库里存的密文格式一致否则会出现“账号密码都对但登录失败”的诡异问题。确认问卷状态字段的默认值。数据库里建议给status字段加默认值 0并加上注释说明 0 草稿、1 发布、2 结束。这样开发期不容易误操作。4.4 本地启动的完整步骤整个启动流程其实非常标准步骤如下用 Maven 执行clean package或者直接在 IDEA 里Reload All Maven Projects确保所有依赖都下载完毕。本地 MySQL 中创建数据库survey_system设置字符集为utf8mb4导入 SQL 脚本。修改application.yml中的数据库账号密码为你本机的实际配置。启动SurveyApplication.java的主方法。浏览器访问http://localhost:8080用脚本里初始化的管理员账号登录后台。在问卷管理页面创建一份问卷添加几道题单选、多选、填空然后点击“发布”复制答题链接用无痕窗口打开答卷页面完成一次完整答题。第 6 步非常重要我建议每位拿这套源码去改的朋友都完整走一遍“创建问卷→发布→答题→查看统计”的闭环而不是直接改代码。只有先跑通主线流程你才知道哪块是正常的、哪块是你改坏的。我之前带过一位实习生一上来就改数据库字段结果问卷发布后答题页面怎么都渲染不出来最后发现是题目表的question_type字段值枚举对不上。先跑通一遍就是给自己建立一个“正常基线”。5. 前端交互与渲染动态问卷表单是怎么做到的5.1 接口设计和数据协议约定很多朋友在学后端的时候会忽略接口设计但问卷系统的接口设计直接决定了前端渲染的复杂度。在这套系统里问卷答题页面的核心接口就一个根据问卷 ID 获取完整的问卷内容。返回的 JSON 结构大致如下{ code: 200, data: { questionnaireId: 19, title: 2024年度员工满意度调查, description: 本问卷共10题预计耗时2分钟, status: 1, deadline: 2024-12-31 23:59:59, questions: [ { questionId: 101, questionType: 1, required: true, stem: 你所在部门是, options: [ {optionId: 1001, text: 技术部}, {optionId: 1002, text: 市场部} ] } ] } }这个结构的特点是问卷、题目、选项一次性全量返回前端拿到后直接遍历渲染即可。对于题库量最大的问卷这种方式的响应体积也就在几十 KB 左右完全没必要做成分页加载。如果后续问卷题目数量特别多比如超过 100 题再考虑分步加载或者按页加载初期不必过度设计。5.2 动态渲染的关键代码思路前端在拿到数据结构后需要根据questionType字段渲染不同的控件。核心是一个条件判断映射单选题渲染成 radio 组多选题渲染成 checkbox 组下拉题渲染成 select填空题渲染成 input/textarea评分题渲染成一排星形按钮矩阵题渲染成表格。以 Vue 为例大致的渲染逻辑是这样的div v-forquestion in questions :keyquestion.questionId div classquestion-title {{ question.required ? * : }}{{ question.stem }} /div !-- 单选题 -- el-radio-group v-ifquestion.questionType 1 v-modelanswerMap[question.questionId] el-radio v-foropt in question.options :keyopt.optionId :labelopt.optionId{{ opt.text }}/el-radio /el-radio-group !-- 多选题 -- el-checkbox-group v-else-ifquestion.questionType 2 v-modelanswerMap[question.questionId] el-checkbox v-foropt in question.options :keyopt.optionId :labelopt.optionId{{ opt.text }}/el-checkbox /el-checkbox-group !-- 下拉题 -- el-select v-else-ifquestion.questionType 3 v-modelanswerMap[question.questionId] el-option v-foropt in question.options :keyopt.optionId :labelopt.text :valueopt.optionId/el-option /el-select !-- 填空题 -- el-input v-else-ifquestion.questionType 4 v-modelanswerMap[question.questionId] typetextarea placeholder请输入你的答案/el-input /div提交时前端的answerMap已经是一个“题目 ID → 答案”的映射比如{101: 1001, 102: [1003, 1005], 103: 挺好的}。把它转成后端需要的列表格式后 POST 给提交接口即可。这个环节有一个容易被忽略的点填空题如果用户什么都没填但题目标了必填后端一定要再次校验不能只依赖前端。因为前端校验被绕过实在太容易了这是安全性的基本功。5.3 后端 XSS 防护和参数合法性校验问卷系统允许用户输入文本那就必然要考虑 XSS跨站脚本攻击。如果有人在填空题里输入一段scriptalert(xss)/script不处理的话这段内容很可能在管理员查看答卷时被浏览器执行。虽然答题入口是内部的但这种教育成本很低的问题没必要赌。我的建议是分两层处理后端入库前对文本类字段做 HTML 标签过滤把和转义为lt;和gt;。前端显示时使用 Vue/React 默认的文本插值而不是v-html来渲染用户提交的内容。这一步是最重要的只要不用v-html渲染用户输入XSS 的风险就会大幅降低。参数合法性校验方面除了前面提到的题目 ID 和选项 ID 匹配之外还要注意文本型答案的长度限制比如单题答案不能超过 500 字。评分题的范围限制必须是 1 到 5 之间的整数。邮箱题如果有要校验邮箱格式。这些校验写起来不复杂但要养成习惯。别觉得“内部系统不用管安全”等到有人拿着你系统的链接刷问卷、灌垃圾数据的时候再回头补这些校验就晚了。6. 统计模块实战数据可视化与导出6.1 统计页面的数据和图表对接问卷管理的后台通常会有一个“查看统计”的入口。点击之后页面会展示这个问卷的回收概况总答卷数、有效答卷数、各题作答率即有多少人答了这道题以及每个选项的选择人数和占比。统计接口的设计思路是按问卷聚合{ questionnaireId: 19, totalCount: 1280, questionStats: [ { questionId: 101, stem: 你所在部门是, type: 1, answerCount: 1275, optionStats: [ {optionId: 1001, text: 技术部, count: 520, rate: 40.8}, {optionId: 1002, text: 市场部, count: 755, rate: 59.2} ] } ] }前端拿到这个结构后用 ECharts 画饼图或者条形图非常直接。一个值得推荐的小技巧是不要在前端计算占比让后端直接返回 rate 字段。这样前端做展示更简单同时后端可以在取数时统一处理精度和格式化逻辑避免不同页面算出来的比例对不上。6.2 统计性能优化索引、缓存、异步导出问卷系统在统计层面的数据量通常不会大到需要引入 Elasticsearch但有几条优化策略是很实用的第一给外键字段建索引。answer_detail表的questionnaire_id和question_id字段在多表 JOIN 时是高频过滤条件建立普通索引就能大幅度加快 GROUP BY 和 WHERE 的查询效率。我建议在初始化 SQL 脚本里就加上这层索引而不是等数据量大了再补。第二统计接口开启 Spring Cache 缓存。同一份问卷在短时间内被多次查看统计结果其实是一样的。用Cacheable注解把统计结果缓存 5 分钟能显著降低数据库压力。注意问卷一旦有新答卷提交需要主动调用CacheEvict清掉对应问卷的缓存否则统计结果会一直不变。第三Excel 导出采用异步生成。当后台需要导出全部答卷明细时同步导出可能会导致请求超时。更好的做法是提交导出任务后返回一个任务 ID后台线程生成 Excel 文件再通过前端轮询或 WebSocket 通知下载完成。这一步在初期可以不做但如果你的系统面向的问卷经常有几千人参与导出功能几乎是必须的。6.3 一道题教会你多选题统计的拆分逻辑多选题的统计是新手最容易懵的地方。假设一道题有 5 个选项用户选了“A、C”我们在answer_detail.option_value字段里存储的是1,3。现在想统计“选项 AID1被选了多少次”如果用GROUP BY option_value只能统计出“同时选 A 和 C 的人有多少”得不出“选 A 的人有多少”。拆分的方式有几种。一种是在 Java 中循环读取后再统计适合数据量小的场景另一种是直接在 SQL 层面用FIND_IN_SET或LIKE处理比如SELECT COUNT(*) FROM answer_detail WHERE question_id 102 AND FIND_IN_SET(1, option_value) 0如果统计所有选项的分布可以用一条 JOIN 把选项表和答题明细表按 FIND_IN_SET 关联起来再分组计数。不过需要留意的是FIND_IN_SET写法简单但当数据量很大时无法走索引。所以在实际项目中我更推荐“冗余统计表”的策略每次答卷提交后异步更新一张question_option_stat统计表每个问卷、每个题目、每个选项一行直接累加计数。这样统计接口永远只查这张小表性能又快又稳定代价仅仅是提交时多一点更新开销。对于中小型问卷系统这是性价比最高的方案。7. 常见问题排查与避坑实录7.1 问题速查表这套系统在开发和部署过程中有几类问题出现的频率特别高我整理了一个速查表方便你直接定位现象可能原因解决方案启动时报Unknown database还没有创建数据库或库名拼写错误在 MySQL 中执行CREATE DATABASE survey_system DEFAULT CHARACTER SET utf8mb4;登录失败账号密码正确但进不去密码加密方式和数据库密文不一致检查登录 Service 中使用的加密算法MD5/SHA与初始数据的密文格式对齐问卷发布后答题页 404问卷状态字段未设置为“发布”或接口路径错误确认status1并检查后端 Controller 的RequestMapping路径时间字段差 8 小时数据库连接 URL 缺少时区配置在url中加入serverTimezoneAsia/Shanghai统计接口响应很慢没有对questionnaire_id建索引给answer_detail表的questionnaire_id字段添加普通索引提交答卷后提示参数错误题型枚举值和实际不符检查前端渲染用的题型映射和后端枚举定义保持一致多选答案统计不准没有处理多选拆分改用“统计表冗余”或FIND_IN_SET拆分逻辑7.2 踩过的坑从一个拼接 SQL 导致的 Bug 说起有一次我在统计模块里为了省事直接拼接了选项 ID 的字符串去查询数据库结果某个选项 ID 是两位数时LIKE %1%把 ID 为 11、21 的选项也匹配进去了统计结果直接翻倍。从那以后我给自己定了一条规矩能用参数化的写法和FIND_IN_SET就不要用字符串 LIKE 匹配数字 ID。这条原则不只适用于问卷系统任何涉及 ID 过滤的场景都一样数据格式规范化永远比“写起来快”更重要。还有个常见的坑是在“复制问卷”功能上。很多系统支持一键复制已有问卷实现时如果只是把问卷表记录复制一份而忘记同时复制题目和选项就会出现“问卷存在但打开编辑时一片空白”的诡异问题。正确做法是在事务里完成三步复制问卷主记录遍历原问卷下的所有题目为新问卷创建新题目和新选项同时维护好新旧 ID 的映射关系。这个逻辑不难但容易漏。7.3 关于并发提交的思考问卷系统有一个特殊场景同一个用户、同一份问卷在多个标签页同时提交。如果系统不做任何限制就可能产生重复答卷。处理方案我在前面提过 Session Redis 的标记方式但更彻底的做法是在数据库层面加一层唯一约束。比如在总答卷表里增加一个unique_key字段存储user_id questionnaire_id 某次会话的随机标识在数据库层面设置唯一索引。这样即使前端重复提交、后端并发处理数据库最终也只会保留一条有效记录。这个方案比单纯依赖后端逻辑要可靠得多因为它是最后一道物理防线。8. 个人体会与几点额外建议回到这个 SpringBoot 网上问卷调查系统本身我个人的体会是它的代码量不算大但覆盖的知识点非常全面。从 SpringBoot 自动配置到 MyBatis Plus 的 ActiveRecord 模式从 REST 接口设计到前端动态渲染从 SQL 聚合统计到部署排查每一个环节都能在真实项目中找到对应场景。对正处于学习阶段的朋友来说把它“吃透”比急着上手微服务更有价值。最后分享一个小技巧做完这套问卷系统后你可以自己给自己提需求比如“支持删除问卷前二次确认”“支持统计结果导出 PNG”“支持答题进度条”然后逐个实现。这些需求单独看都不难但把它们一个个加进去的过程就是对这套代码最有效的巩固方式。你在动手的过程中会遇到“如何改表结构而不影响老数据”“如何加接口而不破坏原有协议”这些真实问题而这些经验恰恰是只读一遍代码学不到的。希望这篇文章能帮你少走一些弯路。