SpringBoot调查问卷系统实战：从数据库设计到Docker部署全解析

拿SpringBoot做一套调查问卷系统，听起来是标准的CRUD模板题，真正动手做才发现，坑全藏在“问卷”这两个字里：题型五花八门、答卷防重、统计分析、定时回收，哪一环单拎出来都够写一篇长文。这篇文章我想从一个已经落地的SpringBoot调查问卷系统出发，把从需求拆解到部署上线的完整链路捋一遍，适合准备用SpringBoot从零搭建问卷、表单类系统的开发者，也适合已经做了一半、想看看别人怎么处理防重复提交、统计和部署这些坑的朋友。

1. 为什么是SpringBoot：先盘一份被低估的需求清单

1.1 问卷系统到底在做哪些事

很多人对问卷系统的第一印象是“不就是维护几个表和两个页面”，实际上问卷类业务的核心复杂度在于状态和数据的组合。

管理端至少要支持：问卷模板的创建与编辑，题型覆盖单选、多选、填空、评分、矩阵、排序；问卷的发布、回收、归档；对已回收答卷的明细查看、按条件筛选、Excel导出；按题目做汇总统计和交叉分析。用户端则要面对：问卷填写、防重复提交、在时间窗口内作答、填写中途断网后的恢复、提交后回执展示等。

这还没算权限管理。管理员、编辑员、普通用户看到的问卷范围不一样，问卷本身还有分类、复制、版本更新这类在需求评审里经常被一笔带过、写代码时却绕不开的琐碎功能。

把这些需求摊开，你会发现问题主要集中在三块：第一，问卷模板的数据结构如何设计，才能应对多样题型和后续修改；第二，答卷数据怎么存储，才能兼顾明细查询和统计性能；第三，一套可靠的状态机如何管理从草稿到归档的整个生命周期。这三块恰好都是SpringBoot生态里很成熟、但没人替你封装好的领域逻辑。

1.2 我用的技术栈与选型理由

我的方案是前后端分离：后端SpringBoot，前端Vue3加Element Plus，数据库MySQL 8.0，缓存和分布式锁用Redis，持久层用MyBatis-Plus。整套配置如下：

很多新人上来就追SpringBoot 3.x，我的建议是：除非你已经很熟悉JDK17的模块化生态，否则2.7.x在问卷调查这类中小型系统里是更稳的选择。3.x把javax包迁移到了jakarta，很多老依赖、老教程、老配置片段直接失效，排查成本远高于它带来的性能收益。

持久层为什么选MyBatis-Plus而不是Spring Data JPA，这也是实际对比后的结论：问卷系统的统计查询基本都是动态条件，按题型、选项、时间范围、答题人属性各种组合过滤，MyBatis-Plus的QueryWrapper和自定义XML能把这类组合查询写得很直接；JPA在这类场景下虽然也能做，但动态规格的代码量和调试成本都要高一些。

2. 数据库建模：一对多关系的边界与冗余字段的取舍

2.1 五张核心表的设计思路

问卷系统的数据模型，核心是“问卷—题目—选项—答卷”这条链。我这里没有引入过多抽象，就是五张表再加一张可选分类表，字段设计务必让后续统计查询简单直接。

• questionnaire：问卷主表，存标题、描述、状态、开始时间、结束时间、创建人、访问码。
• question：题目表，存所属问卷、题型、题干、是否必答、排序号。
• question_option：选项表，存题目ID、选项文本、排序号、附加分值。
• answer_record：答卷主表，存问卷ID、答题人标识、开始时间、提交时间、IP、耗时。
• answer_detail：答卷明细表，存每条答卷的每道题作答内容。

题目表里有个关键字段只用了int类型标识，0代表单选、1代表多选、2代表填空、3代表评分、4代表矩阵，而不是直接存字符串。后续所有枚举转换都在后端统一管理，避免前端传值或Excel导出时出现“答案类型对不上”的脏数据。选项表里我额外加了一个score字段，用于打分题和加权统计，这个字段一开始没设计，后来补上去之后为了历史数据兼容费了不少劲。

answer_detail表是这套模型里最容易写错的地方。我的做法是：一个答卷中的一道题对应一行记录，单选和多选统一把选项ID存进option_ids字段，多个选项用英文逗号分隔；填空或文本题存text_answer字段。这样批量插入很快，行数也少，统计时配合FIND_IN_SET或LIKE处理多选，在小数据量下完全够用。

2.2 为什么不用JSON一把梭存问卷

有一种很诱人的设计：把整个问卷模板包括题目、选项、甚至逻辑跳转全部存成一个JSON字段，答卷也整体存成JSON。开发时确实爽，增删题目不用动表结构，改版也简单。

但它有两个致命问题。第一是统计性能：要分析某道单选各选项的占比，规范化存储直接GROUP BY就能秒出，JSON存储则要把所有答卷拉到应用内存里解析一遍，问卷数据量上万之后，这个操作会让接口卡到怀疑人生。第二是修改成本：如果题目结构变化，JSON里旧数据和新数据完全不在一个schema里，代码里到处都要写兼容分支。

我的建议是：如果这套系统只做“收集”而不做“分析”，JSON方案完全可行；但只要涉及按题目、选项维度的统计，就老老实实拆表。规范化之后的查询、联表、加索引、写汇总表都有明确路径，团队协作时也让后续接手的人少踩坑。

2.3 被很多人忽略的字段细节

这套模型里我有四个字段是强制约定的：version做乐观锁，deleted做逻辑删除，create_time和update_time用MyBatis-Plus的自动填充统一搞定。问卷状态流转和答卷提交涉及并发更新，乐观锁字段是必需品；逻辑删除则保证管理后台能恢复误删的问卷。

自动填充这块，定义一个MetaObjectHandler实现类：

@Component public class MyMetaObjectHandler implements MetaObjectHandler { @Override public void insertFill(MetaObject metaObject) { this.strictInsertFill(metaObject, "createTime", LocalDateTime.class, LocalDateTime.now()); this.strictInsertFill(metaObject, "updateTime", LocalDateTime.class, LocalDateTime.now()); } @Override public void updateFill(MetaObject metaObject) { this.strictUpdateFill(metaObject, "updateTime", LocalDateTime.class, LocalDateTime.now()); } }

实体类里对应字段加上@TableField(fill = FieldFill.INSERT)和@TableField(fill = FieldFill.INSERT_UPDATE)，之后所有插入和更新操作都不用手动维护时间。这个细节看起来小，但问卷榜单页、统计报表页几乎都要按时间排序，时间字段的可靠性直接影响所有下游功能。

还有排序号sort_order，虽然可以用question表的主键递增来凑合，但问卷编辑页里“上移、下移、拖拽排序”是标配功能，没有单独的排序字段，做起来会非常别扭。我所有排序字段都是int类型，预留了步长100，避免频繁重排时大量更新语句。

3. 核心接口链路：从创建问卷到回收答卷

3.1 问卷发布的状态机与题目锁定逻辑

问卷有个生命周期，我定义成四个状态：0草稿、1已发布、2已回收、3已归档。状态流转只有三条合法路径：草稿到发布、发布到回收、回收到归档。任何跨状态跳跃都在Service层拦掉。

状态机的实现看起来简单，真正容易出错的是“发布后题目锁定”的规则。我的处理是：问卷处于草稿状态时可以编辑题目和选项；一旦发布，原题内容就不允许修改了，只允许停用某道题或增加新题目。这是为了保证统计口径稳定——如果已经有1000份答卷，你中途改了单选题的选项文本，那这1000份数据在新旧口径下都无法对齐。

发布接口的伪逻辑大致是：

@Transactional public Long publish(Long id) { SurveyQuestionnaire questionnaire = getById(id); if (questionnaire.getStatus() != STATUS_DRAFT) { throw new BusinessException("只有草稿状态才能发布"); } if (questionnaire.getQuestionCount() == null || questionnaire.getQuestionCount() < 1) { throw new BusinessException("问卷至少要包含一道题目"); } if (questionnaire.getEndTime().isBefore(LocalDateTime.now())) { throw new BusinessException("结束时间必须晚于当前时间"); } // 生成访问码，设置发布时间 questionnaire.setStatus(STATUS_PUBLISHED); questionnaire.setAccessCode(generateAccessCode()); updateById(questionnaire); // 清理缓存中的旧模板 redisTemplate.delete("survey:template:" + id); return id; }

发布之后，用户端拿到的是带访问码的短链接，后端根据访问码找到问卷并返回完整模板。访问码我用6位随机字符串，冲突概率很低，加上唯一索引兜底，生成时一旦碰撞就重新生成。

3.2 答卷提交：防重复、并发与事务一致性

答卷提交是整个系统里并发压力最集中的地方。我的实现思路分四步：校验问卷状态、校验时间窗口、防重复提交、批量插入。

防重复提交是这里最关键的一步。登录用户可以直接用userId做标识，匿名问卷则对IP加UserAgent做哈希来标识。我用Redis分布式锁加数据库唯一索引双保险，核心代码如下：

public SubmitResult submit(SurveySubmitDTO dto) { String lockKey = "survey:submit:" + dto.getQuestionnaireId() + ":" + dto.getUserKey(); boolean locked = stringRedisTemplate.opsForValue() .setIfAbsent(lockKey, "1", Duration.ofSeconds(30)); if (!locked) { throw new BusinessException("正在提交中，请勿重复操作"); } try { SurveyQuestionnaire questionnaire = getPublishedQuestionnaire(dto.getQuestionnaireId()); if (questionnaire.getStatus() != STATUS_PUBLISHED) { throw new BusinessException("问卷不在可填写状态"); } LocalDateTime now = LocalDateTime.now(); if (now.isBefore(questionnaire.getStartTime()) || now.isAfter(questionnaire.getEndTime())) { throw new BusinessException("不在问卷开放时间范围内"); } // 数据库唯一索引再次兜底 saveAnswerRecordAndDetails(dto); } finally { stringRedisTemplate.delete(lockKey); } return SubmitResult.success(); }

数据库层面，answer_record表建一个(questionnaire_id, user_key)的唯一索引。Redis锁防的是瞬时并发，唯一索引防的是极端情况下锁过期后仍然重复插入。两道防线缺一不可。

这里还有个事务边界的教训：saveAnswerRecordAndDetails方法里不要调用任何外部接口，更不要做文本分词这类耗时操作。我踩过一次坑，在事务里做了敏感词检查调用，单次耗时多了几百毫秒，高峰期拖垮了数据库连接池。正确做法是先把答卷完整落库，再异步处理其他逻辑。

批量插入明细时，我用MyBatis-Plus的批量插入，每批200条左右。一道问卷动辄三四十题，一次提交可能要插几十行明细，使用分批插入能显著降低大事务带来的锁竞争。

3.3 答卷分页查询与Excel导出

管理后台的答卷列表，最常用的场景是按问卷ID、提交时间段、答题人关键字进行分页筛选。这部分的查询条件组合非常灵活，MyBatis-Plus的QueryWrapper能省很多事：

LambdaQueryWrapper<AnswerRecord> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(AnswerRecord::getQuestionnaireId, questionnaireId) .eq(StringUtils.hasText(userKey), AnswerRecord::getUserKey, userKey) .between(startTime != null && endTime != null, AnswerRecord::getSubmitTime, startTime, endTime) .orderByDesc(AnswerRecord::getSubmitTime);

导出Excel我用的EasyExcel，这里最需要注意的是“流式导出”。我早期用一次把全部数据查出再写入Excel的做法，五万份答卷直接内存溢出。改成EasyExcel的WriteHandler之后，数据是游标式一行行写到文件的，内存占用几乎不变。导出文件名里带上问卷标题和日期，方便运营侧存档。

4. 统计分析与定时任务：让问卷数据沉淀出价值

4.1 单选多选统计的SQL与“写时统计”策略

统计模块是问卷系统区别于普通表单系统的核心。单选统计非常简单，一张SQL就能算完：

SELECT qd.id AS question_id, qd.option_ids, COUNT(*) AS answer_count FROM answer_detail qd WHERE qd.questionnaire_id = #{questionnaireId} AND qd.question_type = 0 GROUP BY qd.id, qd.option_ids;

多选统计因为option_ids存储的是逗号分隔字符串，直接GROUP BY会按整个组合分组，不符合“每个选项独立计数”的需求。我的做法是先查明细，再用FIND_IN_SET按选项拆开计数，或者更稳妥的方法是在应用层解析一遍。数据量小时完全没问题，但如果问卷量级到了一定程度，实时解析就会拖慢统计接口。

我最终采用的是“写时统计”策略：在答卷提交事务成功之后，额外把这些题目的答案同步写进一张answer_option_stat统计表，每个选项一张汇总行。统计接口直接读这张表，毫秒级返回。代价是存储空间多一点，换来的是首页看板、实时报表的流畅体验。这套思路在数据量上来之后会让你省掉大量重构成本。

4.2 交叉分析与文本题的关键词处理

交叉分析是问卷运营里很有用的功能，比如“不同部门的同事在选择某项福利时有没有明显差异”。实现思路是分组维度用SQL的CASE WHEN配合GROUP BY，把用户属性（部门、职级、城市）拆成桶，再对每个桶内的选项计数做对比。这里的前提是答卷记录和用户属性表能关联上，所以answer_record表里我额外冗余了一个user_group字段，来自用户主表，避免统计时频繁连表。

文本题的自动分析是我后来加的功能，用到了hanlp分词库。在SpringBoot里接入很简单，引入依赖后初始化一个全局的词法分析器，然后对填答题的文本做关键词提取，把高频词汇总成词频表，管理后台就能看到“用户反馈里出现最多的词是哪个”。分词器的初始化要放在启动阶段，不要每次请求都new一个，否则加载词库的时间会让你怀疑人生。

这里顺便记录一下我的分词应用方式：写一个async方法，问卷提交后异步处理文本题答案，把关键词、词频、关联问卷ID写入text_keyword表。这样既不影响主链路提交速度，也能让运营侧在几分钟内看到最新的词云数据。

4.3 SpringBoot定时任务的三个落地场景

定时任务这块，我用的是SpringBoot自带的@EnableScheduling加@Scheduled，不需要引入额外框架。具体应用了三个场景。

第一个是每日凌晨汇总前一天的答卷统计数据到汇总表，运营早上打开后台就能看到昨天的回收量和各题型完成率。第二个是巡检问卷有效期，把已经超过endTime的问卷从“已发布”自动改为“已回收”，免得人工漏操作。第三个是每周给管理员生成一次简单的数据简报邮件，主题、回收量、平均填写时长都在邮件正文里，用的是Spring的邮件封装。

定时任务代码示例：

@Component public class SurveyScheduleTask { @Scheduled(cron = "${survey.stats.daily-cron:0 0 1 * * ?}") public void dailySummary() { List<Questionnaire> needSummary = questionnaireMapper.selectNeedSummary(); for (Questionnaire q : needSummary) { summaryService.buildDailySummary(q.getId()); } } @Scheduled(cron = "${survey.stats.check-cron:0 */30 * * * ?}") public void autoRecycle() { questionnaireMapper.updateExpiredStatus(); } }

cron表达式我建议都放在配置文件里，用占位符提供默认值，这样部署到不同环境时可以随时调整而又不用改代码。

这里有一个多实例部署才会踩到的坑：定时任务在多个服务实例上会重复执行。比如两个后端实例，同一分钟内两个实例都会执行autoRecycle，导致状态更新重复跑。最简单的解决方案是加一个Redis分布式锁，执行任务前先尝试占锁，拿不到锁的实例直接跳过。这个方案比引入ShedLock更轻，因为我们的Redis本来就在用。

5. Docker化部署与性能优化细节

5.1 用Docker打包SpringBoot服务的完整流程

部署这块，我先把SpringBoot服务打成Docker镜像，再在服务器上用容器方式运行。多阶段构建的Dockerfile如下：

FROM maven:3.8.6-openjdk-8 AS build WORKDIR /app COPY pom.xml . RUN mvn dependency:go-offline -B COPY src ./src RUN mvn clean package -DskipTests FROM openjdk:8-jre-alpine WORKDIR /app COPY --from=build /app/target/survey-system.jar app.jar EXPOSE 8080 ENTRYPOINT ["java", "-jar", "app.jar"]

多阶段构建的好处是最终镜像只保留运行环境，不会带着整个Maven仓库，镜像体积少了好几百兆。国内构建镜像时有个非常实际的问题：从官方源拉取基础镜像和依赖特别慢，我配置了阿里云的镜像加速器，并在Maven的settings.xml里配置了国内仓库镜像，整体构建时间从十几分钟降到两分钟以内，这个优化谁做谁知道。

如果服务器装的是宝塔面板，Docker部署也很方便：把Dockerfile和项目源码传到服务器，在宝塔的Docker管理器里构建镜像，再把宿主机的8080端口映射到容器的8080，一个命令就能跑起来。数据库和Redis直接用宝塔面板自带的MySQL和Redis服务，容器内通过宿主机内网IP访问。

5.2 高频接口的缓存与索引优化

问卷模板属于典型的“读多写少”数据，我把模板详情缓存到了Redis，key就是问卷ID，发布和回收时主动删除缓存。这样用户端每次打开问卷都直接走缓存，QPS轻松上一两百也没压力。

数据库索引方面，三个索引是必建的：answer_record表的(questionnaire_id, user_key)唯一索引、answer_detail表的(questionnaire_id, question_id)联合索引、question表的(questionnaire_id, sort_order)索引。没有这些索引，答卷列表、统计汇总、题目顺序查询在数据量上去后都会全表扫描。

列表页的分页还有一个深分页优化技巧：管理后台查看答卷时，翻到第100页以后MySQL的OFFSET会越来越慢。我的解决办法是改成游标式分页，前端传最后一行的id，SQL用WHERE id < #{lastId} ORDER BY id DESC LIMIT 20，翻页性能基本恒定。

性能优化最能让你直观感受到差距的还是统计模块。最初版本统计大题量问卷时要实时扫answer_detail表，一万份答卷要两秒多；改为写时统计后，接口响应直接压在五十毫秒以内，这一步算是整套系统里投入产出比最高的优化之一。

如果以后问卷提交量继续暴涨，我还有两个扩展方向：一是接入消息队列做异步削峰，把提交流量先打到队列里再稳定落库；二是把海量答卷明细定期同步到分析型存储，交给后续的数据分析组件去处理。中小型系统没必要一开始就上这套，先把单库单表的优化做到位更实际。

6. 真实踩坑记录：版本、事务、并发与格式问题

6.1 SpringBoot版本太高带来的连锁反应

这个坑我印象极深。最开始我图新鲜用了SpringBoot 3.2，结果一连串问题直接教我做人：原有的javax.servlet全部变成jakarta.servlet，很多老工具类的import路径全部失效；SpringFox的Swagger不兼容，接口文档从零开始换配置；部分第三方分页插件、代码生成器也停更了。

后来我查了一圈，发现问卷调查这类系统根本没有必要抢新版本，稳定才是第一诉求。我最后锁定了SpringBoot 2.7.x，所有依赖都换成2.x兼容版本，花了小半天把所有import和配置调通。写这套系统的朋友如果在选型阶段，我的建议是先确认你的核心第三方依赖是否已经适配了SpringBoot 3.x，再去决定用哪个版本，不要为了“新”而新。

6.2 事务与锁的两个经典陷阱

第一个陷阱是@Transactional自调用失效。我在写问卷复制功能时，在同一个类的内部方法里调用了一个带事务注解的方法，结果事务完全没有生效，部分数据插入成功、部分失败，还很难复现。原因是Spring的声明式事务基于代理对象，内部自调用走的是this而不是代理，注解被绕过。解决办法很直接：把需要事务的内部逻辑拆到另一个Service里，或者手动注入自身引用后再调用。

第二个陷阱是大事务拖垮性能。答卷提交时，我一度把文本分词、问卷指标更新、Excel导出准备都放在同一个事务里，高峰期数据库连接池被长时间占满。后面把所有非核心操作全部移到事务外，事务内只做校验、落库、更新关键状态，接口耗时立刻降下来。

6.3 时区、序列化与参数校验的边角问题

时区问题是最不起眼但最容易出错的。MySQL连接串里如果没有加serverTimezone参数，LocalDateTime类型会出现8小时的时差。我统一在JDBC配置里指定了serverTimezone=Asia/Shanghai，并且规定所有时间字段在Java侧统一用LocalDateTime，一律不转字符串，这之后时区问题彻底消失。

LocalDateTime在JSON序列化时也翻过车。SpringBoot默认的Jackson如果没配JavaTimeModule，返回给前端的日期格式要么是一串数字，要么直接序列化报错。我的解决方案是全局配置一个ObjectMapper，统一日期格式为“yyyy-MM-dd HH:mm:ss”，前端展示时什么都不用处理。

参数校验方面，我用的是spring-boot-starter-validation的@Validated加自定义注解。比较实用的一个规则是：创建问卷时如果设计了必答题，但用户提交的答卷对应选项为空，需要有清晰的中文业务提示，不要直接抛500。所以我在全局异常处理器里统一捕获MethodArgumentNotValidException和BusinessException，返回统一的响应结构，这样前后端联调时不会被一堆乱七八糟的异常信息搞崩心态。

做完整套系统，回头再看，问卷调查类项目最难的地方从来不是代码量，而是状态管理和数据口径的严谨性。最值得多花时间设计的，是统计模型和防重复机制，这俩决定了系统在数据量上来之后还能不能稳定服务。如果你也要做类似的表单、投票、评测系统，我建议先把这几类题目的数据通路想清楚再写代码，不要急着画页面。