做问卷调查系统听起来是个老掉牙的项目但说实话这种“经典业务主流技术栈”的组合恰恰是练手价值最高的。一方面问卷调查的需求逻辑很清晰用户、问卷、题目、选项、答卷这些实体之间的关系天然适合拿来做数据库设计和接口练习另一方面SpringBoot Vue MySQL这套组合又是目前中小型项目里最主流的搭配做完一个完整可运行的系统你对全栈开发的整个链路——从建表到后端接口再到前端页面——就能建立起完整的体感。这篇博文我基于一个可运行的在线问卷调查系统源码来讲把项目拆开揉碎从设计思路、核心实现到运行部署、踩坑复盘一次说清楚。1. 项目整体设计与技术选型思路1.1 为什么是SpringBoot Vue MySQL这三样东西放一起早就是Web开发领域的“黄金三角”了。SpringBoot负责后端业务逻辑Vue负责前端交互界面MySQL负责数据持久化。它们各自不是唯一选择但组合起来的开发效率、学习资料丰富程度、岗位需求量目前依然是天花板级别的。我见过太多人纠结“要不要换更牛的技术”比如后端用Spring Cloud微服务前端用React数据库上MongoDB。但对于问卷调查这类业务微服务纯属给自己加戏单机SpringBoot完全撑得住MongoDB虽然灵活可问卷调查的数据结构其实是稳定的关系型结构用MySQL做关联查询、统计聚合都更顺手。选技术栈不是选最酷的是选最合适、最能保证项目顺利落地的。还有一点很关键这套技术栈的生态太成熟了。遇到任何问题搜索引擎一搜基本都有现成答案连报错信息都能直接搜到讨论帖。对于一个需要“可直接运行”的项目来说这本身就是巨大的隐性优势因为你卡壳的概率被大大降低了。1.2 问卷调查系统的功能模块拆解在线问卷调查系统听起来简单但真正拆开看该有的模块一个都不能少。我把整个系统分成两个端来看一个是面向管理员的运营端一个是面向普通用户的填答端。管理员端要管的事不少创建问卷、编辑问卷、增删改查题目、配置选项、查看回收的答卷数据。更进一步还可以做问卷的发布和下线控制、基础的数据统计图表展示。别小看这些功能它们组合起来就是一个完整的内容管理闭环。用户端的核心就一件事填问卷。但填问卷背后还有问卷列表浏览、问卷详情加载、答案提交校验、填写状态标识这些细节。用户能不能顺畅地完成一次填写直接决定问卷的回收率和数据的有效性。这里头有一个特别容易被新手忽略的设计点就是题目类型的多样性。问卷调查题型至少有单选、多选、填空、评分、下拉选择这么几类每一种类型的答案存储结构都不一样。很多初版问卷系统就只做了单选题结果真上线了才发现多选题的数据统计怎么算都不对。所以在设计阶段题型一定要作为核心维度去建模不要先做成固定死的结构后面再改就很难受了。2. 数据库与后端核心设计2.1 数据库表结构设计数据库是整个系统的地基表结构设计得好不好直接决定后续开发是顺畅还是痛苦。问卷调查系统的核心表我梳理下来至少要有这几张用户表、问卷表、题目表、选项表、答卷表、答卷明细表。先看用户表字段无非是id、用户名、密码、昵称、角色、创建时间这些。注意角色字段要区分管理员和普通用户因为问卷的创建和管理都是管理员权限普通用户只能填写。密码一定要加密存储用BCrypt或MD5加盐都行明文存密码是极其危险的行为这点千万不能图省事。问卷表要承载问卷的主体信息标题、描述、状态草稿/已发布/已下线、创建者ID、创建时间、开始时间、结束时间。这里有个设计细节值得说就是问卷状态字段。很多新手只做了发布和未发布两种状态但实际上运营中的问卷还经常需要“下线”操作比如回收量够了或者问卷内容有问题需要紧急停止。多一个状态运营的灵活度就完全不一样。题目表就要小心了它要关联问卷ID还要存题型类型。我的建议是题干用text类型因为题目可能比较长题型用一个整数枚举表示例如1单选、2多选、3填空、4评分、5下拉是否必填这个标志必须有直接影响前端校验和后端校验排序号字段也很重要问卷题目的顺序是可调的选项表相对简单关联题目ID、选项文本、排序号。注意单选和多选的选项都放这张表里填充的时候选项顺序不能乱所以排序号的用处就体现出来了。答卷表存每次填写的整体信息关联问卷ID如果系统要求登录才能填写还要关联用户ID再加上填写时间。答卷明细表则是关键中的关键它要记录每一题的答案。这里有个经典设计决策答案是存选项ID还是存文本我的经验是两个都存。存选项ID是为了方便做统计聚合比如“这道题多少人选了A”存文本是为了方便直接展示和导出比如填空题不可能有选项ID。一个明细行记录一道题目的答案既支持选项关联又保留原始文本后边做数据分析的时候两种场景都不耽误。DATABASE设计还有个容易忽略的点索引。查询用户名、查询问卷状态、查询答卷关联的问卷ID这些高频筛选字段一定要建索引否则数据量一上来查询速度会肉眼可见地下降。2.2 后端分层与接口设计SpringBoot后端项目我习惯分成四层Controller、Service、Mapper、Entity。Entity就是数据库表对应的实体类Mapper管数据库读写Service管业务逻辑Controller只做参数接收和结果返回。这样的分层不是摆样子它能让代码各司其职出了问题也能快速定位到具体某一层。接口设计遵循RESTful风格基本的接口清单大概是这样的POST /api/auth/login登录POST /api/auth/register注册GET /api/questionnaire/list获取问卷列表POST /api/questionnaire创建问卷管理员PUT /api/questionnaire/{id}更新问卷管理员DELETE /api/questionnaire/{id}删除问卷管理员GET /api/questionnaire/{id}获取问卷详情POST /api/answer/submit提交答卷GET /api/answer/statistics/{questionnaireId}获取问卷统计结果这里边有几个设计细节值得展开。拿创建问卷来说前端传过来的JSON其实是嵌套结构一个问卷对象里面带一个题目列表每道题又带一个选项列表。SpringBoot后端接收这种嵌套结构没有任何问题直接用Bean属性嵌套映射就行。但真正考验设计功力的是Service层的处理逻辑保存问卷的时候要先把问卷主记录插入拿到自增ID之后再循环插入每道题题目ID拿到之后再循环插入每个选项。这是一个典型的事务性操作任何一步失败都该整体回滚所以务必要加Transactional注解。提交答卷的逻辑更要谨慎。一次提交包含一份答卷主记录和多条答卷明细同样需要事务控制。同时还要做校验这个问卷存不存在、状态是不是已发布、必填题是否都有答案、单选题的答案是不是合法的选项ID。这些校验放后端做是安全底线因为前端的校验随时可以被绕过。永远不要相信前端传过来的数据这是后端开发的第一原则。还有一个问题是身份认证。如果系统要求区分管理员和普通用户就要在登录成功后签发Token后续请求在请求头里带上Token后端拦截器统一校验。用JWT还是用Session我倾向于JWT因为无状态、扩展性好、前后端分离下更好配合。拦截器的判断逻辑也不复杂白名单放行登录注册接口其他接口校验Token再从Token里解析出用户信息。3. 前端页面与交互实现详解3.1 Vue项目结构与核心页面Vue前端的结构按模块来划分比按页面划分更合适。我习惯的目录组织方式是api目录放接口请求封装assets放静态资源router放路由配置store放全局状态views按业务模块放页面组件components放可复用的子组件。这个项目的核心页面其实不算多管理员这边需要问卷列表页、问卷编辑页、答卷统计页用户这边有问卷大厅页、问卷填写页、完成提示页。页面不多但页面的状态管理还是需要认真对待。问卷编辑页是最复杂的因为它要动态维护一个题目列表每种题型渲染不同的编辑控件还要支持添加题目、删除题目、调整顺序。这些状态如果全堆在组件里代码很快就会变得不可读我的建议是把问卷编辑状态封装成一个独立的状态模块来管理数据流会清晰很多。用户填写页面同样有技巧。题目列表一般不止一两道一次性把所有题目都渲染出来遇到长问卷页面会很长。这里可以用分步加载或滚动加载但更简单的做法是直接渲染全部题目只在提交时做整体校验。考虑到问卷调查的实际使用场景用户通常希望看到全部题目一览无余反而体验更好。不要为了技术上的“优雅”牺牲实际体验这是做前端要反复提醒自己的。Vue组件化最大的优势就是复用。单选题、多选题、填空题、评分题虽然编辑和展示都不一样但可以抽象出共同的属性比如题目ID、题干、是否必填、用户的答案。我用过一种做法就是把题型组件做成异构的容器里根据题目类型动态渲染对应的子组件这样添加新题型时只要新写一个组件不用改容器逻辑。3.2 前后端联调的关键配置前后端分离开发联调阶段绕不过去的一个问题是跨域。Vue开发服务器默认跑在localhost:5173或localhost:8080SpringBoot跑在localhost:8080两个端口不一样浏览器就会报跨域错误。解决办法有几种。最简单粗暴的在后端CORS配置里放开所有来源开发环境没问题但不够安全。更规范的做法是前端配置代理把/api路径的请求转发到后端地址。Vue CLI项目在vue.config.js里配devServer.proxyVite项目在vite.config.js里配server.proxy。原理其实不难就是告诉开发服务器遇到/api开头的请求你不是浏览器你帮我转发到后端去这就绕过了浏览器的同源限制。前端请求封装也有讲究。Axios实例要统一设置baseURL和超时时间还要用请求拦截器在每次请求头里带上Token。响应拦截器要统一处理错误码比如Token过期时跳转到登录页网络错误时弹出提示。这些公共逻辑统一封装好每个页面就只管业务不用关心这些机械化的处理。联调阶段最容易踩的一个坑是前后端对字段名和接口路径的理解不一致。比如后端返回的字段是createTime前端写成了createdTime结果页面一直显示不出来。要避免这个我的习惯是做接口文档或者退一步在接口封装层写清楚注释。前后端联调最大的成本不是代码是沟通把数据结构的约定做到前置效率能提升一大截。4. 项目运行指南从零到直接跑起来4.1 环境准备一个标榜“可直接运行”的项目环境准备工作必须写得明明白白。我梳理一下需要的前置环境JDK 8或11注意SpringBoot版本对JDK版本有要求2.x系列用JDK8就没问题3.x系列需要JDK17MySQL 5.7或8.x最好8.x反正新建项目也没必要用老版本Node.js 14以上配合npm或yarn一个开发工具后端推荐IntelliJ IDEA前端用VSCode或者WebStorm都行IDEA装好Vue插件也能同时写前端这些环境装起来都不复杂但版本坑很多。有一个经验不要一味追求最新版本。SpringBoot 3.x虽然发布挺久了但很多老教程和依赖还不适配对一个需要快速跑起来的项目SpringBoot 2.7配上JDK8是最稳妥的组合。Node也是同理太高的Node版本在安装某些老依赖时会报错遇到这种情况降Node版本比改代码要快得多。4.2 导入项目与配置数据库拿到源码之后第一步不是急着启动先花几分钟看看项目结构确认是Maven项目还是Gradle项目前端目录是哪个。后端导入IDEA之后Maven会自动下载依赖网络不好或者被墙的情况下可能比较慢这个时候配置一下Maven国内镜像源会快很多。数据库配置这块网上很多项目都会写死在application.yml里密码也是明文。拿到项目后第一件事是打开application.yml确认数据源配置。要改的有url、username、password三项。URL要确认端口和数据库名比如jdbc:mysql://localhost:3306/survey?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai这一串参数建议原样保留尤其serverTimezone不设置的话连MySQL 8很容易报时区错误。数据库本身需要手动创建。连上MySQL客户端工具执行一条CREATE DATABASE语句然后导入项目里提供的SQL脚本。如果没有sql脚本那就要看看项目里有没有配置了自动建表的选项比如JPA的ddl-auto或MyBatis的初始化脚本。这里还是建议项目里自带一份完整的SQL脚本这是“可直接运行”最实在的保障。4.3 启动后端与前端后端启动很简单直接运行主类里的main方法。看到控制台打印出Tomcat started on port(s): 8080说明后端起来了。但是提醒一下新手最容易搞混端口后端占用了8080前端开发服务器不要也用8080否则一定会有一个起不来Vite项目默认是5173倒是不冲突。前端要先进到前端项目目录执行npm install安装依赖。这一步耗时长短完全看网络状况装完之后执行npm run dev看到Local地址输出就说明前端开发服务器起来了。浏览器打开那个Local地址看到页面能正常显示注册一个账号登录进去再试着创建一个问卷填一下整个链路就跑通了。这里要特别说一个生产构建的问题。npm run dev是开发模式性能差一些但热更新方便。如果要把项目部署到服务器上需要执行npm run build生成的dist目录就是纯静态文件可以交给Nginx托管。前端静态文件和后端接口可以分开部署也可以通过Nginx反向代理合并到同一个域名下后者在生产环境更常用。5. 常见问题与排查技巧实录5.1 环境配置相关的坑这套技术栈的问题我见得最多的就是环境配置问题而且基本都集中在版本冲突和配置细节上。后端启动失败先看报错信息的最后几行十有八九是端口被占用。SpringBoot默认8080如果你机器上已经有别的服务在跑直接改端口就行在application.yml里加一行server.port8081。改完之后前端代理要记得同步改不然请求又找不到了。数据库连接失败也特别常见。报Communications link failure或者Access denied前者一般是IP、端口、数据库名写错了或者是MySQL服务没启动后者是用户名密码不对或者MySQL 8的认证插件版本太高。有个我亲测有效的小技巧就是本地MySQL如果是从老版本升级上来的新建一个用户再授权比在老用户上折腾要省心得多。前端的坑集中在npm install阶段。卡住不动、报ERR_SOCKET_TIMEOUT基本都是网络问题换镜像源一句话就能解决。还有就是node_modules装了一半失败这种时候别纠结把node_modules目录删掉重新装比到处找补丁要干净利落。5.2 业务逻辑里的隐藏问题环境过了业务逻辑层面的问题会更隐蔽。最常见的一个是创建问卷时题目和选项的ID为空。不少前端在新增题目时会临时给一个负数或者字符串作为临时ID提交后端时没有处理好导致后端关联关系混乱。建议是后端直接忽略前端传来的ID重新生成主键然后通过返回结果把真实ID回传给前端让前端更新本地状态。还有一个问题经常出现在统计模块。统计多选题的时候很多人会想当然地认为一个选项只能计数一次但实际上多选题的答案是以逗号分隔的多个选项ID。统计之前需要先切割再逐个累加不做这个处理统计出来的数据一定是错的。提交答卷重复提交也是一个容易被忽略的问题。用户快速双击提交按钮前端发了两条请求后端就生成两条答卷记录。解决办法是前端提交按钮加loading状态并在提交期间禁用后端再配合做一次去重校验比如同一问卷同一用户短时间内不能重复提交。前端是体验兜底后端是安全兜底两层都要做。5.3 部署阶段的经验总结开发环境跑通了很多人转移到生产部署时又踩进坑里。最常见的是前端build之后刷新404这多半是Nginx没有配置history模式下的try_files。Vue Router如果用的是history模式路由变化时浏览器会向服务器请求对应的路径Nginx需要把所有路由都重定向到index.html。配置大概是这样location / { try_files $uri $uri/ /index.html; }还有接口地址的问题。生产环境前端静态文件通过Nginx托管接口请求还是以/api开头Nginx需要把/api代理到后端的Java进程上否则页面怎么都调不到数据。location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }这里有个细节proxy_pass末尾的斜杠有没有代理解析规则会不一样。大家配置的时候不要照抄先搞清楚自己后端接口的实际路径再动手。6. 如何在这个基础上二次扩展项目跑起来了接着要考虑的就是怎么继续扩展。问卷调查系统可以延展的方向非常多我这里挑几个性价比高的说说。第一个方向是问卷逻辑编排。现在的问卷基本都是线性填写但真实业务里很多问卷需要根据用户的回答跳到不同题目。这就需要给题目增加跳转逻辑配置比如“选了A就跳第5题选了B直接结束”实现起来不复杂数据库加两个字段存跳转规则前端提交时根据答案计算下一题后端也要做同步校验。这是我见过问卷系统扩展需求里频率最高的一个。第二个方向是答卷数据的可视化分析。当前统计页面如果只展示表格那还有很大的升级空间。可以集成ECharts做柱状图、饼图、雷达图把单选题的选项分布、评分题的平均值、多选题的占比都做成图表。技术难度不大但视觉冲击力很强演示或者汇报时效果非常加分。第三个方向是权限控制的细粒度扩展。现在可能只是区分管理员和普通用户上线实名制填答场景时还要增加答卷者管理、问卷填写资格控制、导出数据脱敏等功能。这块要动的东西多一些但也是让项目真正能商用化的关键。我个人觉得一个初学者做完这个项目最有价值的事情不是项目本身而是借此把一条完整的技能链路走通数据库设计、后端分层、RESTful接口约定、前端组件化、前后端联调、部署上线。这套流程是通用的以后换任何业务、换任何技术栈做事的框架都是这一套。最后说一个我实际过程中的体会做项目不要一上来就追求把所有功能做完做好。先跑通最小闭环再逐步打磨细节这是个人开发效率最高的路径。项目源码能直接跑起来这个起点很重要它意味着你的每一次修改都能立刻看到实际效果学习的正反馈会一直持续下去。如果你下载的这个项目能成功启动说明你的环境配置已经过关接下来要做的就是往里加东西、改东西、看看会不会把它搞坏坏了再修好能力就是这么涨上来的。