简介面向Java Web初学者与Spring Boot实战者的在线问卷调查系统源码包围绕问卷模板创建、问卷编辑发布、社交网络分享、结果统计与个人中心等模块提供从用户认证授权到RESTful接口设计的完整参考实现。包内共294个文件以100个Java源码、26个HTML页面、26个JavaScript脚本以及CSS、SQL、properties配置文件为主并含图片、字体、图标等静态资源压缩包约37.17MB前后端与数据库相关文件分布较清晰便于按模块查阅。目前已有269人学习下载适合用于课程设计、毕业设计或框架练手也可作为Spring Security鉴权、Spring Data JPA持久化与前后端联调的对照案例。读者可据此梳理Spring Boot项目的分层结构、实体与数据表映射、登录注册流程、问卷增删改查和图表统计的实现思路也能参考静态资源组织与接口联调方式快速搭建可运行的调查问卷应用原型。1. 从一份“回收了 87 张表格”的调研说起去年有个做市场的朋友找我说他们每季度做一次客户满意度调研问卷往群里一发回收上来是几十份填好的 Excel人工合并、去重、数票两天时间就搭进去了还容易数错。后来他们内部有人丢过来一份基于 Spring Boot 的在线问卷调查系统源码问能不能直接改改就用。我看完的第一反应是这类系统功能看着简单——建问卷、发链接、填、看统计但它真正难的地方从来不在页面上而在题目类型的扩展性、答卷的幂等控制、以及统计口径的一致性。这套源码把这三件事的骨架都搭好了Spring Boot MyBatis-Plus MySQL 的组合也很容易接手适合两类人一类是想拿它当毕设或课程项目底稿的学生另一类是真要在内部跑一份调研、又不想上 SaaS 的团队开发者。接下来我按自己拆项目的顺序从技术选型一路讲到怎么改。2. 定位与技术选型这套系统为什么用 Spring Boot 打底2.1 它解决的是“问卷全生命周期”不是“表单页”先把功能边界说清楚不然后面看代码容易迷路。这套系统的核心对象只有四个问卷Survey、题目Question、选项Option、答卷Answer。四个对象串起来是一条完整的状态链——新建问卷是草稿态配好题目后发布发布后生成一个可访问的作答入口用户提交后形成答卷记录最后按题目维度做聚合统计。中间还夹着两个容易被忽略但很关键的动作问卷截止超过时间窗或人为关闭后不再接收新答卷以及答卷去重同一个人对同一份问卷只能提交一次。所以它不是那种“拖拽生成一个表单、提交进数据库就完事”的轻量工具。你在源码里能看到问卷状态字段、开始结束时间、题目排序号、是否必答、答卷来源 IP 这些字段这些都是为“一次严肃的调研”准备的。如果只是想收集个报名信息用这套系统属于杀鸡用牛刀但只要涉及多选题、评分题、结果要出图表、还要防止有人刷票它的结构就比临时拼的表单合理得多。模块划分上源码大致是这么几块用户与权限登录、角色、问卷管理增删改查、发布、截止、题目管理题型、选项、排序、作答端渲染问卷、提交校验、统计端单题汇总、交叉筛选、导出。有些版本还会带一个简答的模板库或者问卷复制功能这个看你拿到的包不影响主干理解。你接手时最该先看的是问卷和题目这两块的 Service它们是整个系统的中枢。2.2 技术栈拆解每一层各自扛什么选型上没有花活是一套很典型的国内中小型管理系统组合好处是资料多、上手快、出问题好查。层次技术在这套系统里的职责Web 框架Spring Boot 2.x提供内嵌容器、自动配置、统一异常处理、拦截器持久层MyBatis-Plus单表 CRUD 走 BaseMapper复杂统计手写 XML数据库MySQL 5.7 / 8.0存问卷、题目、选项、答卷、答案明细视图层Thymeleaf 或 Vue Element管理端表格 作答端表单渲染权限拦截器 / Spring Security管理端登录态校验作答端通常放行统计图表ECharts单选多选出饼图柱状图评分题出均值这里有两个选型点值得单独说一下因为它们直接影响你后面改代码的手感。第一是 MyBatis-Plus 而不是纯 JPA。原因是统计查询太多比如“某问卷每道题的每个选项被选了多少次”这种 SQL 用 JPA 拼起来很别扭而 MyBatis 可以直接在 XML 里写一段带 GROUP BY 的原生 SQL改起来直观。代价是单表 CRUD 要靠代码生成或者手写 MapperPower by MyBatis-Plus 的BaseMapperT能省掉大部分样板代码所以常见做法是单表操作走BaseMapper聚合统计走自定义 XML。第二是作答端用服务端渲染还是前后端分离。这取决于你拿到的包但两种各有取舍Thymeleaf 渲染的好处是链接直接可访问、不需要额外部署前端工程缺点是题目动态渲染尤其是逻辑跳转写起来啰嗦Vue 版本的好处是题目组件化、交互流畅缺点是本地跑起来要同时起两个服务。如果你只是想快速验证功能优先找带 Thymeleaf 的那份如果要做二次开发、加复杂交互Vue 版本更值得投入。2.3 本地跑通从建库到看到第一份问卷跑起来的顺序不要乱先库后服务不然启动就报错。第一步建库字符集用utf8mb4这个别省问卷标题里出现表情符号或者生僻字时utf8会直接抛异常这是我踩过的坑。第二步导入源码里的 SQL 脚本一般包含建表语句和一条管理员初始数据。第三步改application.yml里的数据源第四步启动。server: port: 8080 spring: datasource: url: jdbc:mysql://127.0.0.1:3306/survey?useUnicodetruecharacterEncodingutf8mb4serverTimezoneAsia/Shanghai username: root password: 你的密码 driver-class-name: com.mysql.cj.jdbc.Driver thymeleaf: cache: false # 开发期关掉模板缓存改页面不用重启 mybatis-plus: mapper-locations: classpath*:mapper/*.xml configuration: map-underscore-to-camel-case: true # survey_id 自动映射 surveyId配置里有几个参数值得留意。serverTimezone必须显式指定否则 MySQL 8 驱动在某些环境下会把时间整体偏移 8 小时表现出来就是“刚发布的问卷显示已截止”非常唬人。map-underscore-to-camel-case打开后数据库的下划线字段才能自动映射到实体的驼峰属性如果关掉你会看到一堆字段全是 null但 SQL 明明查出了数据。thymeleaf.cache在开发期关掉改 HTML 刷新即生效省掉反复重启。启动命令就一条如果包里有 Maven Wrapper 就用 wrapper# 打包并启动跳过测试加快首次启动 ./mvnw clean package -DskipTests java -jar target/survey-0.0.1-SNAPSHOT.jar启动成功后访问http://localhost:8080用初始管理员账号登录进管理端新建一份问卷、加两道题、点发布然后用无痕窗口打开作答链接提交一份再回管理端看统计页。这条链路走通说明库、服务、模板、统计四个环节都是通的后面再看代码就有底了。3. 目录结构与数据模型五张表撑起整个系统3.1 包结构按层切还是按业务切源码的包结构大概率是经典的三层切法这也是这类项目最常见的组织方式com.example.survey ├── controller # 管理端与作答端接口 ├── service # 业务逻辑接口 impl ├── mapper # MyBatis-Plus Mapper 接口 ├── entity # 数据库实体 ├── dto # 请求参数如 SubmitDTO、SurveyQueryDTO ├── vo # 返回给前端的聚合对象如 StatVO ├── config # 拦截器、跨域、MyBatis-Plus 配置 └── common # 统一返回体、异常、工具类说句实在话按层切在项目初期没什么问题但写到后面你会发现SurveyService越来越胖发布、复制、统计、导出全塞在一起。我的习惯是接手后先别急着重构等业务稳定了再把“统计”单独拆一个StatService把“导入导出”拆一个ExportService。因为统计逻辑最容易被反复改口径独立出来之后改动半径小也不会误伤发布流程。另外提醒一下entity和dto一定要分开。很多初版代码图省事前端参数直接用实体接结果提交答卷时前端多传一个id就把已有题目覆盖了。这个坑在答题接口上尤其危险因为答题端是公开访问的参数完全不可信。3.2 五张核心表字段设计的取舍建表脚本是理解这个项目最快的方式。核心就五张表我把关键字段摘出来CREATE TABLE t_survey ( id BIGINT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(120) NOT NULL, description VARCHAR(500) NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0草稿 1已发布 2已截止, start_time DATETIME NULL COMMENT 为空表示不限开始, end_time DATETIME NULL COMMENT 为空表示不限结束, creator_id BIGINT NOT NULL, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, deleted TINYINT NOT NULL DEFAULT 0 COMMENT 逻辑删除标记 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE t_question ( id BIGINT PRIMARY KEY AUTO_INCREMENT, survey_id BIGINT NOT NULL, type TINYINT NOT NULL COMMENT 1单选 2多选 3填空 4评分 5矩阵, title VARCHAR(255) NOT NULL, required TINYINT NOT NULL DEFAULT 0, sort_no INT NOT NULL DEFAULT 0, options_json TEXT NULL COMMENT 选项列表JSON 数组, KEY idx_survey (survey_id, sort_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE t_answer ( id BIGINT PRIMARY KEY AUTO_INCREMENT, survey_id BIGINT NOT NULL, user_key VARCHAR(64) NOT NULL COMMENT 登录用户ID或匿名设备指纹, submit_ip VARCHAR(45) NULL, submit_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_survey_user (survey_id, user_key) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE t_answer_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, answer_id BIGINT NOT NULL, question_id BIGINT NOT NULL, content VARCHAR(1000) NULL COMMENT 文本答案, option_keys VARCHAR(255) NULL COMMENT 选中的选项 key多选用逗号分隔, score INT NULL COMMENT 评分题的分数, KEY idx_question (question_id), KEY idx_answer (answer_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这几张表的字段设计里有三个决定值得展开讲。第一个是t_answer上的唯一索引uk_survey_user。这个索引是防刷票的最后一道闸门比起在 Service 里先查后插靠数据库唯一约束更可靠因为并发下“先查再插”会有窗口期两个人同时提交能双双插进去。代价是插入冲突会抛DuplicateKeyException你得在全局异常处理里把它翻译成“您已提交过本问卷”而不是把 500 抛给用户。第二个是t_question.options_json用 JSON 存选项。这个选择在问卷系统里非常常见原因是选项永远跟着题目走从不单独查询拆成独立表反而要每次 JOIN 一次。但它有个代价统计时没法直接 JOIN 选项表选项的展示文案得从 JSON 里解析出来再和聚合结果拼。这在代码里体现为统计 Service 里多一步内存合并不算大问题。第三个是deleted逻辑删除。问卷一旦发布过、有人答过物理删除就会把答卷变成孤儿数据所以逻辑删除是必须的。注意配合 MyBatis-Plus 的TableLogic注解使用否则你手写的 SQL 还得自己加deleted 0漏一处就查出脏数据。3.3 题目类型怎么扩展一个枚举撑起五种题型题型扩展性是这个系统能不能长期用的关键。源码里一般会有一个QuestionType枚举把题型和它的校验规则、渲染方式绑定在一起public enum QuestionType { SINGLE(1, 单选), MULTI(2, 多选), TEXT(3, 填空), SCORE(4, 评分), MATRIX(5, 矩阵); private final int code; private final String label; QuestionType(int code, String label) { this.code code; this.label label; } public static QuestionType of(int code) { for (QuestionType t : values()) { if (t.code code) return t; } throw new BizException(未知题型: code); } }这段代码本身没什么技术含量但它定了一个规矩题型用 code 存库、用枚举在内存里流转前端传的永远是 code服务端永远先经过of()翻译一次。这个规矩的价值在于将来加“排序题”“文件上传题”时你只需要在枚举里加一项然后在提交校验和统计聚合两处各补一个分支而不是满项目搜type 1。我在别的项目里见过反面例子题型判断直接写成if (q.getType() 1)散落在六七个类里后来要加一种题型改了十几处还漏了两处上线后统计页直接空白。血泪经验就是凡是这种固定集合的字段第一件事就是把它变成枚举哪怕初期只有两个值。4. 核心链路拆解一次作答提交到底走了哪些代码4.1 发布与截止状态机比 if 判断靠谱问卷的状态流转看着简单实际上是最容易写乱的地方。草稿可以编辑题目已发布不能改题目结构改了会让历史答卷对不上已截止只能看统计。如果不用状态机代码里就会出现“这个方法里判断了三次状态”的情况。常见做法是把状态判断收拢成一个校验方法public void checkPublishable(Survey survey) { if (survey.getStatus() ! SurveyStatus.DRAFT.getCode()) { throw new BizException(只有草稿状态的问卷可以发布); } Long count questionMapper.selectCount( new LambdaQueryWrapperQuestion().eq(Question::getSurveyId, survey.getId())); if (count null || count 0) { throw new BizException(问卷至少需要一道题目才能发布); } // 单选题必须有选项这里只做抽样校验完整校验遍历题目 }checkPublishable里做了两件事校验当前状态是否允许发布以及校验问卷内容是否完整。之所以把内容校验放在发布这一步而不是保存草稿时是因为草稿本来就是半成品你没法要求用户一次填完但发布出去意味着要给别人答了这时候一道没有选项的单选题会让作答页直接崩掉。截止逻辑同理不要写成定时任务扫描虽然可以更稳的做法是在作答入口处做时间窗判断。因为定时任务有执行间隔中间那几分钟用户还是能提交而入口处判断是即时的。这两条一起用最保险入口判断拦住正常流量定时任务负责把过期问卷的状态刷成“已截止”让列表页显示正确。4.2 作答提交事务、幂等、校验三件套这是整个系统最容易出问题的接口因为它同时要处理并发、事务和用户输入校验。我把典型实现拆开看Transactional(rollbackFor Exception.class) public Long submit(SubmitDTO dto, String userKey, String ip) { Survey survey surveyMapper.selectById(dto.getSurveyId()); // 1. 状态与时间窗校验 if (survey null || survey.getStatus() ! SurveyStatus.PUBLISHED.getCode()) { throw new BizException(问卷不存在或未发布); } LocalDateTime now LocalDateTime.now(); if (survey.getEndTime() ! null now.isAfter(survey.getEndTime())) { throw new BizException(问卷已截止); } // 2. 落主表唯一索引兜底防重复提交 Answer answer new Answer(); answer.setSurveyId(dto.getSurveyId()); answer.setUserKey(userKey); answer.setSubmitIp(ip); try { answerMapper.insert(answer); } catch (DuplicateKeyException e) { throw new BizException(您已提交过本问卷); } // 3. 逐题落明细必答题在这里兜底校验 ListQuestion questions questionMapper.selectList( new LambdaQueryWrapperQuestion().eq(Question::getSurveyId, dto.getSurveyId())); for (Question q : questions) { AnswerItem item buildItem(answer.getId(), q, dto.getItem(q.getId())); answerItemMapper.insert(item); } return answer.getId(); }代码不长但三个点必须说透。事务边界整个方法包在一个事务里任何一道题落库失败都整体回滚避免出现“主表有记录但明细缺一半”的脏数据。rollbackFor Exception.class不能省因为默认只回滚RuntimeException如果你自定义的BizException继承了Exception而不是RuntimeException异常抛出去事务却不回滚这个问题极难排查。幂等控制靠唯一索引而不是先查后插。注意这里捕获的是DuplicateKeyException只有真正插入时撞索引才触发并发下两个人同时点提交数据库只放行一个。userKey的取值是个设计点——登录用户用用户 ID匿名用户用设备指纹或者前端生成并落到 localStorage 的 UUID后者防不住刻意刷票但能挡住正常用户的手抖重复提交。真要做严格的一人一票得靠登录态。必答校验在遍历题目时对required 1的题判断答案是否为空为空直接抛业务异常。这一步必须在服务端做前端那点required属性随手就能绕过不能当安全边界。4.3 统计聚合别在 Java 里数循环统计页是这类系统的门面也是最容易写出性能问题的地方。我见过一种写法把某个问卷的所有answer_item一次性查进内存然后 for 循环按questionId分组、再按选项计数。问卷几十份的时候没问题上千份之后内存直接顶上去而且每次刷新都全量算一遍。正确做法是把聚合下推到数据库-- 单选/多选题每个题目下每个选项被选中的次数 SELECT ai.question_id, o.opt_key, COUNT(*) AS cnt FROM t_answer_item ai JOIN t_question q ON q.id ai.question_id JOIN t_answer a ON a.id ai.answer_id WHERE a.survey_id #{surveyId} AND q.type IN (1, 2) AND FIND_IN_SET(o.opt_key, ai.option_keys) 0 GROUP BY ai.question_id, o.opt_key;不过这段 SQL 有个前提——选项得能 JOIN 出来。前面说了选项存在 JSON 字段里所以实际代码里通常是两步先用一条 SQL 把各选项的计数查出来再在 Service 里从options_json解析出选项文案按 key 合并成前端要的[{name, value}]结构。多选因为存在option_keys里是逗号分隔的字符串用FIND_IN_SET展开这个函数用不上索引数据量大的时候会慢这是这套设计的固有代价。评分题的口径又不一样不能数选项要算均值和分布SELECT question_id, AVG(score) AS avg_score, MIN(score) AS min_score, MAX(score) AS max_score, COUNT(*) AS total FROM t_answer_item WHERE question_id IN (#{ids}) AND score IS NOT NULL GROUP BY question_id;统计里最容易被忽略的是分母。一道非必答题如果 100 人里有 20 人没填那这道题的有效样本是 80 不是 100百分比必须按 80 算。这个口径要在代码里显式处理否则统计出来的比例加起来不到 100%运营同事会来问你为什么。4.4 作答页渲染题目顺序与跳转逻辑作答端要做的不只是把题目循环渲染出来还得处理排序和条件跳转。排序靠sort_noSQL 里ORDER BY sort_no ASC即可简单。真正麻烦的是逻辑跳转——比如“第 3 题选了 A 就跳到第 5 题”。这类功能在源码里可能没有但属于二次开发的高频需求。实现思路是在题目上挂一个next_rule字段JSON存“选了某选项后跳转到哪道题”前端在选项变化时读取规则决定下一步渲染哪题。这里有个血泪教训跳转逻辑一定要前后端一致前端跳了但后端按全量题目校验必答用户就会被卡在“你有一道没见过的题没填”。正确做法是后端在提交时按同一套跳转规则算出“实际生效的题目集合”只对这个集合做必答校验。这种前后端规则各写一遍、又不同步的情况是这类系统上线后最常见的投诉来源。5. 避坑与排查五个真实踩过的坑5.1 数据层时间差 8 小时与中文变问号现象刚发布的问卷作答页直接提示“问卷已截止”可结束时间明明设在一周后。原因JDBC URL 没配serverTimezoneMySQL 8 驱动按 UTC 解析写入的时间和读取的时间差了 8 小时。解决URL 里显式加serverTimezoneAsia/Shanghai同时确认数据库服务器的时区两者要对齐。这个问题在本地开发机上可能不出现因为机器时区恰好一致一部署到别的环境就爆属于典型的“环境玄学”。现象二问卷标题里的中文存进库变成问号或者乱码。原因建库时用了utf8字符集连接串也没指定characterEncoding。解决建库语句统一DEFAULT CHARSETutf8mb4连接串带上characterEncodingutf8mb4三处库、表、连接必须一致缺一处都可能出问题。5.2 提交链路重复提交与事务不回滚现象网络卡顿时用户连点两次提交数据库里出现两条同问卷的答卷统计数字翻倍。原因只在 Service 里做了“先查是否已提交”两个请求并发进来时都查到“没提交过”。解决加唯一索引uk_survey_user兜底同时前端提交按钮点击后置灰后端把DuplicateKeyException捕获后返回友好提示。索引是硬约束代码是软约束两个都要。现象二提交时某道题校验失败抛出业务异常用户重新提交后发现主表多了一条答卷记录但没有明细。原因自定义异常继承的是Exception而Transactional默认只回滚RuntimeException。解决要么让业务异常继承RuntimeException要么显式写rollbackFor Exception.class。这个坑不看日志根本发现不了因为接口返回的是正常的错误提示。5.3 统计与展示口径错位和空数据崩页现象管理端统计页某道题百分比加起来是 92%运营来问是不是算错了。原因这道题非必答有 8% 的人跳过分母用了总答卷数而不是该题的有效答卷数。解决聚合 SQL 里按question_id分组时分母取该题的非空记录数Java 侧不要再二次换算。现象二新发布的问卷还没人答点开统计页直接白屏报 500。原因图表渲染时对空数组取[0]或者对空结果做除法。解决统计接口在没有数据时返回结构完整但数值为 0 的对象前端图表组件做空数据兜底。这类问题在测试阶段很难发现因为测试数据总是有的上线后第一批用户点进来才发现。现象三多选题选项文案和计数对不上。原因选项存在 JSON 里统计结果按 key 合并时用了String比较但两边的 key 大小写或者空格不一致。解决选项 key 在保存时就统一成小写无空格的固定格式比如opt_1、opt_2不要用选项文案本身当 key。6. 二次开发先加一道题型再谈重构接手这类源码我的建议是先做一次“最小改造”来熟悉结构而不是上来就重构。最合适的练手目标是加一种题型——比如“排序题”或者“文件上传题”。整个改造路径能让你把实体、Mapper、Service、前端渲染全走一遍而且改动可控。具体步骤是这样先在QuestionType枚举里加一项然后在t_question表上不用改结构options_json复用但t_answer_item需要存更长的内容时得确认字段长度够接着在提交校验的分支里加一条排序题的答案必须包含全部选项且不重复统计层则要决定口径排序题通常不出饼图而是看“每个选项排在首位的次数”。这一圈改下来你对代码里哪些地方是“开着的”哪些是“焊死的”就有判断了。如果要做的是面向真实业务的改造我列几个优先级改造项价值改动面作答链接加短码链接短、便于分享小加一列 一个跳转接口答卷导出 Excel运营刚需中引入 EasyExcel按题目动态出列逻辑跳转长问卷体验大前后端都要改交叉分析按某题筛选分析深度中统计 SQL 加条件参数问卷模板复制重复建问卷省事小深拷贝问卷和题目优先做导出和复制这两个投入产出比最高而且不碰核心链路改坏了也不影响用户提交。逻辑跳转放最后因为它会同时改动作答页渲染、必答校验、统计口径三处是典型的高风险改造。验证方法上我的习惯是每次改完核心链路手动走一遍“新建 → 发布 → 无痕提交 → 重复提交 → 看统计 → 截止后再提交”这条完整链路六步缺一不可。自动化测试能覆盖大部分但重复提交和截止后提交这两个边界手动点一遍心里才有底。从那以后我每次改动提交接口都强制走一遍这六步哪怕只改了一个字段名——因为这类系统的错误往往不报错只是数字悄悄不对等发现的时候已经回收了几百份脏答卷了。希望帮到你。本文还有配套的精品资源点击获取
简介面向Java Web初学者与Spring Boot实战者的在线问卷调查系统源码包围绕问卷模板创建、问卷编辑发布、社交网络分享、结果统计与个人中心等模块提供从用户认证授权到RESTful接口设计的完整参考实现。包内共294个文件以100个Java源码、26个HTML页面、26个JavaScript脚本以及CSS、SQL、properties配置文件为主并含图片、字体、图标等静态资源压缩包约37.17MB前后端与数据库相关文件分布较清晰便于按模块查阅。目前已有269人学习下载适合用于课程设计、毕业设计或框架练手也可作为Spring Security鉴权、Spring Data JPA持久化与前后端联调的对照案例。读者可据此梳理Spring Boot项目的分层结构、实体与数据表映射、登录注册流程、问卷增删改查和图表统计的实现思路也能参考静态资源组织与接口联调方式快速搭建可运行的调查问卷应用原型。1. 从一份“回收了 87 张表格”的调研说起去年有个做市场的朋友找我说他们每季度做一次客户满意度调研问卷往群里一发回收上来是几十份填好的 Excel人工合并、去重、数票两天时间就搭进去了还容易数错。后来他们内部有人丢过来一份基于 Spring Boot 的在线问卷调查系统源码问能不能直接改改就用。我看完的第一反应是这类系统功能看着简单——建问卷、发链接、填、看统计但它真正难的地方从来不在页面上而在题目类型的扩展性、答卷的幂等控制、以及统计口径的一致性。这套源码把这三件事的骨架都搭好了Spring Boot MyBatis-Plus MySQL 的组合也很容易接手适合两类人一类是想拿它当毕设或课程项目底稿的学生另一类是真要在内部跑一份调研、又不想上 SaaS 的团队开发者。接下来我按自己拆项目的顺序从技术选型一路讲到怎么改。2. 定位与技术选型这套系统为什么用 Spring Boot 打底2.1 它解决的是“问卷全生命周期”不是“表单页”先把功能边界说清楚不然后面看代码容易迷路。这套系统的核心对象只有四个问卷Survey、题目Question、选项Option、答卷Answer。四个对象串起来是一条完整的状态链——新建问卷是草稿态配好题目后发布发布后生成一个可访问的作答入口用户提交后形成答卷记录最后按题目维度做聚合统计。中间还夹着两个容易被忽略但很关键的动作问卷截止超过时间窗或人为关闭后不再接收新答卷以及答卷去重同一个人对同一份问卷只能提交一次。所以它不是那种“拖拽生成一个表单、提交进数据库就完事”的轻量工具。你在源码里能看到问卷状态字段、开始结束时间、题目排序号、是否必答、答卷来源 IP 这些字段这些都是为“一次严肃的调研”准备的。如果只是想收集个报名信息用这套系统属于杀鸡用牛刀但只要涉及多选题、评分题、结果要出图表、还要防止有人刷票它的结构就比临时拼的表单合理得多。模块划分上源码大致是这么几块用户与权限登录、角色、问卷管理增删改查、发布、截止、题目管理题型、选项、排序、作答端渲染问卷、提交校验、统计端单题汇总、交叉筛选、导出。有些版本还会带一个简答的模板库或者问卷复制功能这个看你拿到的包不影响主干理解。你接手时最该先看的是问卷和题目这两块的 Service它们是整个系统的中枢。2.2 技术栈拆解每一层各自扛什么选型上没有花活是一套很典型的国内中小型管理系统组合好处是资料多、上手快、出问题好查。层次技术在这套系统里的职责Web 框架Spring Boot 2.x提供内嵌容器、自动配置、统一异常处理、拦截器持久层MyBatis-Plus单表 CRUD 走 BaseMapper复杂统计手写 XML数据库MySQL 5.7 / 8.0存问卷、题目、选项、答卷、答案明细视图层Thymeleaf 或 Vue Element管理端表格 作答端表单渲染权限拦截器 / Spring Security管理端登录态校验作答端通常放行统计图表ECharts单选多选出饼图柱状图评分题出均值这里有两个选型点值得单独说一下因为它们直接影响你后面改代码的手感。第一是 MyBatis-Plus 而不是纯 JPA。原因是统计查询太多比如“某问卷每道题的每个选项被选了多少次”这种 SQL 用 JPA 拼起来很别扭而 MyBatis 可以直接在 XML 里写一段带 GROUP BY 的原生 SQL改起来直观。代价是单表 CRUD 要靠代码生成或者手写 MapperPower by MyBatis-Plus 的BaseMapperT能省掉大部分样板代码所以常见做法是单表操作走BaseMapper聚合统计走自定义 XML。第二是作答端用服务端渲染还是前后端分离。这取决于你拿到的包但两种各有取舍Thymeleaf 渲染的好处是链接直接可访问、不需要额外部署前端工程缺点是题目动态渲染尤其是逻辑跳转写起来啰嗦Vue 版本的好处是题目组件化、交互流畅缺点是本地跑起来要同时起两个服务。如果你只是想快速验证功能优先找带 Thymeleaf 的那份如果要做二次开发、加复杂交互Vue 版本更值得投入。2.3 本地跑通从建库到看到第一份问卷跑起来的顺序不要乱先库后服务不然启动就报错。第一步建库字符集用utf8mb4这个别省问卷标题里出现表情符号或者生僻字时utf8会直接抛异常这是我踩过的坑。第二步导入源码里的 SQL 脚本一般包含建表语句和一条管理员初始数据。第三步改application.yml里的数据源第四步启动。server: port: 8080 spring: datasource: url: jdbc:mysql://127.0.0.1:3306/survey?useUnicodetruecharacterEncodingutf8mb4serverTimezoneAsia/Shanghai username: root password: 你的密码 driver-class-name: com.mysql.cj.jdbc.Driver thymeleaf: cache: false # 开发期关掉模板缓存改页面不用重启 mybatis-plus: mapper-locations: classpath*:mapper/*.xml configuration: map-underscore-to-camel-case: true # survey_id 自动映射 surveyId配置里有几个参数值得留意。serverTimezone必须显式指定否则 MySQL 8 驱动在某些环境下会把时间整体偏移 8 小时表现出来就是“刚发布的问卷显示已截止”非常唬人。map-underscore-to-camel-case打开后数据库的下划线字段才能自动映射到实体的驼峰属性如果关掉你会看到一堆字段全是 null但 SQL 明明查出了数据。thymeleaf.cache在开发期关掉改 HTML 刷新即生效省掉反复重启。启动命令就一条如果包里有 Maven Wrapper 就用 wrapper# 打包并启动跳过测试加快首次启动 ./mvnw clean package -DskipTests java -jar target/survey-0.0.1-SNAPSHOT.jar启动成功后访问http://localhost:8080用初始管理员账号登录进管理端新建一份问卷、加两道题、点发布然后用无痕窗口打开作答链接提交一份再回管理端看统计页。这条链路走通说明库、服务、模板、统计四个环节都是通的后面再看代码就有底了。3. 目录结构与数据模型五张表撑起整个系统3.1 包结构按层切还是按业务切源码的包结构大概率是经典的三层切法这也是这类项目最常见的组织方式com.example.survey ├── controller # 管理端与作答端接口 ├── service # 业务逻辑接口 impl ├── mapper # MyBatis-Plus Mapper 接口 ├── entity # 数据库实体 ├── dto # 请求参数如 SubmitDTO、SurveyQueryDTO ├── vo # 返回给前端的聚合对象如 StatVO ├── config # 拦截器、跨域、MyBatis-Plus 配置 └── common # 统一返回体、异常、工具类说句实在话按层切在项目初期没什么问题但写到后面你会发现SurveyService越来越胖发布、复制、统计、导出全塞在一起。我的习惯是接手后先别急着重构等业务稳定了再把“统计”单独拆一个StatService把“导入导出”拆一个ExportService。因为统计逻辑最容易被反复改口径独立出来之后改动半径小也不会误伤发布流程。另外提醒一下entity和dto一定要分开。很多初版代码图省事前端参数直接用实体接结果提交答卷时前端多传一个id就把已有题目覆盖了。这个坑在答题接口上尤其危险因为答题端是公开访问的参数完全不可信。3.2 五张核心表字段设计的取舍建表脚本是理解这个项目最快的方式。核心就五张表我把关键字段摘出来CREATE TABLE t_survey ( id BIGINT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(120) NOT NULL, description VARCHAR(500) NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0草稿 1已发布 2已截止, start_time DATETIME NULL COMMENT 为空表示不限开始, end_time DATETIME NULL COMMENT 为空表示不限结束, creator_id BIGINT NOT NULL, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, deleted TINYINT NOT NULL DEFAULT 0 COMMENT 逻辑删除标记 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE t_question ( id BIGINT PRIMARY KEY AUTO_INCREMENT, survey_id BIGINT NOT NULL, type TINYINT NOT NULL COMMENT 1单选 2多选 3填空 4评分 5矩阵, title VARCHAR(255) NOT NULL, required TINYINT NOT NULL DEFAULT 0, sort_no INT NOT NULL DEFAULT 0, options_json TEXT NULL COMMENT 选项列表JSON 数组, KEY idx_survey (survey_id, sort_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE t_answer ( id BIGINT PRIMARY KEY AUTO_INCREMENT, survey_id BIGINT NOT NULL, user_key VARCHAR(64) NOT NULL COMMENT 登录用户ID或匿名设备指纹, submit_ip VARCHAR(45) NULL, submit_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_survey_user (survey_id, user_key) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE t_answer_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, answer_id BIGINT NOT NULL, question_id BIGINT NOT NULL, content VARCHAR(1000) NULL COMMENT 文本答案, option_keys VARCHAR(255) NULL COMMENT 选中的选项 key多选用逗号分隔, score INT NULL COMMENT 评分题的分数, KEY idx_question (question_id), KEY idx_answer (answer_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这几张表的字段设计里有三个决定值得展开讲。第一个是t_answer上的唯一索引uk_survey_user。这个索引是防刷票的最后一道闸门比起在 Service 里先查后插靠数据库唯一约束更可靠因为并发下“先查再插”会有窗口期两个人同时提交能双双插进去。代价是插入冲突会抛DuplicateKeyException你得在全局异常处理里把它翻译成“您已提交过本问卷”而不是把 500 抛给用户。第二个是t_question.options_json用 JSON 存选项。这个选择在问卷系统里非常常见原因是选项永远跟着题目走从不单独查询拆成独立表反而要每次 JOIN 一次。但它有个代价统计时没法直接 JOIN 选项表选项的展示文案得从 JSON 里解析出来再和聚合结果拼。这在代码里体现为统计 Service 里多一步内存合并不算大问题。第三个是deleted逻辑删除。问卷一旦发布过、有人答过物理删除就会把答卷变成孤儿数据所以逻辑删除是必须的。注意配合 MyBatis-Plus 的TableLogic注解使用否则你手写的 SQL 还得自己加deleted 0漏一处就查出脏数据。3.3 题目类型怎么扩展一个枚举撑起五种题型题型扩展性是这个系统能不能长期用的关键。源码里一般会有一个QuestionType枚举把题型和它的校验规则、渲染方式绑定在一起public enum QuestionType { SINGLE(1, 单选), MULTI(2, 多选), TEXT(3, 填空), SCORE(4, 评分), MATRIX(5, 矩阵); private final int code; private final String label; QuestionType(int code, String label) { this.code code; this.label label; } public static QuestionType of(int code) { for (QuestionType t : values()) { if (t.code code) return t; } throw new BizException(未知题型: code); } }这段代码本身没什么技术含量但它定了一个规矩题型用 code 存库、用枚举在内存里流转前端传的永远是 code服务端永远先经过of()翻译一次。这个规矩的价值在于将来加“排序题”“文件上传题”时你只需要在枚举里加一项然后在提交校验和统计聚合两处各补一个分支而不是满项目搜type 1。我在别的项目里见过反面例子题型判断直接写成if (q.getType() 1)散落在六七个类里后来要加一种题型改了十几处还漏了两处上线后统计页直接空白。血泪经验就是凡是这种固定集合的字段第一件事就是把它变成枚举哪怕初期只有两个值。4. 核心链路拆解一次作答提交到底走了哪些代码4.1 发布与截止状态机比 if 判断靠谱问卷的状态流转看着简单实际上是最容易写乱的地方。草稿可以编辑题目已发布不能改题目结构改了会让历史答卷对不上已截止只能看统计。如果不用状态机代码里就会出现“这个方法里判断了三次状态”的情况。常见做法是把状态判断收拢成一个校验方法public void checkPublishable(Survey survey) { if (survey.getStatus() ! SurveyStatus.DRAFT.getCode()) { throw new BizException(只有草稿状态的问卷可以发布); } Long count questionMapper.selectCount( new LambdaQueryWrapperQuestion().eq(Question::getSurveyId, survey.getId())); if (count null || count 0) { throw new BizException(问卷至少需要一道题目才能发布); } // 单选题必须有选项这里只做抽样校验完整校验遍历题目 }checkPublishable里做了两件事校验当前状态是否允许发布以及校验问卷内容是否完整。之所以把内容校验放在发布这一步而不是保存草稿时是因为草稿本来就是半成品你没法要求用户一次填完但发布出去意味着要给别人答了这时候一道没有选项的单选题会让作答页直接崩掉。截止逻辑同理不要写成定时任务扫描虽然可以更稳的做法是在作答入口处做时间窗判断。因为定时任务有执行间隔中间那几分钟用户还是能提交而入口处判断是即时的。这两条一起用最保险入口判断拦住正常流量定时任务负责把过期问卷的状态刷成“已截止”让列表页显示正确。4.2 作答提交事务、幂等、校验三件套这是整个系统最容易出问题的接口因为它同时要处理并发、事务和用户输入校验。我把典型实现拆开看Transactional(rollbackFor Exception.class) public Long submit(SubmitDTO dto, String userKey, String ip) { Survey survey surveyMapper.selectById(dto.getSurveyId()); // 1. 状态与时间窗校验 if (survey null || survey.getStatus() ! SurveyStatus.PUBLISHED.getCode()) { throw new BizException(问卷不存在或未发布); } LocalDateTime now LocalDateTime.now(); if (survey.getEndTime() ! null now.isAfter(survey.getEndTime())) { throw new BizException(问卷已截止); } // 2. 落主表唯一索引兜底防重复提交 Answer answer new Answer(); answer.setSurveyId(dto.getSurveyId()); answer.setUserKey(userKey); answer.setSubmitIp(ip); try { answerMapper.insert(answer); } catch (DuplicateKeyException e) { throw new BizException(您已提交过本问卷); } // 3. 逐题落明细必答题在这里兜底校验 ListQuestion questions questionMapper.selectList( new LambdaQueryWrapperQuestion().eq(Question::getSurveyId, dto.getSurveyId())); for (Question q : questions) { AnswerItem item buildItem(answer.getId(), q, dto.getItem(q.getId())); answerItemMapper.insert(item); } return answer.getId(); }代码不长但三个点必须说透。事务边界整个方法包在一个事务里任何一道题落库失败都整体回滚避免出现“主表有记录但明细缺一半”的脏数据。rollbackFor Exception.class不能省因为默认只回滚RuntimeException如果你自定义的BizException继承了Exception而不是RuntimeException异常抛出去事务却不回滚这个问题极难排查。幂等控制靠唯一索引而不是先查后插。注意这里捕获的是DuplicateKeyException只有真正插入时撞索引才触发并发下两个人同时点提交数据库只放行一个。userKey的取值是个设计点——登录用户用用户 ID匿名用户用设备指纹或者前端生成并落到 localStorage 的 UUID后者防不住刻意刷票但能挡住正常用户的手抖重复提交。真要做严格的一人一票得靠登录态。必答校验在遍历题目时对required 1的题判断答案是否为空为空直接抛业务异常。这一步必须在服务端做前端那点required属性随手就能绕过不能当安全边界。4.3 统计聚合别在 Java 里数循环统计页是这类系统的门面也是最容易写出性能问题的地方。我见过一种写法把某个问卷的所有answer_item一次性查进内存然后 for 循环按questionId分组、再按选项计数。问卷几十份的时候没问题上千份之后内存直接顶上去而且每次刷新都全量算一遍。正确做法是把聚合下推到数据库-- 单选/多选题每个题目下每个选项被选中的次数 SELECT ai.question_id, o.opt_key, COUNT(*) AS cnt FROM t_answer_item ai JOIN t_question q ON q.id ai.question_id JOIN t_answer a ON a.id ai.answer_id WHERE a.survey_id #{surveyId} AND q.type IN (1, 2) AND FIND_IN_SET(o.opt_key, ai.option_keys) 0 GROUP BY ai.question_id, o.opt_key;不过这段 SQL 有个前提——选项得能 JOIN 出来。前面说了选项存在 JSON 字段里所以实际代码里通常是两步先用一条 SQL 把各选项的计数查出来再在 Service 里从options_json解析出选项文案按 key 合并成前端要的[{name, value}]结构。多选因为存在option_keys里是逗号分隔的字符串用FIND_IN_SET展开这个函数用不上索引数据量大的时候会慢这是这套设计的固有代价。评分题的口径又不一样不能数选项要算均值和分布SELECT question_id, AVG(score) AS avg_score, MIN(score) AS min_score, MAX(score) AS max_score, COUNT(*) AS total FROM t_answer_item WHERE question_id IN (#{ids}) AND score IS NOT NULL GROUP BY question_id;统计里最容易被忽略的是分母。一道非必答题如果 100 人里有 20 人没填那这道题的有效样本是 80 不是 100百分比必须按 80 算。这个口径要在代码里显式处理否则统计出来的比例加起来不到 100%运营同事会来问你为什么。4.4 作答页渲染题目顺序与跳转逻辑作答端要做的不只是把题目循环渲染出来还得处理排序和条件跳转。排序靠sort_noSQL 里ORDER BY sort_no ASC即可简单。真正麻烦的是逻辑跳转——比如“第 3 题选了 A 就跳到第 5 题”。这类功能在源码里可能没有但属于二次开发的高频需求。实现思路是在题目上挂一个next_rule字段JSON存“选了某选项后跳转到哪道题”前端在选项变化时读取规则决定下一步渲染哪题。这里有个血泪教训跳转逻辑一定要前后端一致前端跳了但后端按全量题目校验必答用户就会被卡在“你有一道没见过的题没填”。正确做法是后端在提交时按同一套跳转规则算出“实际生效的题目集合”只对这个集合做必答校验。这种前后端规则各写一遍、又不同步的情况是这类系统上线后最常见的投诉来源。5. 避坑与排查五个真实踩过的坑5.1 数据层时间差 8 小时与中文变问号现象刚发布的问卷作答页直接提示“问卷已截止”可结束时间明明设在一周后。原因JDBC URL 没配serverTimezoneMySQL 8 驱动按 UTC 解析写入的时间和读取的时间差了 8 小时。解决URL 里显式加serverTimezoneAsia/Shanghai同时确认数据库服务器的时区两者要对齐。这个问题在本地开发机上可能不出现因为机器时区恰好一致一部署到别的环境就爆属于典型的“环境玄学”。现象二问卷标题里的中文存进库变成问号或者乱码。原因建库时用了utf8字符集连接串也没指定characterEncoding。解决建库语句统一DEFAULT CHARSETutf8mb4连接串带上characterEncodingutf8mb4三处库、表、连接必须一致缺一处都可能出问题。5.2 提交链路重复提交与事务不回滚现象网络卡顿时用户连点两次提交数据库里出现两条同问卷的答卷统计数字翻倍。原因只在 Service 里做了“先查是否已提交”两个请求并发进来时都查到“没提交过”。解决加唯一索引uk_survey_user兜底同时前端提交按钮点击后置灰后端把DuplicateKeyException捕获后返回友好提示。索引是硬约束代码是软约束两个都要。现象二提交时某道题校验失败抛出业务异常用户重新提交后发现主表多了一条答卷记录但没有明细。原因自定义异常继承的是Exception而Transactional默认只回滚RuntimeException。解决要么让业务异常继承RuntimeException要么显式写rollbackFor Exception.class。这个坑不看日志根本发现不了因为接口返回的是正常的错误提示。5.3 统计与展示口径错位和空数据崩页现象管理端统计页某道题百分比加起来是 92%运营来问是不是算错了。原因这道题非必答有 8% 的人跳过分母用了总答卷数而不是该题的有效答卷数。解决聚合 SQL 里按question_id分组时分母取该题的非空记录数Java 侧不要再二次换算。现象二新发布的问卷还没人答点开统计页直接白屏报 500。原因图表渲染时对空数组取[0]或者对空结果做除法。解决统计接口在没有数据时返回结构完整但数值为 0 的对象前端图表组件做空数据兜底。这类问题在测试阶段很难发现因为测试数据总是有的上线后第一批用户点进来才发现。现象三多选题选项文案和计数对不上。原因选项存在 JSON 里统计结果按 key 合并时用了String比较但两边的 key 大小写或者空格不一致。解决选项 key 在保存时就统一成小写无空格的固定格式比如opt_1、opt_2不要用选项文案本身当 key。6. 二次开发先加一道题型再谈重构接手这类源码我的建议是先做一次“最小改造”来熟悉结构而不是上来就重构。最合适的练手目标是加一种题型——比如“排序题”或者“文件上传题”。整个改造路径能让你把实体、Mapper、Service、前端渲染全走一遍而且改动可控。具体步骤是这样先在QuestionType枚举里加一项然后在t_question表上不用改结构options_json复用但t_answer_item需要存更长的内容时得确认字段长度够接着在提交校验的分支里加一条排序题的答案必须包含全部选项且不重复统计层则要决定口径排序题通常不出饼图而是看“每个选项排在首位的次数”。这一圈改下来你对代码里哪些地方是“开着的”哪些是“焊死的”就有判断了。如果要做的是面向真实业务的改造我列几个优先级改造项价值改动面作答链接加短码链接短、便于分享小加一列 一个跳转接口答卷导出 Excel运营刚需中引入 EasyExcel按题目动态出列逻辑跳转长问卷体验大前后端都要改交叉分析按某题筛选分析深度中统计 SQL 加条件参数问卷模板复制重复建问卷省事小深拷贝问卷和题目优先做导出和复制这两个投入产出比最高而且不碰核心链路改坏了也不影响用户提交。逻辑跳转放最后因为它会同时改动作答页渲染、必答校验、统计口径三处是典型的高风险改造。验证方法上我的习惯是每次改完核心链路手动走一遍“新建 → 发布 → 无痕提交 → 重复提交 → 看统计 → 截止后再提交”这条完整链路六步缺一不可。自动化测试能覆盖大部分但重复提交和截止后提交这两个边界手动点一遍心里才有底。从那以后我每次改动提交接口都强制走一遍这六步哪怕只改了一个字段名——因为这类系统的错误往往不报错只是数字悄悄不对等发现的时候已经回收了几百份脏答卷了。希望帮到你。本文还有配套的精品资源点击获取
