刚拿到这套“在线问卷调查系统”源码的时候我其实没抱太大期望。毕竟这类管理系统在Gitee和GitHub上一搜一大把质量参差不齐很多都是“能跑但没法用”的Demo级作品。但这套SpringBoot后端Vue前端MySQL的组合实测下来确实给了我一个不小的惊喜结构干净、功能完整最关键的是——真的能直接跑起来。这个项目能做什么用户管理、问卷创建、在线答题、数据统计、结果导出一套标准问卷调查系统该有的功能基本都覆盖了。后端用SpringBoot整合MyBatis-Plus前端用Vue写页面数据库用MySQL存数据典型的前后端分离架构也是目前JavaWeb项目里最主流的组合。它的价值不仅仅在于帮你快速搭一个问卷系统更在于提供了一个完整的学习样本如果你是准备毕设、练手或者想了解企业级项目结构的学生能从里面看到控制器、服务层、Mapper是怎么协同工作的如果你是想快速部署一个内部调研系统的开发者直接改一改数据库配置就能用。我后续会从架构拆解、数据库设计、运行实战和排坑经验四个维度把整个项目讲透。1. 整体架构与设计思路拆解1.1 为什么选SpringBootVue这套组合做问卷系统市面上其实有几种技术路线可选。一种是纯后端模板渲染像SpringBoot加Thymeleaf写起来快但页面交互体验一般还有一种是用现成的第三方问卷平台功能强大但数据全在别人那里没法二次开发再一种就是这套项目采用的前后端分离方案。SpringBoot负责提供RESTful接口Vue负责页面渲染两者之间通过JSON格式的数据交互。这种组合的好处是职责清晰后端专注业务逻辑和数据存储前端专注交互效果和视觉呈现。问卷系统天然就有“管理端”和“填答端”两种完全不同的界面需求——管理端需要的是复杂的信息展示和操作反馈填答端需要的是流畅简洁的答题体验——用前后端分离的方式开发两边的开发效率都会高很多。另一个现实因素是这套技术栈的职业通用性。在我接触过的中小型项目中SpringBootVueMySQL的出镜率非常高学会这套体系后续在招聘市场或接私活的时候能力可以直接平移学习成本不会被浪费。1.2 核心模块划分一套系统里的三条主线打开这套源码你会发现它的后端代码结构非常规整按功能可以拆成三条主线。第一天线是用户体系。包含用户注册、登录、信息维护、权限控制。问卷系统的用户分为管理员和普通用户管理员负责创建问卷、查看数据普通用户负责填答问卷。权限的控制方式采用的是拦截器加角色判断够用且易于理解。第二天线是问卷管理。从创建问卷、编辑题目、发布问卷、关闭问卷到删除问卷整个生命周期管理都在这个模块里。这是整个系统最核心的部分涉及到问卷状态的多态变化和题目的动态增删。第三条线是答卷管理。用户提交答卷后数据要落库系统要能够对答卷数据进行清洗、统计、可视化展示。这套源码里用了一些很聪明的统计技巧比如通过SQL聚合函数直接计算选项分布避免在Java内存里做大量循环统计。1.3 这套设计的取舍亮点我在实际跑项目的时候发现一个特别好的设计细节问卷和题目的关系用的是主从表设计。问卷主表存问卷的基本信息标题、状态、创建时间题目表存每一道题的具体内容通过外键关联。这个设计看起来简单但很多人首次做管理系统时会踩进“把所有信息塞进一张大表”的坑里导致后期扩展和统计都非常痛苦。这种主从表设计的优势打个比方就很好理解问卷就像一本书题目是书里的每一页二者分开存想改第几页就改哪页想统计整本书的页数也不用把书拆了数。如果全赛在一张表里每次查问卷都要带出一坨题目性能和数据结构的清晰度都会受影响。2. 数据库表设计与核心实现解析2.1 数据表全景六张表撑起一个系统这套项目的数据库设计非常克制核心就六张表我整理了一个简表方便你快速浏览。表名职责描述核心字段user用户信息id、username、password、role、create_timequestionnaire问卷主表id、title、description、status、creator_id、create_timequestion题目表id、questionnaire_id、type、content、sort_orderoption选项表选择题用id、question_id、content、sort_orderanswer答卷主表id、questionnaire_id、user_id、submit_timeanswer_detail答卷明细表id、answer_id、question_id、option_id、content细看这套表结构有几个地方设计得很有门道。第一题目类型字段type用了整数枚举而不是字符串1代表单选、2代表多选、3代表填空。这样存储占用小、查询效率高Java代码里再定义对应的枚举类做转换兼顾了性能和可读性。第二选项表单独拆出来而不是在question表里搞一个逗号分隔的文本字段。这一点尤其重要——如果选项是用逗号拼在一个字段里统计每个选项被选了多少次的时候就只能靠子串匹配不仅写起来痛苦跑起来也慢。拆成独立的option表后统计可以用JOIN加GROUP BY效率和优雅程度完全是两个档次。第三answer和answer_detail两表分离这个设计很见功力。answer表记录“哪个人在哪次提交了哪份问卷”answer_detail则是明细账。将来要做分析时可以先从answer表按条件过滤再去关联detail不用每次都在明细表里全表扫描。2.2 问卷状态机掌握问卷生命周期的最关键逻辑问卷表里的status字段承担着整个系统的业务核心逻辑。这套源码采用的是经典的三态设计1代表草稿、2代表发布中、3代表已关闭。这三个状态的流转规则我直接说结论草稿状态下问卷可以被编辑和删除发布后问卷只读用户可答题创建者不可改题关闭后问卷归档不能答题但可查看统计结果。很多刚接触者容易忽略“发布后不可改题”这层规则其实这是很多成熟问卷系统的通用约定。想象一下问卷已经发给200个人作答了这时候创建者偷偷改了一个题目选项那么改之前和改之后的数据混在一起统计结果就失真了。这套源码对发布状态加了这个业务约束是充分理解行业需求后才能做出来的设计。2.3 前端答题页的几个实现细节Vue前端部分答题页的实现我建议你重点阅读。它采用了动态表单渲染的思路后端把问卷的题目数据以JSON形式传给前端Vue拿到数据后通过v-for动态循环渲染每种类型的题目组件。这个方案避免了写死页面结构的问题。传统做法是同一套代码的页面就那么几个固定题目每次换个问卷就要改前端代码。而这套系统的做法是页面是通用的问卷内容从接口拉取数据驱动渲染。新建一份问卷前端一行不动页面自动跟着变。还有一个值得注意的细节是答题进度的实时校验。每完成一道必答题前端会更新本地答题进度记录未完成的题目用星号标记提交时再统一校验。这种交互模式对填答者的体验很友好能有效降低因为漏答而导致的提交失败率。3. 运行环境准备与部署实操记录3.1 环境最低要求清单跑这套项目环境配置没有特别苛刻的要求。我列出实测可行的版本组合你按这个准备不会出问题。依赖项推荐版本说明JDK1.8实测JDK8和JDK11都能跑不建议直接上17Maven3.6后端依赖管理必备Node.js14前端构建环境MySQL5.7新版需要8.0视driver配置调整Redis不需要这套源码没用到别被其他项目经验误导这里多说一句JDK版本的问题。很多初学者上来就装最新的JDK17甚至21结果一跑Java代码就抛各种奇怪异常。原因在于Spring Boot 2.x系列官方支持到JDK8和11到JDK17会出现反射访问限制等问题。这个项目用的是Spring Boot 2.x所以老老实实用JDK8或11能少踩很多坑。3.2 数据库初始化的正确姿势这套源码自带一个数据库初始化脚本通常在项目的sql目录下文件名类似questionnaire.sql。但直接导入之前有两个关键步骤必须调整。第一建库语句要改。打开脚本文件把开头的CREATE DATABASE IF NOT EXISTS后面跟着的数据库名改成你想要的库名推荐用英文小写字母比如survey_db。我之前有用户环境里默认库名带中划线后面配置文件里所有连接串都要跟着改非常麻烦还是开始就统一好。第二确认MySQL的字符集。脚本里如果没有设置DEFAULT CHARSETutf8mb4建议手动在库和表上补上。问卷系统百分之百会涉及用户输入的中文内容如果建库时默认charset是latin1问卷标题就会变成问号。这个坑我在别的项目里见过太多次确保utf8mb4是你的数据库默认字符集这是所有中文项目运行前的必修课。导入命令用这一条即可mysql -u root -p questionnaire.sql导入完成后用mysql命令看一眼表清单确认六张核心表都建好了再进行下一步。3.3 后端配置的修改点与启动验证后端启动前必须改配置。项目配置文件一般是src/main/resources下的application.yml核心要改的是数据库连接。如果只是本地跑最稳的配置写法是直接用你自己数据库的用户名密码。具体打开application.yml找到spring.datasource.url这一段确认jdbc:mysql后面的地址、端口和库名是否与你的环境一致。如果MySQL装在本机、端口还是默认的3306一般只需要改库名和你自己的用户名密码。启动后端有一个很好的自检方式不只是看“BUILD SUCCESS”要看控制台日志里的端口监听信息。Spring Boot启动完成后会打印一行Tomcat started on port(s): 8080看到这个才说明后端真的起来了。如果只看到BUILD SUCCESS但没有端口监听日志多半是启动过程中出错了这时候要拉上面的Exception堆栈信息看真正原因。后端接口的自测也很简单。浏览器或接口调试工具里直接访问http://localhost:8080/api/user/list之类的接口如果返回JSON数据说明接口链路通畅。这一步做完再配前端就心里有底了。3.4 前端环境的搭建与跨域配置前端代码在项目里一般是单独一个目录比如vue-frontend或front。进入这个目录后先装依赖npm install这一步在国内网络环境下可能比较慢有耐心的可以用默认源。如果是着急调试把registry切换成国内镜像源也行npm config set registry https://registry.npmmirror.com依赖装完之后启动开发服务器npm run serveVue的调试服务器默认跑在8080端口但后端接口也占了8080两个会冲突。这里有两种解法推荐先看后端的配置。后端在application.yml中如果配了server.port8080前端开发服务器的默认端口就可以改成8090或其他。这个项目如果先启动了后端前端本身会提示端口冲突选择换一个新端口就好。如果前端和后端不在同一个端口下运行就涉及跨域问题。这套源码大概率在后端的WebConfig或CorsConfig里已经配置了跨域放行如果没有最简单的办法是在Vue项目的vue.config.js里配置devServer的proxy代理把接口请求全部proxy转发到后端端口。前端页面用相对路径请求/api就不会再有跨域烦恼。这一套逻辑不只是本项目的经验凡是前后端分离的项目都是同样操作模式。3.5 前后端联调的标准验收清单全部启动后不要急着说部署成功建议按下面的清单走一遍完整流程任何一步卡住都能快速定位问题的归属端。我将这个项目验证通过的检查项整理成了一张快速验收表检查项预期结果归属端访问前端首页页面正常渲染无白屏报错前端注册一个新用户注册成功数据库user表多一条记录后端数据库登录后进入后台跳转正常能展示当前用户信息前后端配合创建一份问卷问卷出现在列表中状态为草稿后端前端发布问卷并复制填答链接链接能正常打开答题页前端提交一份答卷答题页提示成功后端入表后端数据库查看统计报表选项分布和图表正确后端前端这七步走通系统主干功能就全部验证过了。后续再去填一些边界功能比如编辑题目、数据导出等就会顺很多。4. 常见问题与排查技巧实录4.1 启动类问题端口被占与依赖冲突实际跑项目最常遇到的就是两类启动问题。一个是端口被占用另一个是依赖版本冲突。端口被占用的报错信息一般是Port 8080 was already in use。如果你本机之前跑过其他Java服务或者有别的开发工具占了8080后端就起不来。最省事的解决办法是改后端端口在application.yml里改server.port比如改成8090。同时前端所有请求的baseURL也要同步改如果前端配置里写死了8080记得一并调整。依赖冲突更多发生在Maven下载阶段。项目能“直接运行”的前提是你本地Maven仓库里有正确版本的依赖。如果下载过程中断或者本地仓库里存在旧版本的jar包会抛出NoClassDefFoundError或BeanCreationException。遇到这种问题优先试一次强制刷新mvn clean package -U-U参数强制让Maven检查远程仓库的更新版本对付依赖版本不一致有奇效。还需要确认一下你的Maven全局配置里settings.xml的镜像地址是否可靠国内环境经常因为默认远在国外下载到一半就超时把这个配置好能省下一大半的折腾时间。4.2 数据库连接的经典报错Public Key Retrieval is not allowed这是一个极具代表性的MySQL 8.0踩坑点。如果你本机用的是MySQL 8.0以上跑这个项目时后端日志里出现了Public Key Retrieval is not allowed不要慌不是项目本身有问题而是MySQL 8.0默认的caching_sha2_password认证插件不允许客户端在非SSL连接时直接请求公钥。有两个解决方向二选一即可。一个是连接串里加参数jdbc:mysql://localhost:3306/survey_db?allowPublicKeyRetrievaltrueuseSSLfalse另一个是把数据库用户的认证方式改成mysql_native_passwordSQL语句如下ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY 你的密码;这两种方法第一种改起来快不影响数据库全局配置第二种对老旧客户端兼容性更好实际选哪个都行。4.3 前端白屏Node版本过低与依赖缺失前端起不来或者起来后白屏大概率卡在两个地方。第一Node.js版本过旧。Vue CLI的现代版本对Node的版本要求最低在12以上如果你还在用8或10启动时就会直接报错或卡在编译阶段。用node -v先确认自己的版本如果版本过低去官网装一个LTS版本即可。第二node_modules目录不完整。很多从Gitee或网盘下载的压缩包并不会连同node_modules一起打包因为体积太大且不通用如果你没有执行npm install或者这个过程中断启动后页面就会因为缺模块而渲染失败。判断方法很简单打开前端dist或src下的入口文件浏览器F12打开控制台如果看到一堆Module not found的红色报错就是依赖不全重新执行一次npm install并确认安装过程成功到100%。4.4 功能性问题答题完成后统计结果不刷新这是一个比较隐蔽的逻辑层面的坑。问卷创建者填完问卷、查看统计报表时发现数据不是最新的或者提示“暂无数据”。排这个问题的思路要先从数据链路从上往下捋。打开数据库查询answer表看你刚才提交的那份答卷是否真的落库了。如果表里没有说明提交接口出问题检查前端控制台提交请求的返回状态如果表里有那就是统计接口的SQL逻辑问题常见的原因是统计时条件筛选里多了不必要的状态判断比如只统计某种状态的答卷而真实数据里状态值不一致。我这几次帮用户排查九成以上都卡在第一步——接口请求根本没有成功发送到后端。前端提交按钮的校验逻辑过多有一项没通过请求压根就没发出去。所以排查顺序建议固定为前端请求是否发出 - 后端是否收到并返回 - 数据库是否写入 - 统计接口是否读出来。这个顺序在问卷系统里几乎是通用的排查路线。5. 快速上手心得与扩展建议5.1 最省时间的上手路径如果你刚拿到这套源码别急着打开IDE就直接跑。我的建议是先花十分钟看README和目录结构摸清楚前后端各自的位置再去改配置。磨刀不误砍柴工这个习惯在接手任何开源项目时都适用。对于学生朋友我还有一个额外建议在能完整跑通的基础上试着在问卷题目类型里加一种新题型。比如现在只有单选、多选、填空你可以尝试加一个“评分题”1到5星打分。这个扩展会同时涉及数据库取值、后端类型判断、前端动态渲染、统计图表适配四个层面的修改把这条链路走通你对这个项目的理解会瞬间从“会用”升级到“懂原理”比背十遍八股文都管用。5.2 部署到服务器的路线参考本地跑通了下一步通常是部署到云服务器上。部署时需要将前端项目进行构建npm run build构建完成后会在dist目录下生成一堆静态文件。这些静态文件可以直接用Nginx托管然后通过Nginx反向代理把/api路径转发到后端的Spring Boot服务上。后端侧打包也类似mvn clean package -DskipTests生成的jar包直接在服务器上用java -jar运行即可。如果服务器内存比较小比如只有1G可以在运行命令里加参数限制JVM内存java -jar -Xms256m -Xmx512m questionnaire-system.jar我在部署过程中还习惯给服务器开一个定时任务每天自动备份一次数据库。做法简单用crontab加一条mysqldump命令就行。问卷系统的数据一旦上线会持续增长没有备份机制就像把文件只放在桌面不备份到网盘一样风险太大。5.3 记录一个数据安全的合规提醒最后给所有要实际运营问卷系统的朋友提个醒收集用户填答数据时如果问卷里包含手机号、姓名、身份证等个人信息尽量不要明文存储后端可以在入库前用哈希或加密算法处理。另外完整的答卷明细在统计完有效问卷数量后可以考虑定期物理删除或脱敏。我在实际项目中见过不止一次因为问卷数据泄露引发的纠纷。系统源码再完善也只是工具数据安全意识和存储规范才是你自己要守住的底线。这两条做到位问卷系统才能真正用得长久。 
长河君 · 2026/10/16 6:56:11 · 阅读 1.2k SpringBoot+Vue+MySQL在线问卷调查系统：架构、部署与排坑实战
刚拿到这套“在线问卷调查系统”源码的时候我其实没抱太大期望。毕竟这类管理系统在Gitee和GitHub上一搜一大把质量参差不齐很多都是“能跑但没法用”的Demo级作品。但这套SpringBoot后端Vue前端MySQL的组合实测下来确实给了我一个不小的惊喜结构干净、功能完整最关键的是——真的能直接跑起来。这个项目能做什么用户管理、问卷创建、在线答题、数据统计、结果导出一套标准问卷调查系统该有的功能基本都覆盖了。后端用SpringBoot整合MyBatis-Plus前端用Vue写页面数据库用MySQL存数据典型的前后端分离架构也是目前JavaWeb项目里最主流的组合。它的价值不仅仅在于帮你快速搭一个问卷系统更在于提供了一个完整的学习样本如果你是准备毕设、练手或者想了解企业级项目结构的学生能从里面看到控制器、服务层、Mapper是怎么协同工作的如果你是想快速部署一个内部调研系统的开发者直接改一改数据库配置就能用。我后续会从架构拆解、数据库设计、运行实战和排坑经验四个维度把整个项目讲透。1. 整体架构与设计思路拆解1.1 为什么选SpringBootVue这套组合做问卷系统市面上其实有几种技术路线可选。一种是纯后端模板渲染像SpringBoot加Thymeleaf写起来快但页面交互体验一般还有一种是用现成的第三方问卷平台功能强大但数据全在别人那里没法二次开发再一种就是这套项目采用的前后端分离方案。SpringBoot负责提供RESTful接口Vue负责页面渲染两者之间通过JSON格式的数据交互。这种组合的好处是职责清晰后端专注业务逻辑和数据存储前端专注交互效果和视觉呈现。问卷系统天然就有“管理端”和“填答端”两种完全不同的界面需求——管理端需要的是复杂的信息展示和操作反馈填答端需要的是流畅简洁的答题体验——用前后端分离的方式开发两边的开发效率都会高很多。另一个现实因素是这套技术栈的职业通用性。在我接触过的中小型项目中SpringBootVueMySQL的出镜率非常高学会这套体系后续在招聘市场或接私活的时候能力可以直接平移学习成本不会被浪费。1.2 核心模块划分一套系统里的三条主线打开这套源码你会发现它的后端代码结构非常规整按功能可以拆成三条主线。第一天线是用户体系。包含用户注册、登录、信息维护、权限控制。问卷系统的用户分为管理员和普通用户管理员负责创建问卷、查看数据普通用户负责填答问卷。权限的控制方式采用的是拦截器加角色判断够用且易于理解。第二天线是问卷管理。从创建问卷、编辑题目、发布问卷、关闭问卷到删除问卷整个生命周期管理都在这个模块里。这是整个系统最核心的部分涉及到问卷状态的多态变化和题目的动态增删。第三条线是答卷管理。用户提交答卷后数据要落库系统要能够对答卷数据进行清洗、统计、可视化展示。这套源码里用了一些很聪明的统计技巧比如通过SQL聚合函数直接计算选项分布避免在Java内存里做大量循环统计。1.3 这套设计的取舍亮点我在实际跑项目的时候发现一个特别好的设计细节问卷和题目的关系用的是主从表设计。问卷主表存问卷的基本信息标题、状态、创建时间题目表存每一道题的具体内容通过外键关联。这个设计看起来简单但很多人首次做管理系统时会踩进“把所有信息塞进一张大表”的坑里导致后期扩展和统计都非常痛苦。这种主从表设计的优势打个比方就很好理解问卷就像一本书题目是书里的每一页二者分开存想改第几页就改哪页想统计整本书的页数也不用把书拆了数。如果全赛在一张表里每次查问卷都要带出一坨题目性能和数据结构的清晰度都会受影响。2. 数据库表设计与核心实现解析2.1 数据表全景六张表撑起一个系统这套项目的数据库设计非常克制核心就六张表我整理了一个简表方便你快速浏览。表名职责描述核心字段user用户信息id、username、password、role、create_timequestionnaire问卷主表id、title、description、status、creator_id、create_timequestion题目表id、questionnaire_id、type、content、sort_orderoption选项表选择题用id、question_id、content、sort_orderanswer答卷主表id、questionnaire_id、user_id、submit_timeanswer_detail答卷明细表id、answer_id、question_id、option_id、content细看这套表结构有几个地方设计得很有门道。第一题目类型字段type用了整数枚举而不是字符串1代表单选、2代表多选、3代表填空。这样存储占用小、查询效率高Java代码里再定义对应的枚举类做转换兼顾了性能和可读性。第二选项表单独拆出来而不是在question表里搞一个逗号分隔的文本字段。这一点尤其重要——如果选项是用逗号拼在一个字段里统计每个选项被选了多少次的时候就只能靠子串匹配不仅写起来痛苦跑起来也慢。拆成独立的option表后统计可以用JOIN加GROUP BY效率和优雅程度完全是两个档次。第三answer和answer_detail两表分离这个设计很见功力。answer表记录“哪个人在哪次提交了哪份问卷”answer_detail则是明细账。将来要做分析时可以先从answer表按条件过滤再去关联detail不用每次都在明细表里全表扫描。2.2 问卷状态机掌握问卷生命周期的最关键逻辑问卷表里的status字段承担着整个系统的业务核心逻辑。这套源码采用的是经典的三态设计1代表草稿、2代表发布中、3代表已关闭。这三个状态的流转规则我直接说结论草稿状态下问卷可以被编辑和删除发布后问卷只读用户可答题创建者不可改题关闭后问卷归档不能答题但可查看统计结果。很多刚接触者容易忽略“发布后不可改题”这层规则其实这是很多成熟问卷系统的通用约定。想象一下问卷已经发给200个人作答了这时候创建者偷偷改了一个题目选项那么改之前和改之后的数据混在一起统计结果就失真了。这套源码对发布状态加了这个业务约束是充分理解行业需求后才能做出来的设计。2.3 前端答题页的几个实现细节Vue前端部分答题页的实现我建议你重点阅读。它采用了动态表单渲染的思路后端把问卷的题目数据以JSON形式传给前端Vue拿到数据后通过v-for动态循环渲染每种类型的题目组件。这个方案避免了写死页面结构的问题。传统做法是同一套代码的页面就那么几个固定题目每次换个问卷就要改前端代码。而这套系统的做法是页面是通用的问卷内容从接口拉取数据驱动渲染。新建一份问卷前端一行不动页面自动跟着变。还有一个值得注意的细节是答题进度的实时校验。每完成一道必答题前端会更新本地答题进度记录未完成的题目用星号标记提交时再统一校验。这种交互模式对填答者的体验很友好能有效降低因为漏答而导致的提交失败率。3. 运行环境准备与部署实操记录3.1 环境最低要求清单跑这套项目环境配置没有特别苛刻的要求。我列出实测可行的版本组合你按这个准备不会出问题。依赖项推荐版本说明JDK1.8实测JDK8和JDK11都能跑不建议直接上17Maven3.6后端依赖管理必备Node.js14前端构建环境MySQL5.7新版需要8.0视driver配置调整Redis不需要这套源码没用到别被其他项目经验误导这里多说一句JDK版本的问题。很多初学者上来就装最新的JDK17甚至21结果一跑Java代码就抛各种奇怪异常。原因在于Spring Boot 2.x系列官方支持到JDK8和11到JDK17会出现反射访问限制等问题。这个项目用的是Spring Boot 2.x所以老老实实用JDK8或11能少踩很多坑。3.2 数据库初始化的正确姿势这套源码自带一个数据库初始化脚本通常在项目的sql目录下文件名类似questionnaire.sql。但直接导入之前有两个关键步骤必须调整。第一建库语句要改。打开脚本文件把开头的CREATE DATABASE IF NOT EXISTS后面跟着的数据库名改成你想要的库名推荐用英文小写字母比如survey_db。我之前有用户环境里默认库名带中划线后面配置文件里所有连接串都要跟着改非常麻烦还是开始就统一好。第二确认MySQL的字符集。脚本里如果没有设置DEFAULT CHARSETutf8mb4建议手动在库和表上补上。问卷系统百分之百会涉及用户输入的中文内容如果建库时默认charset是latin1问卷标题就会变成问号。这个坑我在别的项目里见过太多次确保utf8mb4是你的数据库默认字符集这是所有中文项目运行前的必修课。导入命令用这一条即可mysql -u root -p questionnaire.sql导入完成后用mysql命令看一眼表清单确认六张核心表都建好了再进行下一步。3.3 后端配置的修改点与启动验证后端启动前必须改配置。项目配置文件一般是src/main/resources下的application.yml核心要改的是数据库连接。如果只是本地跑最稳的配置写法是直接用你自己数据库的用户名密码。具体打开application.yml找到spring.datasource.url这一段确认jdbc:mysql后面的地址、端口和库名是否与你的环境一致。如果MySQL装在本机、端口还是默认的3306一般只需要改库名和你自己的用户名密码。启动后端有一个很好的自检方式不只是看“BUILD SUCCESS”要看控制台日志里的端口监听信息。Spring Boot启动完成后会打印一行Tomcat started on port(s): 8080看到这个才说明后端真的起来了。如果只看到BUILD SUCCESS但没有端口监听日志多半是启动过程中出错了这时候要拉上面的Exception堆栈信息看真正原因。后端接口的自测也很简单。浏览器或接口调试工具里直接访问http://localhost:8080/api/user/list之类的接口如果返回JSON数据说明接口链路通畅。这一步做完再配前端就心里有底了。3.4 前端环境的搭建与跨域配置前端代码在项目里一般是单独一个目录比如vue-frontend或front。进入这个目录后先装依赖npm install这一步在国内网络环境下可能比较慢有耐心的可以用默认源。如果是着急调试把registry切换成国内镜像源也行npm config set registry https://registry.npmmirror.com依赖装完之后启动开发服务器npm run serveVue的调试服务器默认跑在8080端口但后端接口也占了8080两个会冲突。这里有两种解法推荐先看后端的配置。后端在application.yml中如果配了server.port8080前端开发服务器的默认端口就可以改成8090或其他。这个项目如果先启动了后端前端本身会提示端口冲突选择换一个新端口就好。如果前端和后端不在同一个端口下运行就涉及跨域问题。这套源码大概率在后端的WebConfig或CorsConfig里已经配置了跨域放行如果没有最简单的办法是在Vue项目的vue.config.js里配置devServer的proxy代理把接口请求全部proxy转发到后端端口。前端页面用相对路径请求/api就不会再有跨域烦恼。这一套逻辑不只是本项目的经验凡是前后端分离的项目都是同样操作模式。3.5 前后端联调的标准验收清单全部启动后不要急着说部署成功建议按下面的清单走一遍完整流程任何一步卡住都能快速定位问题的归属端。我将这个项目验证通过的检查项整理成了一张快速验收表检查项预期结果归属端访问前端首页页面正常渲染无白屏报错前端注册一个新用户注册成功数据库user表多一条记录后端数据库登录后进入后台跳转正常能展示当前用户信息前后端配合创建一份问卷问卷出现在列表中状态为草稿后端前端发布问卷并复制填答链接链接能正常打开答题页前端提交一份答卷答题页提示成功后端入表后端数据库查看统计报表选项分布和图表正确后端前端这七步走通系统主干功能就全部验证过了。后续再去填一些边界功能比如编辑题目、数据导出等就会顺很多。4. 常见问题与排查技巧实录4.1 启动类问题端口被占与依赖冲突实际跑项目最常遇到的就是两类启动问题。一个是端口被占用另一个是依赖版本冲突。端口被占用的报错信息一般是Port 8080 was already in use。如果你本机之前跑过其他Java服务或者有别的开发工具占了8080后端就起不来。最省事的解决办法是改后端端口在application.yml里改server.port比如改成8090。同时前端所有请求的baseURL也要同步改如果前端配置里写死了8080记得一并调整。依赖冲突更多发生在Maven下载阶段。项目能“直接运行”的前提是你本地Maven仓库里有正确版本的依赖。如果下载过程中断或者本地仓库里存在旧版本的jar包会抛出NoClassDefFoundError或BeanCreationException。遇到这种问题优先试一次强制刷新mvn clean package -U-U参数强制让Maven检查远程仓库的更新版本对付依赖版本不一致有奇效。还需要确认一下你的Maven全局配置里settings.xml的镜像地址是否可靠国内环境经常因为默认远在国外下载到一半就超时把这个配置好能省下一大半的折腾时间。4.2 数据库连接的经典报错Public Key Retrieval is not allowed这是一个极具代表性的MySQL 8.0踩坑点。如果你本机用的是MySQL 8.0以上跑这个项目时后端日志里出现了Public Key Retrieval is not allowed不要慌不是项目本身有问题而是MySQL 8.0默认的caching_sha2_password认证插件不允许客户端在非SSL连接时直接请求公钥。有两个解决方向二选一即可。一个是连接串里加参数jdbc:mysql://localhost:3306/survey_db?allowPublicKeyRetrievaltrueuseSSLfalse另一个是把数据库用户的认证方式改成mysql_native_passwordSQL语句如下ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY 你的密码;这两种方法第一种改起来快不影响数据库全局配置第二种对老旧客户端兼容性更好实际选哪个都行。4.3 前端白屏Node版本过低与依赖缺失前端起不来或者起来后白屏大概率卡在两个地方。第一Node.js版本过旧。Vue CLI的现代版本对Node的版本要求最低在12以上如果你还在用8或10启动时就会直接报错或卡在编译阶段。用node -v先确认自己的版本如果版本过低去官网装一个LTS版本即可。第二node_modules目录不完整。很多从Gitee或网盘下载的压缩包并不会连同node_modules一起打包因为体积太大且不通用如果你没有执行npm install或者这个过程中断启动后页面就会因为缺模块而渲染失败。判断方法很简单打开前端dist或src下的入口文件浏览器F12打开控制台如果看到一堆Module not found的红色报错就是依赖不全重新执行一次npm install并确认安装过程成功到100%。4.4 功能性问题答题完成后统计结果不刷新这是一个比较隐蔽的逻辑层面的坑。问卷创建者填完问卷、查看统计报表时发现数据不是最新的或者提示“暂无数据”。排这个问题的思路要先从数据链路从上往下捋。打开数据库查询answer表看你刚才提交的那份答卷是否真的落库了。如果表里没有说明提交接口出问题检查前端控制台提交请求的返回状态如果表里有那就是统计接口的SQL逻辑问题常见的原因是统计时条件筛选里多了不必要的状态判断比如只统计某种状态的答卷而真实数据里状态值不一致。我这几次帮用户排查九成以上都卡在第一步——接口请求根本没有成功发送到后端。前端提交按钮的校验逻辑过多有一项没通过请求压根就没发出去。所以排查顺序建议固定为前端请求是否发出 - 后端是否收到并返回 - 数据库是否写入 - 统计接口是否读出来。这个顺序在问卷系统里几乎是通用的排查路线。5. 快速上手心得与扩展建议5.1 最省时间的上手路径如果你刚拿到这套源码别急着打开IDE就直接跑。我的建议是先花十分钟看README和目录结构摸清楚前后端各自的位置再去改配置。磨刀不误砍柴工这个习惯在接手任何开源项目时都适用。对于学生朋友我还有一个额外建议在能完整跑通的基础上试着在问卷题目类型里加一种新题型。比如现在只有单选、多选、填空你可以尝试加一个“评分题”1到5星打分。这个扩展会同时涉及数据库取值、后端类型判断、前端动态渲染、统计图表适配四个层面的修改把这条链路走通你对这个项目的理解会瞬间从“会用”升级到“懂原理”比背十遍八股文都管用。5.2 部署到服务器的路线参考本地跑通了下一步通常是部署到云服务器上。部署时需要将前端项目进行构建npm run build构建完成后会在dist目录下生成一堆静态文件。这些静态文件可以直接用Nginx托管然后通过Nginx反向代理把/api路径转发到后端的Spring Boot服务上。后端侧打包也类似mvn clean package -DskipTests生成的jar包直接在服务器上用java -jar运行即可。如果服务器内存比较小比如只有1G可以在运行命令里加参数限制JVM内存java -jar -Xms256m -Xmx512m questionnaire-system.jar我在部署过程中还习惯给服务器开一个定时任务每天自动备份一次数据库。做法简单用crontab加一条mysqldump命令就行。问卷系统的数据一旦上线会持续增长没有备份机制就像把文件只放在桌面不备份到网盘一样风险太大。5.3 记录一个数据安全的合规提醒最后给所有要实际运营问卷系统的朋友提个醒收集用户填答数据时如果问卷里包含手机号、姓名、身份证等个人信息尽量不要明文存储后端可以在入库前用哈希或加密算法处理。另外完整的答卷明细在统计完有效问卷数量后可以考虑定期物理删除或脱敏。我在实际项目中见过不止一次因为问卷数据泄露引发的纠纷。系统源码再完善也只是工具数据安全意识和存储规范才是你自己要守住的底线。这两条做到位问卷系统才能真正用得长久。