ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀，每一条都经过真实交付验证。

首页 / 资讯中心 / 正文

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

2026/9/16 4:40:27 拓冰建站 浏览量
SpringBoot问卷调查管理系统实践：从数据库设计到部署全解析 做后台开发这些年我经手过不少业务系统问卷调查管理系统算是一个麻雀虽小但五脏俱全的典型项目。基于SpringBoot来搭这一套几乎成了Java方向毕设和内部工具系统的标配因为它的业务链路完整——从问卷创建、题目配置、发布回收到用户填写、数据统计每一环都能讲出设计点又不像电商那样复杂到劝退新人。我最近整理了一套完整的“基于SpringBoot的问卷调查管理系统”源码顺手把部署文档和代码讲解也补齐了这篇就把整个实践过程掰开揉碎从技术选型、数据库设计、核心逻辑到服务器部署、常见坑排查一条线写清楚。不管你是拿它做毕业设计还是想在团队内部快速搭一套轻量问卷工具都有可以直接抄作业的部分。1. 项目定位与整体设计思路1.1 为什么用SpringBoot做问卷系统先说结论SpringBoot不是功能最强的却是这个场景下综合成本最低的。问卷调查系统的核心诉求是“快速搭建、稳定跑起来、能改能扩”它没有复杂的实时交互也没有海量并发的硬指标绝大多数场景就是几百上千人同时填问卷数据量撑死几万条。SpringBoot的自动装配让配置量直线下降内嵌Tomcat让部署变成一个java -jar命令的事这对小团队和单机部署来说极其友好。我做这套系统时也纠结过要不要上微服务、要不要拆模块后来想清楚了业务边界就那么大硬拆只会徒增维护成本。最终定下来的方案是单体应用 分层架构后续如果问卷量爆炸优先做缓存和索引优化而不是急着拆服务这一条对所有中小型系统都适用。1.2 系统功能与模块边界这套问卷调查管理系统覆盖了一整套业务闭环功能拆成四个核心模块问卷管理创建问卷、编辑题目、设置问卷状态草稿、发布中、已结束、复制问卷。用户填写按问卷链接或问卷码进入作答后提交答卷系统做幂等控制防止重复提交。数据统计按问卷维度统计回收量、各题选项分布、填空题答案列表并支持导出Excel。系统管理维护管理员账号、查看操作日志这块是给后台运维用的。这四个模块合起来基本就是一个商用问卷工具的MVP版本。没有做权限细化到角色那种复杂设计而是用最直接的管理员登录态控制后台操作前台填写完全开放这也是大多数内部问卷系统的通行做法。1.3 这套系统适合谁如果你正在准备Java方向的毕业设计这套系统能让你在答辩时有足够的内容可讲——SpringBoot核心机制、MyBatis数据访问、前端模板渲染、权限控制、AOP日志每一个点都能展开。如果你是团队里负责内部工具的开发者它也能直接用把问卷配置好丢给同事填后台导出数据就完事。当然它不适合拿去跟问卷星这类商业产品正面竞争功能深度和并发能力都差着量级但作为一套学习范式和内部工具够用了。2. 技术选型与项目结构详解2.1 技术选型背后的取舍整套系统的技术栈如下技术组件选型版本选型理由JDK1.8 / 11稳定且兼容性最好服务器部署不会遇到版本兼容噩梦SpringBoot2.7.x2.x系兼容性和资料丰富度最佳避免3.x新特性带来的坑MyBatis2.xSQL可控性强统计类复杂查询更好调优MySQL5.7通用性最强免费资料多Thymeleaf3.x后台管理端直接用服务端模板渲染简单直接Bootstrap jQuery5.x / 3.x管理端UI不用引入重型前端框架原生HTML AJAX—前台问卷填写页轻量快速EasyExcel / POI3.xExcel导入导出Druid1.x数据库连接池 监控页面为什么后台管理端不用Vue或React这里很多人会踩坑。问卷管理后台的交互复杂度和数据实时性要求都不高用Thymeleaf服务端渲染开发效率极高一个Controller返回视图名就把页面跳转解决了不用额外搭Node环境、不用处理跨域对单体应用来说这是最优解。如果问卷填写页用Vue则同理它其实就是一个页面接口AJAX请求提交JSON数据就够了不需要引入完整的构建链路。2.2 项目目录结构约定源码的包结构沿用了我多年固定的分层习惯清晰到看一眼就知道代码在哪com.example.survey ├── controller # 接口层接收请求、返回结果 ├── service # 业务层核心逻辑都在这 │ └── impl ├── mapper # MyBatis数据访问层纯接口 ├── entity # 数据库实体类 ├── dto # 数据传输对象避免实体直接暴露给前端 ├── vo # 视图对象按需组装返回给页面的数据 ├── config # 配置类拦截器、跨域等 ├── interceptor # 登录拦截器 ├── aspect # AOP切面写日志用 ├── common # 统一返回结果、异常处理、工具类 └── SurveyApplication.java这里有一个容易被忽视的规范问题实体类entity和视图对象vo必须分开。很多人图省事直接拿实体给前端返回结果密码字段漏出去、多余字段暴露后面怎么改都别扭。我在这个项目里用VO做了前端数据的二次封装接口返回什么都由VO决定安全性可控很多。2.3 核心依赖与版本兼容建议pom.xml里的依赖不用全列出来但有几个关键点值得提醒SpringBoot的父级版本和MyBatis starter版本一定要匹配我遇到过2.7.x的SpringBoot配了1.3.x的mybatis-spring-boot-starter结果自动装配失败报找不到SqlSessionFactory。数据库驱动坐标在SpringBoot 2.x里用com.mysql:mysql-connector-j如果你还在用老的mysql:mysql-connector-java部分版本会报警告但不影响运行技术上没大问题但建议统一。Lombok建议加上实体类的getter/setter/toString靠注解搞定代码量少一大截而且是编译期处理对运行无影响。分页插件pagehelper直接引入com.github.pagehelper:pagehelper-spring-boot-starter一行配置就能用比手写limit强在不用每写一条查询都算页码。3. 数据库设计是这套系统的地基3.1 核心数据表与字段解析问卷系统的数据库设计准确说就围绕一个核心思想问卷-题目-选项-答卷四层结构拆开存。我设计了五张核心表建表SQL可以直接用到你的项目里-- 问卷表 CREATE TABLE survey ( id bigint(20) NOT NULL AUTO_INCREMENT, title varchar(200) NOT NULL COMMENT 问卷标题, description text COMMENT 问卷描述, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 0草稿 1发布中 2已结束, start_time datetime DEFAULT NULL COMMENT 开始时间, end_time datetime DEFAULT NULL COMMENT 结束时间, questionnaire_code varchar(32) DEFAULT NULL COMMENT 问卷码, create_time datetime DEFAULT NULL, update_time datetime DEFAULT NULL, deleted tinyint(4) NOT NULL DEFAULT 0 COMMENT 逻辑删除, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT问卷表; -- 题目表 CREATE TABLE question ( id bigint(20) NOT NULL AUTO_INCREMENT, survey_id bigint(20) NOT NULL COMMENT 所属问卷ID, type tinyint(4) NOT NULL COMMENT 1单选 2多选 3简答, stem varchar(500) NOT NULL COMMENT 题干, sort_order int(11) NOT NULL DEFAULT 0 COMMENT 排序, required tinyint(4) NOT NULL DEFAULT 1 COMMENT 是否必答, PRIMARY KEY (id), KEY idx_survey_id (survey_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT题目表; -- 选项表 CREATE TABLE option ( id bigint(20) NOT NULL AUTO_INCREMENT, question_id bigint(20) NOT NULL COMMENT 所属题目ID, option_text varchar(300) NOT NULL COMMENT 选项内容, sort_order int(11) NOT NULL DEFAULT 0, PRIMARY KEY (id), KEY idx_question_id (question_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT选项表; -- 答卷表 CREATE TABLE answer_sheet ( id bigint(20) NOT NULL AUTO_INCREMENT, survey_id bigint(20) NOT NULL, user_key varchar(64) DEFAULT NULL COMMENT 填写人标识如IP浏览器指纹, submit_time datetime DEFAULT NULL, PRIMARY KEY (id), KEY idx_survey_id (survey_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT答卷表; -- 答卷明细表 CREATE TABLE answer_detail ( id bigint(20) NOT NULL AUTO_INCREMENT, answer_sheet_id bigint(20) NOT NULL, question_id bigint(20) NOT NULL, option_ids varchar(300) DEFAULT NULL COMMENT 选中的选项ID逗号分隔, answer_text text COMMENT 简答题答案, PRIMARY KEY (id), KEY idx_sheet_id (answer_sheet_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT答卷明细表;这套设计的核心思路是题目和选项不冗余存在问卷表里而是各自独立成表用外键关联。好处是统计时可以直接对option表做分组聚合要改题目也只动question表不动survey表。3.2 状态设计与逻辑删除状态字段我用的是数字枚举值没有用字符串。有人喜欢用字符串如draft、published这样直观但数字在数据库存储上更省空间、索引效率更高代码里用枚举类去做语义映射可读性一样有保障。逻辑删除是我特别提的一个点也是很多项目会忽略的设计。问卷数据是有统计价值的资产物理删除一旦误操作就找不回来。我在每个核心表都加了deleted字段所有查询默认带deleted 0条件删除操作实际上执行的是UPDATE而不是DELETE。MyBatis里我会建一个公用的SQL片段避免每个查询都重复写这句条件。3.3 索引与外键取舍数据库设计中一个常见争议是用不用物理外键。我的习惯是业务开发中不使用物理外键只保留逻辑关联和普通索引。原因很现实物理外键会让插入和更新的性能下降而且一旦数据量大起来外键约束排查问题非常费劲。数据一致性完全可以在service层通过事务控制保证。所以我在表结构里只建了普通索引比如idx_survey_id查询题目列表和统计答卷时靠它加速。另外要提醒的是option_ids这个字段我故意设计成了逗号分隔的字符串这在外行眼里是“反范式设计”但它在这个场景里是合理的权衡。多选题的答案天然就是一对多关系如果强行拆行存统计和展示都要多做一次聚合反而复杂。只要题目选项数量有限字符串存ID列表完全够用查询时用FIND_IN_SET或其他方式处理也不慢。如果你想做得更规范可以拆成关联表但那是另一套复杂度。4. 核心功能实现与代码讲解4.1 问卷CRUD与状态流转问卷管理后台的Controller层很薄真正的逻辑在Service里。以发布问卷为例这个操作不是简单改一个状态字段就完事还包含一系列校验问卷下至少有一道题目题目内容不能为空结束时间必须晚于当前时间。我把这些校验统一抽到validateSurvey()方法里发布前调用草稿保存时不做校验因为用户可能只填了一半就去保存。状态流转用代码约束死public Boolean publishSurvey(Long surveyId) { Survey survey surveyMapper.selectById(surveyId); if (survey null || survey.getDeleted() 1) { throw new BusinessException(问卷不存在); } if (survey.getStatus() SurveyStatus.PUBLISHED.getCode()) { throw new BusinessException(问卷已发布请勿重复操作); } // 校验题目数量 int questionCount questionMapper.countBySurveyId(surveyId); if (questionCount 0) { throw new BusinessException(问卷下至少需要一道题目); } survey.setStatus(SurveyStatus.PUBLISHED.getCode()); surveyMapper.updateById(survey); return true; }这种状态校验放在service层而不是controller层的用意是controller只负责参数接收和路由如果业务校验散落在多个接口里状态流转的规则就不够集中后面有人改代码容易漏掉某种状态组合。4.2 题目类型的统一抽象选择题和简答题的处理逻辑差异很大但我用类型字段统一管理而不是建多张表分表存。题目类型用type字段区分1单选、2多选、3简答。前端页面的处理是加载问卷时先获取全部题目再根据题目类型动态渲染不同的交互组件。单选渲染radio多选渲染checkbox简答渲染textarea。这里有一个我踩过的坑单选题的name属性必须是题号如果所有单选题都用同一个name浏览器会把它们当成一组选A题会影响B题。一定要用namequestion_${id}这种方式做隔离。后端接收答案时也按类型分别处理if (question.getType() QuestionType.SINGLE_CHOICE.getCode()) { // 单选只允许一个选项ID直接转int answerDetail.setOptionIds(singleOptionId.toString()); } else if (question.getType() QuestionType.MULTIPLE_CHOICE.getCode()) { // 多选是数组拼接成1,3,5 answerDetail.setOptionIds(StringUtils.join(multiOptionIds, ,)); } else { // 简答存文本 answerDetail.setAnswerText(answerText); }核心思想就一个答案的存储结构统一但解析逻辑按类型分支处理。这样统计模块就能通过一个统一的入口拿到所有答案数据再做二次计算。4.3 答卷提交与幂等控制问卷提交最怕的是用户手滑点了两次提交按钮或者网络超时后前端重试导致同一份答卷被插了两条。我在后端做了两层控制第一层前端提交按钮在发送请求后立即置灰禁止重复点击这是体验层面的兜底。第二层后端在提交接口里做了用户标识查重同一用户对同一问卷只能提交一次// 用户标识优先取登录用户ID否则用IPUser-Agent哈希 String userKey buildUserKey(request); int exists answerSheetMapper.countBySurveyIdAndUserKey(surveyId, userKey); if (exists 0) { throw new BusinessException(您已经提交过该问卷请勿重复提交); }这个方案简单可靠虽然极端情况下会有并发穿透但对问卷系统这种低频并发场景完全够用。如果你要更高强度可以在answer_sheet表加上(survey_id, user_key)的唯一索引用数据库层面兜底。提交的整个动作放在一个事务里答卷表插一条主记录明细表循环插入多条子记录任何一条失败全部回滚Transactional(rollbackFor Exception.class) public void submitAnswer(SubmitDTO dto, HttpServletRequest request) { // 插入答卷主记录 // 循环插入明细记录 }4.4 统计报表的实现思路统计模块的SQL是这个项目里最能体现MyBatis优势的地方。问卷回收量是count单选题做分组统计多选题要先拆分再统计。多选的统计我推荐的做法是先查出该题所有答案的option_ids在Java代码里拆分成列表再计数而不是硬写SQL。为什么不用SQL直接拆因为MySQL没有内置split函数写起来要么用SUBSTRING_INDEX循环处理要么用JSON函数性能和可维护性都差。数据量在几千条时纯Java处理毫秒级完成不构成性能瓶颈。强行炫技反而给自己留坑。单选题最适合用SQL一步搞定SELECT option_id, COUNT(*) AS count FROM answer_detail WHERE question_id #{questionId} GROUP BY option_id查出结果后再到option表把选项文本补上就能拼出前端图表需要的结构。我在管理后台直接用了ECharts展示统计图表后端只需要返回选项名和对应数量前端配置一个饼图或柱状图即可工作量很小。5. 部署文档与实操踩坑全记录5.1 开发环境准备与关键配置这套系统的开发环境需要JDK 8、Maven 3.6、MySQL 5.7和一个趁手的IDE。环境装好后先把数据库建出来mysql -u root -p CREATE DATABASE survey_system DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;然后导入项目里sql目录下的初始化脚本注意脚本里包含了建表和初始管理员数据。核心配置文件在src/main/resources/application.ymlserver: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/survey_system?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse username: root password: 你的密码 type: com.alibaba.druid.pool.DruidDataSource thymeleaf: cache: false mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.survey.entity configuration: map-underscore-to-camel-case: true这里三个配置项是最容易出问题的serverTimezoneAsia/Shanghai必须加否则数据库连接会报时区错误或者时间字段少8小时。characterEncodingutf8必须加否则读中文会乱码。map-underscore-to-camel-case: true建议加它能自动将数据库的create_time映射到实体的createTime字段省掉大量resultMap配置。5.2 打包构建与jar部署开发调试完成后要部署到服务器核心就是用Maven打包成可执行的jar文件。我推荐直接用IDEA右侧Maven面板双击package打包前先跑clean避免旧的class文件干扰。打包完成后target目录下会生成一个survey-system-0.0.1-SNAPSHOT.jar这个jar包含了内嵌的Tomcat传到服务器后用一条命令就能启动java -jar survey-system-0.0.1-SNAPSHOT.jar想让它在后台持续运行用nohup命令nohup java -jar survey-system-0.0.1-SNAPSHOT.jar survey.log 21 查看实时日志用tail -f survey.log停在后台启动的方式也有讲究 survey.log 21把标准输出和错误输出都重定向到日志文件里排查问题时全靠这个文件。别小看这一步我第一次部署时少写21报错信息直接丢到终端看不到排查了很久。如果想随服务器启动自动运行推荐用systemd写一个服务文件这样就算进程意外退出也可以自己拉起来。5.3 Nginx反向代理与静态资源配置生产环境我一般会在jar前面再挂一层Nginx主要做三件事端口转发把80端口转到8080、缓存静态资源、统一处理跨域。一个最简配置如下server { listen 80; server_name your.domain.com; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location ~* \.(css|js|png|jpg|jpeg|gif|ico|svg)$ { proxy_pass http://127.0.0.1:8080; expires 7d; } }注意proxy_set_header X-Real-IP $remote_addr必须配不然后端通过request.getRemoteAddr()拿到的都是Nginx的IP 127.0.0.1这会导致我之前做的用户提交幂等判断全部失效因为每个用户看起来IP都一样第一个人提交后其他人就都提交不了了。这个坑非常隐蔽不配Nginx时本机环境根本发现不了。5.4 服务器部署避坑清单我把部署过程中遇到的典型问题和解决方案整理成了一张表现象原因解决方案页面中文乱码数据库连接URL没加characterEncoding在url上加characterEncodingutf8时间字段少了8小时连接时区没指定url加上serverTimezoneAsia/Shanghai前端提交问卷一直转圈接口405或500看后台日志多半是参数名不对或类型转换失败无法连接MySQL数据库权限或端口没开检查bind-address和防火墙给用户授权user%jar包启动后过几秒自动退出端口占用或配置错误看日志的开头有没有APPLICATION FAILED TO STARTNginx 502 Bad Gateway后端jar没启动或proxy_pass配置错确认8080端口能通curl http://127.0.0.1:8080提交问卷提示重复同一IP多人填写且用了IP做用户标识改用IP浏览器指纹哈希或放宽为同一IPN分钟内限制一次6. 常见问题排查与代码学习建议6.1 部署期高频问题的排查思路部署类问题有一个通用的排查顺序先看日志再看端口再看网络最后看权限。很多人一遇到问题就改代码这是错误路径。日志永远是最快定位问题的入口。端口占用的问题也频繁出现。如果你8080端口被其他程序占了要么改端口要么杀掉占用进程。Linux上查端口占用netstat -tlnp | grep 8080查到PID后直接kill -9即可或者干脆从源头解决把Nginx里映射的端口换一个空闲的。数据库连接问题更常见的是权限不对。本地能连服务器上连不上绝大多数是MySQL用户授权问题SQL执行一下GRANT ALL PRIVILEGES ON survey_system.* TO root% IDENTIFIED BY 密码; FLUSH PRIVILEGES;这里要提醒生产环境不建议直接用root远程连数据库更安全的做法是建一个独立的账号只授权这个库的最小权限。安全意识从开发期就养成省得后面出事故。6.2 代码学习与二次开发的建议拿到这套源码建议不要从Controller看起而是按数据流向看先看数据库表结构再看entity实体然后看mapper接口和XML理解数据怎么读写最后看service和controller理解业务逻辑怎么编排。有几个核心文件建议精读SurveyController.java看一个完整业务模块的接口怎么写。AnswerSheetServiceImpl.java看事务和幂等控制怎么实现。StatisticServiceImpl.java看统计类的聚合逻辑怎么组织。LoginInterceptor.java看登录态校验怎么做注意哪些路径放行哪些拦截。二次开发时最常改的点是统计维度扩展、问卷模板复用、题目类型增加新玩法比如评分题、排序题。评分题本质上可以看作单选的变体可以复用单选的结构只是渲染和统计的逻辑不同。6.3 一套代码的边界什么场景需要升级方案最后泼一点冷水。这套系统在内部使用场景非常合适但如果要做成SaaS产品或者预计单问卷会收集几十万份答卷有几个点就必须重新设计option_ids字符串存多选的方案要拆成明细行或JSON统计逻辑要支持异步计算或跑批文件导出要异步化前端要换成Vue/React 构建链路。真要走到那一步就不是搭个demo的事但本项目的分层和思路可以给你提供一个相对清晰的升级路径。我在实际使用中发现这套代码最重要的是把“够用就好”的边界守住了没有为了炫技引入一堆不必要的复杂度。每次有人拿它当毕设改需求我也建议先想清楚哪些地方是锦上添花哪些是画蛇添足改代码之前先改思路比什么都重要。