每次带学生做毕设或者帮朋友规划练手项目问卷调查系统都是我张口就来的推荐选题。这个题目听起来普通但真要把创建问卷—发布—填写—回收—统计这一整条链路做扎实从前端交互到后端事务从数据库设计到部署上线几乎所有Web开发的核心环节都会碰一遍。很多人低估了它的复杂度觉得不就是增删改查嘛——等真上手做编辑器、做动态表单渲染、做统计聚合的时候才发现里面全是细节。我这次做完一套完整的 SpringBoot Vue 在线问卷调查系统之后最大的感受是这类人人见过、天天在用的业务系统恰恰是最能锻炼工程能力的题目。它不要求你发明新概念但要求你把每个常规功能做到真的能用、真的好用。这篇文章我把自己从建表到部署的全过程、踩过的坑、几个关键模块的设计思路全部整理出来给正在做类似选题的朋友一个可复现的参考。1. 选题逻辑这个老题目为什么值得重新做一遍1.1 表面是增删改查实际是一套完整业务闭环问卷系统的业务链路其实非常典型管理员创建一份问卷向问卷里添加不同类型的题目发布后生成一个可访问的链接普通用户打开链接填写答案后台回收答案并自动生成统计报表。这四步串起来就是一个完整的、有明确用户角色的业务闭环。很多初学者会把问卷系统简化成一张问卷表 一张答卷表写几个接口草草了事。但等你真的细想每个环节就会发现里面藏着不少值得认真对待的问题一份问卷里可以有很多道题题的顺序怎么控制题型不同数据结构怎么统一单选题、多选题、填空题、评分题前端要怎么根据题型动态渲染不同的输入控件问卷发布之后还能不能改题目改了之后已经回收的答卷数据怎么处理统计报表怎么算单选是占比填空是要把所有文本列出来多选要计频次怎么用SQL高效拿到这些结果任何一个问题展开都能聊出一堆设计决策。这就是为什么我说这个题目老但不旧它逼着你不要停留在CRUD表面而是要认真做数据建模和业务状态设计。1.2 用户角色与核心流程梳理我做的这套系统设计了两个端管理端登录后使用问卷的创建、编辑、发布、关闭、删除查看答卷数据管理问卷列表。填写端无需登录通过链接直接打开问卷逐题作答并提交。这个角色划分本身就是一个重要的设计决策填写端不需要登录。如果非要强制注册才能填问卷那用户的填写意愿会大幅降低而且这套系统就凭空多出了注册流程和用户关系绑定的复杂度对核心业务没有实质帮助。所以我的方案是——管理端维护一份管理员账号用简单的 JWT 做登录态校验填写端通过一个随机的问卷标识不是自增ID访问问卷提交时只保留作答内容和一个防刷的时间戳不做任何身份绑定。核心流程我总结成一张状态流转草稿(新建) - 发布 - 进行中 - 关闭 | | --- 编辑 --- --- 不可填写可看统计草稿状态下管理员可以任意增删改题目点击发布后问卷进入进行中状态此时题目结构锁定不可再修改这一点后面会详细讲为什么。收集到足够数据后管理员可以手动关闭问卷关闭后填写端打开链接只能看到问卷已停止收集的提示但管理端依然可以查看统计结果和原始答案。2. 技术选型SpringBoot Vue MySQL 的分工边界选型这件事很多人觉得大家用什么我就用什么但我觉得清楚每一项技术在这个项目里到底解决什么问题比跟风更重要。这套系统的选型逻辑是这样的2.1 后端SpringBoot负责什么、不负责什么SpringBoot 在这套系统里的定位是稳定的业务后端。它负责三件事提供 RESTful API供 Vue 前端调用问卷的增删改查、答卷提交、统计查询。做数据校验和事务管理保证一份答卷的所有题目要么全部写入成功要么全部不写入。做登录态的签发与校验用 JWT 保护管理端接口。它不需要负责的事情也值得说一句不需要做页面渲染。传统做法是 Thymeleaf 模板在后端拼HTML前后端不分离我这次选择了彻底的前后端分离前端用 Vue 构建单页应用后端只返回 JSON。这样做的好处是职责清晰后端开发时可以完全不关心页面长什么样用 Postman 或者 Apifox 把接口调试好前端可以独立用 mock 数据跑页面最后联调时再对接。整个开发节奏会舒服很多。2.2 前端Vue2 / Vue3 / ElementUI 的组合选择前端我选了 Vue2 ElementUI你可能想问为什么不直接上 Vue3。坦白说如果你是从零开始学直接上 Vue3 Element Plus 完全没问题Vue3 是当前主流趋势。但如果是课程设计或者毕设场景有一个现实因素要考虑网上能找到的参考资料、学长学姐留下的代码、老师的熟悉程度Vue2 都更多。我在实际开发中没有用到特别依赖 Vue3 新特性的功能Vue2 的组合式 API 也够用遇到问题时的排查成本更低。我的项目结构大致是Vue Router 做前端路由登录页、问卷列表页、问卷编辑页、问卷填写页、统计页。Axios 做 HTTP 请求封装统一处理 token 注入和错误提示。ElementUI 提供表格、表单、日期选择、消息提示等基础组件。ECharts 做统计模块的图表渲染。2.3 为什么不需要Redis和消息队列有些同学一上来就想着加 Redis、加 RabbitMQ仿佛不用分布式组件就显得项目不够高级。我的观点很明确一个在线问卷系统一天的答卷量能有多少几百人同时填写已经是很大的并发量了单机 MySQL 扛住这种量级没有任何压力。引入 Redis 做缓存加一层序列化和缓存一致性的复杂度但它解决的问题在这个业务场景里根本不存在。当然有一件事我确实做了防刷处理——填写端提交时校验一个带时间戳的签名参数防止调用方直接抓接口暴力提交大量垃圾数据。这种简单方案比引入消息队列削峰实用得多。技术选型不是堆料而是每一个组件都有它存在理由。一个普通问卷系统用上 MySQL SpringBoot Vue 就已经是恰到好处的组合了。3. 数据库设计动态问卷如何用四张表承载数据库是这个项目的重中之重。我见过很多新手做问卷系统第一版就把表设计错了后面写代码越写越别扭。核心原因只有一个——问卷的题目结构是动态的但你用静态的思维设计了表。3.1 四张核心表的结构设计我把数据模型拆成了四张表问卷表、题目表、答卷记录表、答卷详情表。问卷表survey记录问卷本身的基本信息字段类型说明idbigint主键titlevarchar(100)问卷标题descriptiontext问卷说明statustinyint0草稿 / 1进行中 / 2已关闭survey_codevarchar(32)随机短码用于生成填写链接create_bybigint创建人IDcreate_timedatetime创建时间update_timedatetime修改时间题目表question记录每份问卷下的所有题目字段类型说明idbigint主键survey_idbigint所属问卷question_typetinyint题型1单选/2多选/3填空/4评分titlevarchar(255)题干is_requiredtinyint是否必填sort_orderint题目顺序optionsjson选项内容JSON数组非选择题为空这里有个很关键的取舍就是 options 字段我把单选、多选题的选项直接存成了一个 JSON 数组。按数据库三范式来说这看起来是反范式设计但实际上它更贴合业务——题目和选项是同时出现、同时修改、同时删除的把它们拆成两张表反而没有意义下一节展开说。答卷记录表answer_record对应一次完整的问卷提交字段类型说明idbigint主键survey_idbigint问卷IDsubmit_tokenvarchar(32)防重提交tokenanswerer_ipvarchar(64)提交者IPcreate_timedatetime提交时间答卷详情表answer_detail存每一道题的具体答案字段类型说明idbigint主键record_idbigint答卷记录IDquestion_idbigint题目IDanswer_valuetext答案内容3.2 选项为什么用 JSON 而不是单独建一张选项表这是我和很多教科书式设计最大的分歧点。教科书会教你把选项拆成一张 option 表一个选项一行用 question_id 关联再按 sort_no 排序。这样设计在理论上没有任何问题但你在实际编码时会发现问卷管理端做编辑操作时前端传来的数据结构是这道题包含哪些选项这样一个整体。如果你用选项表后端要把前端传来的选项数组逐个比对数据库里已有的选项判断哪些新增、哪些删除、哪些更新——三行代码能解决的事情被你写成了几十行。用 JSON 字段存储选项之后后端代码极其简洁整个题目作为一个对象整体更新options 字段整体替换。在 MySQL 5.7 以上版本中 JSON 字段可以支持索引查询对于统计某个选项被选了多少次这种需求虽然不能用索引但数据量不大时用 JSON_CONTAINS 或者直接在 Java 内存里过滤都很快。提示这个设计取舍的前提是选项和题目同生命周期。如果你将来要做选项级别的独立分析或者多个题目共享选项池那就应该拆表。设计没有绝对的对错看业务侧重。3.3 答卷记录拆分两张表的原因一行一个答题卡把答卷拆成 answer_record 和 answer_detail 两张表可能很多人第一反应是冗余。但你仔细想一下一次提交会包含十几道题的答案。如果把这些答案全部用逗号拼接塞在一个字段里很多偷懒的做法统计的时候要把字符串拆开解析SQL 根本没法高效聚合。如果按一条记录存一道题的答案来设计虽然提交时一次要插入 N 行但统计时可以直接GROUP BY question_id拿到每个题目的所有答案逻辑非常清晰。而且这种拆法还有一个额外的好处当你想导出某个用户填了什么的时候只需要按 record_id 过滤就可以拼出这个人的完整答题卡当你想算某道题有多少人选了A的时候只需要按 question_id 过滤。两个维度的查询都很快因为每次查询都用到了索引列。四张表的关系用一个比较形象的说法offer 表是试卷question 表是试卷上的每一道题answer_record 是一个学生交上来的答题卡只写了名字和学号answer_detail 是答题卡上每一道题的答案。你把问卷业务想成考试数据模型一下就清晰了。4. 后端落地从建表到发布问卷的接口链路数据库设计好之后后端的开发就顺畅多了。SpringBoot 项目的标准分层——Controller、Service、Mapper——按部就班往下填即可。这一节我挑几个最核心的模块来拆解因为这几个就是问卷系统的灵魂。4.1 统一接口返回与全局异常处理后端接口我不会赶时间直接返回裸数据而是封装了一个统一的返回体public class ResultT { private Integer code; private String message; private T data; }code 为 200 表示成功其他为业务错误码。这样前端的 Axios 拦截器可以统一处理读到 code 为 200 就正常返回 data读到 401 就自动跳登录页读到其他错误码就弹出 message 提示。配合全局异常处理器业务代码里只需要throw new BizException(问卷不存在)前端就能看到对应的错误信息。这套封装虽然多写了一点模板代码但联调阶段的效率提升非常明显前端不用在几十个接口里分别处理错误格式。4.2 问卷的 CRUD 与发布状态机问卷编辑相关的接口最核心的一点是状态约束。我的约定是草稿状态下可以修改标题、说明可以增删改题目。发布状态下不可以修改题目结构只允许修改问卷说明、关闭问卷。关闭状态下不可进行任何编辑操作只能查看。这个约束我在 Service 层用一段简单的状态判断来实现if (survey.getStatus() ! SurveyStatus.DRAFT) { throw new BizException(问卷已发布题目结构不可修改); }在保存问卷时前端会把整份问卷的题目数组传过来后端用事务包裹先删除该问卷下的所有旧题目再重新插入新的题目列表。这种先删后插的策略在草稿阶段非常高效——因为草稿状态的问卷还没有任何答卷数据删了重建不会影响数据一致性代码也远比逐题 diff 增删改简单。发布问卷时后端只更新一个状态字段同时生成一个随机的 survey_codesurvey.setStatus(SurveyStatus.PUBLISHED); survey.setSurveyCode(UUID.randomUUID().toString().replace(-, ).substring(0, 8)); survey.setPublishTime(new Date());这个 survey_code 就是填写链接的唯一标识。前端拿到之后拼成http://host/fill/xxxx这样一个链接转发给填答者。4.3 答卷提交一次保存多张表的正确姿势答卷提交的接口是整个后端业务逻辑里最值得写清楚的地方。它不像普通 CRUD 那样一次操作一张表而是需要在一个事务里完成多张表的写入Transactional public void submitAnswer(SurveySubmitDTO dto) { // 1. 校验问卷状态是否为进行中 Survey survey surveyMapper.selectById(dto.getSurveyId()); if (survey null || survey.getStatus() ! 1) { throw new BizException(问卷不存在或已停止收集); } // 2. 校验提交 token 防止重复提交 if (answerRecordMapper.countByToken(dto.getSubmitToken()) 0) { throw new BizException(请勿重复提交); } // 3. 插入答卷主记录 AnswerRecord record new AnswerRecord(); record.setSurveyId(survey.getId()); record.setSubmitToken(dto.getSubmitToken()); answerRecordMapper.insert(record); // 4. 循环插入每道题的答案详情 for (AnswerDetailDTO detail : dto.getAnswers()) { AnswerDetail answerDetail new AnswerDetail(); answerDetail.setRecordId(record.getId()); answerDetail.setQuestionId(detail.getQuestionId()); answerDetail.setAnswerValue(detail.getAnswerValue()); answerDetailMapper.insert(answerDetail); } }这里有两个细节值得注意。第一Transactional保证了主记录和详情记录的一致写入不会出现头插进去了但答案没写进去的脏数据。第二防重复提交我用了前端传来的一个随机 token它在前端进入问卷页时生成并存在变量里用户每次刷新页面都会重新生成。如果用户手滑点了两次提交按钮第二次请求就会因为token 已存在而被拦截。这个方案比单纯的按钮置灰可靠得多因为用户可以用 F5 刷新之后再次提交。4.4 统计接口GROUP BY 撑起的数据看板统计模块的后端实现是把这个系统从能跑升级到有用的分水岭。我的统计接口返回的数据结构是{ questionId: 1, title: 你最常用的开发语言是, type: 1, total: 120, options: [Java, Python, Go], counts: [45, 60, 15], percentages: [37.5, 50.0, 12.5] }后端拿到这个结构的分三步走。第一步查题目和选项信息选项直接从 question 表的 options JSON 字段里取。第二步查这个题目下所有的 answer_valueListString answers answerDetailMapper.selectAnswerValuesByQuestionId(questionId);第三步在 Java 内存里做统计。你可能会想为什么不用GROUP BY answer_value直接在 SQL 里分组原因很直接——判断题的答案可能是A填空题的答案是几十种不同的文本。多选题的答案如果存的是A,B,C这样的逗号拼接字符串SQL 分组根本分不对。与其在 SQL 层绕来绕去不如把原始答案查出来在 Java 里按逗号拆分、去重、计数逻辑所见即所得反而不会出错。等数据量真的到了百万级再考虑把所有聚合都下沉到 SQL 或者引入分析型数据库。在毕业设计、企业内部小工具这个量级上这种用计算资源换开发效率的方式是性价比最高的。5. 前端实现编辑器、填写页与统计看板如果说后端的主体是数据模型设计那前端的主体就是动态表单渲染。这是两个端共通的核心难点。问卷的题目类型是不同的你怎么让 Vue 根据每道题的 type 字段渲染出对应的输入控件这是问卷系统前端要解决的头号问题。5.1 项目骨架与路由设计我用 Vue CLI 初始化的项目路由设计如下/login 登录页 /survey/list 问卷列表管理端 /survey/edit/:id 问卷编辑器管理端:id为new表示新建 /fill/:code 问卷填写页无需登录 /survey/stats/:id 统计看板管理端管理端所有页面都挂在同一个布局组件下通过 Vue Router 的全局前置守卫做登录校验router.beforeEach((to, from, next) { if (to.path /login) { next(); return; } const token localStorage.getItem(token); if (!token) { next(/login); return; } next(); });填写页/fill/:code不需要登录它通过 URL 里的 code 参数向后端换取问卷详情。注意这里我用的是 survey_code 而不是自增ID避免用户通过遍历 ID 看到不相关的问卷。5.2 问卷填写页的动态表单渲染问卷填写页拿到后端返回的问卷详情后数据结构长这样{ title: 程序员生活方式调查, description: 感谢你参与本次调查, questions: [ { id: 1, type: 1, title: 你的工作年限, required: true, options: [1年以下, 1-3年, 3-5年, 5年以上] }, { id: 2, type: 2, title: 你常用的开发语言, required: true, options: [Java, Python, Go, JavaScript] }, { id: 3, type: 3, title: 你接下来的学习计划, required: false, options: [] }, { id: 4, type: 4, title: 你对当前工作的满意程度, required: true, options: [] } ] }页面拿到这个结构之后用v-for遍历渲染div v-forq in survey.questions :keyq.id classquestion-item div classquestion-title span v-ifq.required classrequired-mark*/span {{ q.title }} /div !-- 单选题 -- el-radio-group v-ifq.type 1 v-modelanswers[q.id] el-radio v-foropt in q.options :keyopt :labelopt{{ opt }}/el-radio /el-radio-group !-- 多选题 -- el-checkbox-group v-ifq.type 2 v-modelanswers[q.id] el-checkbox v-foropt in q.options :keyopt :labelopt{{ opt }}/el-checkbox /el-checkbox-group !-- 填空题 -- el-input v-ifq.type 3 v-modelanswers[q.id] typetextarea / !-- 评分题 -- el-rate v-ifq.type 4 v-modelanswers[q.id] / /div这个地方的设计核心是我们用一个对象answers来收集所有答案key 是题目ID。因为 Vue 的响应式机制对对象新增属性有坑我初始化时就把answers里每个题目的 key 都预置好了避免后续赋值不触发更新的问题。提交时把answers对象通过Object.keys()转成数组传给后端即可。校验必填的逻辑也在提交时统一做遍历所有必填题如果 answers[q.id] 为空就提示并且自动滚动到第一道未填写的题目位置。5.3 问卷编辑器JSON 数据驱动的题型管理问卷编辑器是整个前端最复杂的模块。我的编辑器把每道题当作一张卡片卡片左侧是题目内容和选项右侧是操作按钮上移、下移、编辑、删除、复制最下方是添加题目按钮点开可以选择题型。编辑器里的数据模型非常简单form: { title: , description: , questions: [ { id: null, type: 1, title: , required: true, options: [选项1, 选项2] } ] }添加题目时向 questions 数组 push 一个新对象type 决定了该题型默认带几个选项addQuestion(type) { const question { id: null, type: type, title: , required: true, options: [] }; if (type 1 || type 2) { question.options [选项1, 选项2]; } this.form.questions.push(question); }编辑选项时直接修改对应索引的 options 元素el-input v-for(opt, index) in q.options :keyindex v-modelq.options[index] placeholder请输入选项内容 el-button slotappend clickaddOption(q)添加/el-button el-button slotappend clickremoveOption(q, index)删除/el-button /el-input由于数据模型是嵌套的操作起来非常顺手不需要做任何 DOM 层面的操作。保存时整个 form 对象直接 POST 给后端后端先删后插更新问卷和所有题目。这套方案是我实测下来、改动量最小且最不容易出 bug 的编辑器实现方式。编辑器里还对排序做了处理。我没有引入 vuedraggable 拖拽排序因为那个库在 ElementUI 表格里的拖拽体验其实一般而是用了更朴素的上移、下移按钮。每点击一次交换两个题目的 sort_order 值同时交换它们在数组里的位置。代码量很少但够用且稳定。如果你想做拖拽排序vuedraggable 是可以实现的但要多处理一层拖拽结束的回调、样式错位等问题投入产出比一般。5.4 统计页面的可视化呈现统计页的前端我用了 ECharts 来做图表渲染。整体布局是上面一份问卷的标题和概览信息参与人数、题目总数、平均完成时间中间按题目顺序依次展示每道题的统计卡片。单选、多选和评分题用饼图或柱状图展示分布填空题没有选项分布就直接用列表展示所有原始答案。为了实现这个效果我在统计接口返回数据结构里加了 questionType 字段前端根据类型不同决定渲染图表还是文本列表renderChart(question) { const chartData question.options.map((opt, index) ({ name: opt, value: question.counts[index] })); this.$nextTick(() { const chart echarts.init(this.$refs[chart-${question.id}][0]); chart.setOption({ tooltip: { trigger: item }, series: [{ type: pie, radius: 60%, data: chartData }] }); }); }有一点经验之谈ECharts 在v-for循环里渲染时this.$refs获取到的可能是一个数组而且必须在 DOM 渲染完成之后$nextTick再初始化否则图表容器拿不到尺寸。我在这里踩过好几次空指针的坑原因都是在数据还没加载完时就去初始化图表。6. 前后端联调与生产部署6.1 跨域问题从烦人到理解它前端项目和后端项目分开跑一个是localhost:8080一个是localhost:8081前后端联调时第一个拦路虎就是跨域。浏览器默认不允许跨端口请求Vue 项目里如果不配置代理axios 请求会被浏览器拦截。我的方案是在 Vue 项目的vue.config.js里配置 devServer 代理module.exports { devServer: { port: 8081, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } };这样一来前端请求/api/survey/list时会被开发服务器代理转发到后端的http://localhost:8080/api/survey/list。浏览器以为请求的是同一个源跨域问题就不存在了。这个方案在开发阶段是最省心的比在后端写CrossOrigin或者配置 CORS 过滤器更贴近上线后的真实请求路径。不过要提醒一个容易忽略的点代理配置只对本地开发服务器有效。前端npm run build打包出来的静态文件丢到 Nginx 上之后Nginx 也要配置代理转发否则生产环境的/api请求会 404。这一点我在下面部署环节展开。6.2 打包与 Nginx 部署项目的最终形态是后端打成一个 jar 包前端打成静态资源目录由 Nginx 托管。后端打包mvn clean package -DskipTests java -jar target/survey-system.jar --server.port8080前端打包npm run build生成dist目录里面是 index.html 和一堆带哈希的 JS/CSS 文件。我把 dist 目录上传到服务器/usr/share/nginx/html/survey下然后配置 Nginxserver { listen 80; server_name your-domain.com; # 前端静态资源 location / { root /usr/share/nginx/html/survey; index index.html; try_files $uri $uri/ /index.html; } # 后端接口代理 location /api/ { proxy_pass http://127.0.0.1:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }try_files $uri $uri/ /index.html;这一行必不可少。它解决的是 Vue Router history 模式的一个经典问题用户在问卷填写页/fill/abc123刷新时浏览器会直接请求 Nginx 上的这个路径但 Nginx 的静态目录里根本没有fill/abc123这个文件如果没配 try_filesNginx 会返回 404。配置了 try_files 之后所有不存在的路径都会回退到 index.html再由 Vue Router 接管路由页面就能正常打开。提示如果你在本地预览打包后的页面发现访问二级路由刷新是白屏大概率就是没有配置 try_files 或者 router 用的不是 history 模式。不熟悉部署的同学可以先用 hash 模式URL 里多个#规避这个问题上线前再切回 history。7. 踩坑复盘与续作方向7.1 我在实际开发中绕过的几个坑第一个坑是 MySQL 表名和字段名用了保留字。我最初给状态字段起名status在 MySQL 8.0 下倒是没问题但换到 5.7 版本执行某些 SQL 时会出现语法报错。后来统一把所有表名都用反引号包裹字段命名尽量避开status、order、group这些单词。建议大家在建表阶段就养成给表名字段名换一个不容易撞词的名字的习惯比如survey_status比status稳妥。第二个坑是时间字段的时区问题。SpringBoot 连接 MySQL 时连接字符串里如果没有指定serverTimezoneAsia/Shanghai你往数据库里写入的时间会比本地时间早八个小时。排查这个问题的过程很曲折因为数据库里看起来有数据日期不对这个问题在开发初期根本不会暴露等你真正去查某天提交了多少份问卷时才发现统计全乱了。解决方案就是在 JDBC 连接串里显式指定时区。第三个坑是问卷发布后改了题目结构。我在需求阶段特意定了发布后不允许改题目的规则但为了灵活允许管理员在问卷编辑页复制问卷——创建一份内容相同的新草稿修改后再重新发布。这个设计既保护了历史数据的统计一致性又给了管理员纠错的途径。第四个坑是前端打包后布局异常。这个问题通常是因为 ElementUI 的样式按需引入和全局引入混用导致的或者浏览器缓存了旧的 JS 文件。我最终的做法是统一引入完整版 ElementUI 样式在 index.html 里加了一个版本号的 meta 标签每次发布新版本时手动改一下强制让浏览器拉取新资源。7.2 系统做完了再往哪些方向扩展这个版本已经是完整可用的状态但如果你时间充裕想把这个项目做出亮点我建议往这几个方向深挖答卷的筛选与导出管理端增加按时间范围筛选答卷支持导出 Excel。这个功能在企业内部做问卷调查时几乎必用。问卷模板库内置一批常用问卷模板满意度调查、课程反馈、活动报名等用户基于模板快速创建问卷。逻辑跳转某些题目选择特定选项后跳过后续若干题。如你是否使用过XX功能选否直接跳到最后。这个功能实现难度不小但做出来会非常加分。单题分析不只给整体统计还能做选择A的人群中又有多少人选了B这样的交叉分析这会让统计模块显得专业很多。多管理员与角色权限目前管理员比较简单可以扩展成多用户注册、角色分级超级管理员、普通管理员、访客。我在做这个项目的过程中最大的体会是不要被问卷调查系统这几个字的朴素外表迷惑。它和电商系统、博客系统一样是一个需要你认真思考数据怎么建模、状态怎么流转、边界怎么约束的真实业务系统。把这套东西完整做下来前后端分离开发的整套技能栈都会有一个质的提升。如果你正在写一份有问卷模块的毕业设计或练手项目希望这篇笔记能帮你少走一些弯路。尤其是数据库设计那四张表和发布后锁定题目结构这两个决策我建议你拿小本本记下来——它们是整个系统从能运行变成经得起推敲的关键。后面如果遇到具体问题欢迎随时交流。