企业官网建设流程全解析

每年三到五月，总能在各种技术群里看到同一类问题：“毕设选什么题好”“SpringBoot+Vue有没有成熟项目可以抄”“问卷系统源码哪里有”。如果目标是稳定通过、拿一个体面的分数，我通常直接推荐在线问卷调查系统。它不是最炫的选题，但却是SpringBoot+Vue+MySQL这套组合里性价比极高的选择：业务闭环完整、需求边界清晰、前后端工作量都体现得出来，论文也好写。这篇博客就基于一个完整跑通的毕业设计项目，从选型、数据库设计、后端接口、前端交互到论文和部署文档，把整个产出过程讲透，顺便把那些只有动手做一遍才会踩到的坑一并列出来。

1. 为什么毕设选“在线问卷调查系统”最不容易翻车

1.1 一套系统串起三个技术栈的硬核考点

很多人看到“问卷调查”四个字，潜意识里觉得这就是个平平无奇的增删改查项目。但实际上，它比普通的管理系统多了好几个值得深挖的技术点。

第一，问卷数据结构天然是一对多、多对多的嵌套关系。一张问卷包含多道题目，一道选择题包含多个选项，一份答卷对应多条答案明细。这意味着你的表结构必须拆开设计，后端必须处理事务，前端必须做动态渲染。

第二，题目类型是可扩展的。单选、多选、填空、评分，甚至矩阵题、下拉题，每种题型在数据模型和前端渲染上都不同。这就逼着你把“题目类型”抽象成一种可枚举、可扩展的机制，而不是在页面上写死。

第三，统计报表是项目的加分项。发布出去的问卷，回收之后要能按题目维度做聚合分析，画饼图、柱状图、评分分布图。这部分同时考到MySQL的聚合查询能力和前端可视化组件的使用。

第四，系统存在真实角色划分。管理员创建问卷、发布问卷、查看答卷；普通用户登录后填写问卷、查看自己参与的记录。有权限控制、有JWT认证，这正好补齐了Web应用最基础的安全设计。

把这些点做完，一套系统的技术栈覆盖密度已经很高了：SpringBoot负责接口、事务、认证鉴权，Vue负责组件化、动态渲染、状态管理，MySQL负责表设计、索引、聚合统计。简历上写“独立完成问卷系统全栈开发”，面试官不会觉得水。

1.2 和其他热门毕设题比，优劣势在哪里

每年毕设热门题无非是学生管理系统、图书管理系统、二手交易平台、商城系统、博客系统。问卷系统跟它们比，优势在于“动态性”。

学生管理、图书管理这类题目的数据模型非常固定，学生表、图书表、借阅表，翻来覆去就是字段CRUD，做完之后技术亮点不大，论文里“系统设计”一章很难写出花。商城系统和博客系统虽然功能多，但需求边界容易被自己扩得很大，做不完是常态。

问卷系统的需求规模恰好处于中间位置：说简单，它确实没有支付、没有秒杀；说复杂，它有动态表单、有嵌套数据结构、有统计聚合、有重复提交防护。这个复杂度对于本科毕设来说刚刚好——不会因为功能太少被质疑工作量，也不会因为功能太多导致烂尾。

1.3 想让项目不“撞脸”，这几个差异化方向很好用

基本版的问卷系统确实烂大街，但只要加一两个亮点，就能让项目在答辩时明显拉开差距。我见过并且亲测好用的方向有这几种：

• 逻辑跳题：根据用户对上一题的答案，决定下一题是否展示。这在前端是一个computed属性+条件渲染，在后端是给题目增加“跳转条件”字段，实现成本不高，但答辩时一说“支持智能问卷逻辑”，老师印象分会上来。
• 问卷模板复用：把常用问卷保存为模板，创建新问卷时一键导入。本质是对问卷表做一个深拷贝，代码量不大但能体现设计深度。
• 回收数据交叉分析：比如“不同年龄段的用户对某项功能的满意度差异”，本质是两个维度组合的GROUP BY查询，统计页面用交叉表或堆叠柱状图展示。
• 作答时长与回收率统计：答卷表记录作答耗时，问卷列表展示发布后的回收率，这些数据口径可以让论文的需求分析章节更丰满。

挑其中一个做进去就够，不用贪多。重点是让老师能指着某个页面问“这个功能是怎么实现的”，你能从头到尾讲明白。

2. 架构与数据库设计：ER图之外的几个关键决策

2.1 技术选型：版本定不对，后面全是坑

这套系统选用的技术栈是SpringBoot 2.7.x + MyBatis-Plus + MySQL 8.0 + Vue 3 + Vite + Element Plus + ECharts，认证用JWT。

为什么SpringBoot选2.7而不是3.x？核心原因是3.x要求JDK17，并且包名从javax改成jakarta，网上大量教程、博客、博客参考代码都是基于2.x的。毕设本来时间就紧，没有必要在这种地方给自己增加排错成本。JDK用8或者11都行，我实测用JDK8配合SpringBoot 2.7.x最稳，启动快、报错少。

MyBatis-Plus值得专门推荐一下。用原生MyBatis写单表CRUD太啰嗦，MyBatis-Plus提供了BaseMapper，大部分增删改查一行都不用写XML，只有统计报表这种复杂查询才需要手写SQL。对毕设来说，这意味着你能把更多时间花在业务逻辑上，而不是死在Mapper文件里。

前端这边，如果你对Vue 2更熟，用Vue 2 + Element UI完全没问题；如果本来就打算学Vue 3，那就直接上Vue 3 + Vite + Element Plus。我的建议是：哪个熟用哪个，别在毕设阶段临时切换大版本。Vite相比Webpack的优势是开发环境下秒级热更新，对调试问卷编辑器这种复杂交互帮助很大。

MySQL推荐8.0。5.7虽然也够用，但8.0的窗口函数和更好的默认字符集支持，会让统计SQL的写法更舒服。安装时字符集一定要选utf8mb4，排序规则可以选utf8mb4_general_ci，否则后面插入中文极容易变成问号。

2.2 六张核心表：每个字段都对应一个明确的理由

整个系统我拆成六张表：用户表、问卷表、题目表、选项表、答卷主表、答卷明细表。

用户表保存登录账号和角色信息。密码字段必须存BCrypt加密后的密文，绝对不能明文入库。角色字段用tinyint，0是管理员、1是普通用户，程序里用常量类或枚举对应。

问卷表存问卷本身的基本信息。这里最值得关注的是status字段，我建议用0草稿、1已发布、2已关闭三个状态。为什么不用字符串？因为tinyint在索引和比较上更高效，程序里用一个枚举类定义，可读性不会比字符串差。匿名标记字段决定用户填写时是否需要登录，这个在需求分析阶段就要确认清楚。

题目表和选项表是典型的父子表关系。题目表通过questionnaire_id关联问卷，sort_order控制题目在问卷中的排序，type字段标记题型。选项表通过question_id关联题目，同样有sort_order。这里有一个我踩过坑的细节：前端编辑器里需要一种本地临时ID来标识每道题，不要直接拿数据库主键当唯一标识，否则新增题目还没入库时，主键是空的，排序和删除时会出各种奇怪问题。

答卷主表和答卷明细表负责回收数据。answer_record记录“谁在什么时间填了哪份问卷”，answer_detail记录“这道题选了哪个选项或填了什么文本”。主从分离的原因很简单：如果每道题答案直接挂在records表的一行里，统计“第5题选A的人有多少”时，就只能用字符串匹配，效率低且不优雅。

给一个精简版的建表SQL片段：

CREATE TABLE questionnaire ( id BIGINT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(100) NOT NULL COMMENT '问卷标题', description VARCHAR(500) DEFAULT '' COMMENT '问卷说明', status TINYINT NOT NULL DEFAULT 0 COMMENT '0草稿 1已发布 2已关闭', anonymous TINYINT NOT NULL DEFAULT 0 COMMENT '0实名 1匿名', start_time DATETIME DEFAULT NULL, end_time DATETIME DEFAULT NULL, create_user_id BIGINT NOT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_create_user_id (create_user_id), KEY idx_create_time (create_time) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='问卷表'; CREATE TABLE question ( id BIGINT PRIMARY KEY AUTO_INCREMENT, questionnaire_id BIGINT NOT NULL, sort_order INT NOT NULL DEFAULT 0, type TINYINT NOT NULL COMMENT '1单选 2多选 3填空 4评分', title VARCHAR(255) NOT NULL COMMENT '题干', required TINYINT NOT NULL DEFAULT 1 COMMENT '是否必填', KEY idx_questionnaire_id (questionnaire_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='题目表';

2.3 索引和唯一约束：防重复提交的“免费保险”

数据库设计阶段就要把索引和唯一约束想好，不要等数据量大了再回头加。

answer_record表上有一个联合唯一索引，这是防止同一用户重复提交问卷的关键手段：

CREATE TABLE answer_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, questionnaire_id BIGINT NOT NULL, user_id BIGINT NOT NULL, answer_time DATETIME NOT NULL, duration INT DEFAULT 0 COMMENT '作答耗时秒数', ip VARCHAR(64) DEFAULT '', UNIQUE KEY uk_questionnaire_user (questionnaire_id, user_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='答卷主表';

这个唯一索引的妙处在于，哪怕后端代码里忘了做重复校验，数据库层也会直接拒绝第二次插入。这属于“防御性设计”，答辩时老师问“怎么防止同一用户反复提交”，你就可以从应用层校验和数据库约束两个层面回答，显得考虑周全。

统计查询通常集中在answer_detail表上，所以创建联合索引(questionnaire_id, question_id)。配合唯一索引的record_id，可以快速从明细表反查答卷主表。

单选题的统计SQL长这样：

SELECT qo.option_text, COUNT(ad.id) AS answer_count FROM answer_detail ad JOIN question_option qo ON ad.option_id = qo.id WHERE ad.question_id = #{questionId} GROUP BY ad.option_id, qo.option_text ORDER BY answer_count DESC;

这里为什么一定要JOIN选项表？因为answer_detail只存option_id，没有冗余option_text。如果直接按option_id分组，统计结果里只有数字ID，前端还得再做一次映射。JOIN选项表拿文本，一次查询直接得到“选项文本+数量”，前端组装图表数据就非常省事。多选统计稍微不同，需要先对option_id做子查询拆分，因为一个答案记录里可能存了多个选项ID，我的做法是明细表每行只存一个选项ID，多选题拆成多行插入，统计逻辑就和单选完全一致了。

3. SpringBoot后端：接口设计、动态题型存储和防重复提交

3.1 接口清单：围绕业务的完整闭环

后端接口设计遵循RESTful风格，按模块划分。整体可以分为认证模块、问卷管理模块、答卷模块、统计模块。

字段级别还要注意：所有接口返回统一使用Result 结构，包含code、message、data三个字段。为什么要统一？因为前端axios拦截器可以统一处理错误码，不用每个接口单独写try-catch。项目里再配一个全局异常处理器，用@RestControllerAdvice捕获业务异常和系统异常，返回给前端的就是规整的JSON错误信息。

3.2 动态题型如何入库：先删后插的事务策略

问卷编辑器最终提交上来的是一个嵌套JSON结构：问卷包含题目列表，题目包含选项列表。这也是前后端联调时最容易出问题的地方。

我的处理思路是：后端定义QuestionnaireCreateDTO，内部包含List ，QuestionDTO内部包含List 。Controller收到之后，直接在Service层完成拆解入库。

这里有一个很重要的策略：更新问卷时不要去做复杂的Diff对比，直接用“先删后插”。也就是在同一个事务里，先把该问卷下的旧题目和旧选项全部物理删除，再按照提交上来的最新结构重新插入。好处是逻辑极其清晰，不存在“哪些题目没变、哪些选项要保留”的繁琐判断，代码量小且不容易出Bug。

但先删后插有个前提——同一份问卷如果已经有用户提交了答卷，删除题目会导致历史答卷明细失去关联。所以我的做法是：问卷在草稿状态下允许自由编辑，一旦有答卷记录，就提示管理员必须先关闭问卷或创建新问卷。这个限制在业务上也说得通：问卷发布后不允许改题，否则统计口径就乱了。答辩时把这个规则讲出来，老师会觉得你有业务思维。

核心代码大致是这样：

@Transactional public Long createOrUpdateQuestionnaire(QuestionnaireCreateDTO dto) { Questionnaire questionnaire = new Questionnaire(); questionnaire.setTitle(dto.getTitle()); questionnaire.setDescription(dto.getDescription()); questionnaire.setStatus(0); questionnaireMapper.insert(questionnaire); if (CollectionUtils.isEmpty(dto.getQuestions())) { throw new BizException("问卷至少需要一道题目"); } for (QuestionDTO q : dto.getQuestions()) { Question question = new Question(); question.setQuestionnaireId(questionnaire.getId()); question.setType(q.getType()); question.setTitle(q.getTitle()); question.setRequired(q.getRequired()); question.setSortOrder(q.getSortOrder()); questionMapper.insert(question); if (q.getType() == QuestionType.RADIO.getCode() || q.getType() == QuestionType.CHECKBOX.getCode()) { if (CollectionUtils.isEmpty(q.getOptions()) || q.getOptions().size() < 2) { throw new BizException("选择题至少需要两个选项"); } for (OptionDTO o : q.getOptions()) { QuestionOption option = new QuestionOption(); option.setQuestionId(question.getId()); option.setOptionText(o.getOptionText()); option.setSortOrder(o.getSortOrder()); optionMapper.insert(option); } } } return questionnaire.getId(); }

注意@Transactional注解，它保证了问卷表、题目表、选项表的写入要么全部成功，要么全部回滚。如果少了事务，可能出现“问卷建好了但题目没插进去”这种脏数据，而且极难排查。把事务、校验、异常处理三者组合好，后端核心逻辑就已经完成了大半。

3.3 提交答卷：匿名与实名场景下的幂等设计

提交答卷是整个系统并发压力最高的入口，也是数据一致性要求最严格的模块。

流程拆解为四步：第一步，校验问卷存在且状态为已发布；第二步，校验用户是否已经提交过，如果提交过直接返回提示；第三步，插入answer_record获得主键ID；第四步，遍历答案列表，逐条插入answer_detail。

防止重复提交的最终防线是数据库联合唯一索引，但代码里同样要写判断。为什么两处都要做？因为应用层的查询和插入之间存在时间窗口，两个并发请求可能同时通过“是否提交过”的校验，然后同时插入成功。此时唯一索引会拦住其中一个，让它抛出DuplicateKeyException。把这个异常捕获后转成“您已提交过该问卷”的友好提示，系统就稳了。

如果问卷开启了匿名模式，就没有user_id可用了，可以用IP地址+浏览器指纹（User-Agent）组合作为标识，或者干脆不做一人一次限制，只记录IP。这块取舍要在论文里写清楚：实名问卷强约束，匿名问卷弱约束。

答案明细的统一数据模型设计也很关键。明细表同时保留option_id和answer_text两个字段：单选/多选题写option_id，填空题写answer_text，评分题两个都用上。这样一张表就能兼容所有题型，统计和导出都方便。

3.4 权限控制：JWT要比Spring Security更适合毕设

很多同学一听权限设计就想到Spring Security，然后被它的过滤器链和配置类折磨一整天。我的建议是：毕设阶段完全可以不用Spring Security，用简单的JWT拦截器方案就够了，代码量小，逻辑自己完全可控。

具体做法是：登录成功生成一个token，里面放入userId、username、role，密钥放在配置文件里；后端写一个AuthInterceptor，实现HandlerInterceptor接口，在preHandle方法中解析请求头里的Authorization字段，校验token有效性，然后把当前登录用户信息放进ThreadLocal。这样Controller层通过UserContext.getUserId()就能拿到当前用户，不用每个接口都从参数里传userId。

管理端接口再通过自定义注解加一个角色判断，比如@RequireRole(Admin)，在拦截器里校验角色是否符合。这套方案在答辩时可以理直气壮地解释为“基于JWT的无状态认证，配合拦截器实现接口粒度权限控制”，而且面试官问起来，你对每一行代码都是清楚的，不会被几个Security配置类问住。

4. Vue前端：问卷编辑器、动态渲染和统计图表的实现思路

4.1 前端工程结构：按模块拆组件，避免单文件失控

前端设计很容易出现一个误区：把问卷编辑器所有功能堆在一个组件里，写了两千行还在继续加。正确的做法是先把工程结构按职责拆好。

我的项目结构大致是这样：

src/ api/ # axios请求模块 router/ # 路由配置 store/ # Pinia状态管理 views/ login.vue # 登录页 admin/ QuestionnaireList.vue # 问卷列表 QuestionnaireEdit.vue # 问卷编辑器 Statistics.vue # 统计图表页 fill/ FillQuestionnaire.vue # 用户填写页 components/ editor/ # 编辑器相关组件 QuestionPanel.vue # 左侧题库面板 CanvasPanel.vue # 中间画布 PropertyPanel.vue # 右侧属性面板 answer/ # 填写页动态组件 RadioQuestion.vue CheckboxQuestion.vue TextQuestion.vue RateQuestion.vue

这样拆分的好处是：问卷编辑器的三栏布局各司其职，新增一种题型时，只需要在编辑器的题库面板加一个入口、新建一个answer组件，其他部分不需要大改。这种可扩展性在论文的“系统详细设计”章节可以直接作为设计亮点写进去。

4.2 编辑器三栏布局：左侧题库、中间画布、右侧属性

问卷编辑器是整个前端最难写的部分，我当时花了整整两天才把交互理顺。核心布局是左侧题库面板、中间画布、右侧属性面板。

数据模型使用一个响应式的问卷对象：

const questionnaire = reactive({ title: '', description: '', questions: [] })

每道题在前端模型里包含本地id、题型、题干、是否必填、选项列表。本地id用uuid或Date.now()生成，在和数据库主键区分开的同时，保证每道题在拖拽排序、删除时都能被准确找到。

中间画布的题目排序推荐使用vuedraggable组件，拖拽完成后重新计算每道题的sortOrder。这里有一个容易忽略的细节：拖拽的是题目在数组中的顺序，保存时要把数组索引作为sortOrder传给后端，否则刷新页面后题目顺序就乱了。

右侧属性面板负责配置选中题目的属性：选项文本增删、是否必填、题目类型切换。当选中的题目类型切换时，要注意清空选项列表，否则会出现“单选题变成多选题但老选项还留着”的奇怪状态。编辑器的整个状态都保存在前端，只有点击“保存问卷”时才提交到后端。为什么这样设计？因为编辑过程是高频率交互，每动一下都请求后端不仅慢，还会让数据库负载变大，而且草稿状态的编辑本来就不需要实时持久化。

4.3 填写页动态渲染：用组件映射处理所有题型

填写页是所有普通用户真正交互的页面，核心需求是根据题型动态渲染对应控件。实现方式不复杂：遍历问卷详情里的questions数组，用component动态组件根据type渲染不同子组件。

<component :is="componentMap[question.type]" :question="question" :model-value="answers[question.id]" @update:model-value="answers[question.id] = $event" />

componentMap是一个对象映射，key是题型编码，value是对应的组件。这样新增一种题型，只需要注册一个新的组件，不用在页面里堆一堆v-if。

填写页的数据收集要特别注意：用一个普通对象answers来保存所有题目的答案，key是题目id，value根据不同题型分别是单个选项ID、数组、字符串或数字。提交时再组装成后端要求的格式。这块前后端字段如果没有对齐，联调阶段会浪费大量时间，我的经验是先写接口文档再动手写代码，哪怕是只有自己能看的简易文档，也比边写边猜强。

问卷填写页还需要处理一个逻辑跳题的场景：比如用户选了“否”，后面两道满意度题就不应该展示。这个可以在组件树外层套一个v-if，根据所在题目的跳题条件和当前答案对象实时计算是否渲染。不要试图改题目数组本身，只控制显示与否，这样答案对象的数据结构始终稳定。

4.4 统计图表：数据结构和ECharts的组装技巧

统计模块是让项目“看起来高级”的关键页面。后端返回每个题目的统计结构，前端统一渲染。

对于单选题，后端返回的数据格式是：

{ "questionId": 1, "type": 1, "title": "您的年龄段", "options": [ { "optionText": "00后", "answerCount": 23 }, { "optionText": "90后", "answerCount": 45 } ] }

前端拿到这个结构，直接组装成ECharts饼图的data数组：

chartData.value = data.options.map(item => ({ name: item.optionText, value: item.answerCount }))

多选题的统计结果类似，只是总数可能大于答卷总数。评分题我习惯用两个图表：一个柱状图展示各分数人数分布，一个直接显示平均分大数字，视觉效果很好。

用ECharts有三个容易踩的坑：第一，图表容器必须有显式高度，否则render不会出图；第二，组件卸载时务必调用chart.dispose()，否则路由切换会导致内存泄漏，控制台会报“ResizeObserver loop”警告；第三，图表数据是异步获取的，容器要先渲染出来再初始化图表，否则宽度为0，图表会挤成一团。我的解决方案是在拿到数据后用nextTick再调用setOption。

5. 论文和部署文档：源码之外那50%的毕设工作量

5.1 论文结构怎么安排才能避开“说明书”差评

论文是毕业设计评分的重头戏，很多项目源代码写得不错，论文却被批“像用户手册”，原因就是只会贴截图和代码。

标准的论文结构是摘要、绪论、相关技术介绍、需求分析、系统设计、系统实现、系统测试、总结展望。需求分析部分不要只写“用户需要登录后创建问卷”，要配合用例图和用例描述表格，至少写出管理员、普通用户两类角色的完整用例。系统设计部分画系统架构图、功能模块图、数据库ER图，加上核心表结构的说明。系统实现部分挑三四个核心业务流程展开，比如问卷创建流程、答卷提交流程、统计报表流程，配核心代码片段和运行截图，其他普通功能一笔带过。

最容易拿分的其实是系统测试章节。写一份功能测试用例表，列出用例编号、测试场景、操作步骤、预期结果、实际结果、是否通过，表格做到二十条以上。老师一看就知道你确实跑过完整测试，而不是写完代码就扔那儿了。

论文里不建议大段贴SQL，更不建议把整个Controller源码复制进去。只需要把关键设计思路、核心代码片段、方法时序逻辑讲清楚就行。论文的意义是证明你理解这个系统是怎么运转的，不是证明你会用Ctrl+C。

5.2 部署文档要写什么：照着这个清单做就能跑起来

部署文档是很多同学最后才补的东西，但如果你打算把项目挂到简历或者GitHub上，这一步写好了会非常加分。

我的部署文档内容包括五部分。第一，环境版本清单，明确写出JDK、Maven、Node、MySQL、Nginx的版本号。第二，数据库初始化步骤，告诉读者执行哪个sql脚本，以及application.yml里的数据源配置该怎么改。第三，后端打包运行，mvn clean package生成jar包，再用java -jar启动。第四，前端构建，npm install、npm run build生成dist目录。第五，Nginx配置，把dist目录作为网站根目录，并把接口请求反向代理到后端。

一个标准的Nginx配置片段是这样：

server { listen 80; server_name your-domain.com; root /opt/questionnaire-front/dist; index index.html; location / { try_files $uri $uri/ /index.html; } location /prod-api/ { proxy_pass http://127.0.0.1:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

location /里的try_files配置必须写，否则Vue路由开启history模式后，刷新页面会404。这个问题很多人部署完才发现，其实就是Nginx不知道前端路由应该回退到index.html。

5.3 演示视频和PPT的准备思路

答辩演示顺序建议是：登录演示→创建问卷，现场添加单选、多选、填空、评分几类题目→发布问卷→用另一个测试账号填写问卷→管理员查看答卷列表→查看统计图表页面。整个过程控制在八分钟以内，录屏时字体尽量放大，操作速度放慢。

PPT控制在10到12页。第一页是题目和基本信息，第二页讲选题背景和意义，第三页是需求分析，第四页是系统总体架构，第五页是数据库设计，第六到第八页放核心功能截图，第九页是系统测试情况，第十页是总结与展望。别把PPT做成代码展示会，页面里不要贴大段代码，老师看PPT的时间很短，只会关注截图和关键词。

6. 实测踩坑记录：从环境搭建到答辩现场的高频问题

6.1 环境与部署常见的坑，附解决方案

这些坑我全部亲自踩过，列出来给后面做的人省点时间。

跨域问题多说一句。开发环境下我用后端CorsFilter解决，生产环境用Nginx反代。如果你直接用Vite的proxy代理，前端请求路径也要统一加前缀。前后端联调时最怕的就是“一会儿能通一会儿不能通”，根源往往是CORS配置和代理配置混用。

6.2 答辩老师最爱问的问题，提前准备好答案

整理几个我统计过的高频问题，附上参考回答思路。

“为什么选MySQL不选Oracle？”回答要点：MySQL开源免费，社区资料丰富，安装维护成本低，对于本系统量级的数据，性能和稳定性已经完全够用。Oracle更强的地方在于企业级分布式场景，但学习和部署成本都更高，不适合作为毕设选题的主要数据库。

“如果数据量大，系统怎么扩展？”回答要点：分层次回答。首先是索引优化，所有查询字段都建索引；其次是加Redis缓存热点问卷和统计结果；如果单表数据量真的大到千万级，可以采用分表分库和数据归档策略。毕设阶段做到前两步就完全够讲。

“题目类型怎么扩展？”回答要点：后端新增type枚举值，前端新增对应的动态渲染组件，问卷编辑器题库面板加一个入口，校验规则再补上。因为系统设计时已经通过type字段和动态组件做了解耦，加题型不需要改主体流程。

“同一用户重复提交怎么办？”回答要点：应用层在提交接口里查询是否已存在答卷记录，数据库层再用联合唯一索引兜底，出现DuplicateKeyException统一捕获并提示。两条防线同时生效。

“项目如何防SQL注入？”回答要点：使用MyBatis-Plus的参数占位符机制，所有SQL参数都是预编译绑定，杜绝字符串拼接。前端使用编码组件进行用户输入内容转码，防止XSS攻击。

6.3 让老师打分更高的代码规范加分项

代码规范属于隐性评分点，很多项目功能完整但分数上不去，问题往往出在这一块。

统一返回结果类。所有接口不要直接返回Map或者裸数据，统一用Result 包裹，Controller层代码会清爽很多，前端axios拦截器也容易做统一处理。

全局异常处理器。用@RestControllerAdvice注解写一个GlobalExceptionHandler，把业务异常NotFoundException、参数异常MethodArgumentNotValidException分别处理。这样Controller里只用写正常流程，异常全部抛出去由全局处理器兜底。

Service接口加实现类。Controller只负责接收参数和调用Service，业务逻辑全部在Service实现里。像单表CRUD的项目不需要这么讲究，但问卷系统的题目保存、答卷提交这种业务复杂逻辑，拆接口实现是合理的。

参数校验用注解。DTO字段上用@NotBlank、@NotNull、@Size注解，Controller方法参数加@Validated。至少占比很重的“参数校验”在论文里能写成一节。

考虑到时间是有限的，这里给一个明确的项目时间规划参考：数据库设计1天，后端核心接口3天，前端管理端3天，前端填写页加统计2天，测试修Bug2天，论文撰写4天，部署文档加演示录制1天。整体节奏控制在三周左右，留出足够缓冲时间应对突发情况。

最后分享一点个人体会。做这种毕业设计系统，真正拉开差距的不是堆功能数量，而是面对“为什么这么做”的问题时，你能不能从表结构、事务、索引、组件拆分这些具体决策开始讲起，一直讲到业务闭环。我在做完这个问卷系统之后，最明显的感受是：SpringBoot和Vue并不是被“用”会的，而是被一个个真实问题逼着“查”会的。每当遇到一个之前没见过的报错，解决之后把原因记下来，这些东西比项目本身值钱得多。希望这份完整的拆解过程，能让正在做同类题目的你少走几条弯路。