计算机毕业设计选题这件事每年都能看到同样的场面教务系统里题目翻了一百多个热门题被抢完剩下的不是太旧就是太偏。如果选题名额还没定我建议你优先看看“基于Spring Boot的教学辅助问答系统”这个方向。它是一个学生课后提问、教师在线答疑的轻量教学辅助平台核心价值是把“课堂没人提问、课后没人答疑”的场景搬到线上做成一个能支撑知识点分类、问题流转、最佳回答采纳的完整闭环。对正在找毕设题目的计算机专业学生来说这个题的好处非常具体难度处于“跳一跳够得着”的区间技术栈是Java岗位最常见的Spring Boot组合前后端分离的架构也方便写进简历和答辩PPT。这个题目每年都有人选但真正做完做好的并不算多。多数问题不是卡在技术上而是卡在范围失控、文档注水、验收时讲不清楚。这篇内容我会从选题价值、需求拆解、技术选型、数据库设计、后端落地、前端联调、论文撰写到答辩演示完整讲一遍这类系统从0到1怎么做才不容易翻车顺便把最影响进度的几个隐藏雷区也复盘出来。1. 为什么“教辅问答系统”是毕业设计里的常青树1.1 规模与难度恰好在“可完成”区间一个合格的毕设题目难度不能低到几个晚上就抄完也不能高到做半年还看不到成品。教辅问答系统正好卡在中间位置它比学生管理系统、博客系统多了一层业务互动深度又远够不到电商、大型后台那种订单、支付、库存的复杂联动。核心业务就是“用户提问、用户回答、教师采纳”。数据模型围绕用户、问题、回答、点赞、收藏、通知这几类实体展开关系清晰逻辑链路完整。对大多数普通水平的计算机专业学生来说用三个月左右的时间完成设计、编码、测试、写论文时间上是来得及的。如果深度刚好拉满做完之后还会有余力加几个扩展功能而不是被系统本身拖着走。1.2 技术栈经典直接对应岗位技能这个题目可以很自然地用到当前Java方向最主流的一套组合Spring Boot 提供后端服务、MyBatis Plus 或 Spring Data JPA 操作数据库、MySQL 存数据、Vue 负责前端页面、Redis 做缓存与热点数据。这套组合不是某个毕业设计机构的私货而是很多实际项目里真实在用的组合。做完这个题简历上可以写“独立设计并实现了一个基于前后端分离架构的在线问答系统”面试官想追问的点也基本都在可控范围内——JWT 认证、分页查询、表设计、接口幂等、跨域处理这些都能在这个项目里找到对应落点。比起写一个“员工考勤系统”问答系统的场景更常见也更容易聊出内容量。1.3 业务场景完整答辩时有话可说很多同学答辩翻车不是因为功能没做出来而是因为评委问“你这个系统解决了什么实际问题”时只能憋出一句“管理数据更方便”。教辅问答系统的场景天然好讲高校课程多学生课后有问题找不到统一反馈渠道老师也缺少一个集中答疑的窗口。系统把问题按课程分类学生提问、教师回答、最佳答案采纳配合热度排序和全文搜索形成一套教学辅助闭环。评委听你讲的时候不需要太多背景铺垫就能理解需求。这也意味着你的时间可以更多花在实现细节和亮点展示上而不是反复解释业务逻辑。综合来看这是一个“性价比”很高的选择。2. 功能需求拆解用三个角色把系统边界圈死2.1 学生端提问、浏览、互动需求分析阶段最忌讳的就是“想到什么写什么”。我当时给几个学生定功能边界时第一条原则是先按角色列功能再按优先级砍需求。学生端是这个系统最核心的使用者功能至少要包含注册与登录含退出登录和身份信息修改浏览问题列表按分类、热度、最新时间筛选发布问题填写标题、正文、所属课程分类查看问题详情在详情页发布回答对自己有帮助的问题和回答进行点赞收藏问题在个人中心查看收藏列表在自己的问题下采纳某条回答为最佳答案考虑让提问者有权采纳。这里有一个容易被忽略的设计点学生之间能不能互相回答很多第一次做这个题目的人会把“回答权”只给教师认为“教学辅助”就该是老师答。但实际上学生互答恰恰是问答社区活跃度的来源也是系统展示同伴互助学习氛围的亮点。我建议把回答权限放开给学生同时保留“教师回答标记”和“提问者采纳最佳答案”的机制这样既符合场景又增加了功能层次。2.2 教师端答疑、采纳、统计教师端不一定要单独做一个App在同一个Web系统里通过角色字段区分权限即可。教师登录后能看到属于自己课程分类下的问题列表可以对问题进行回答系统会给教师提问者的身份标识增强可信度。除了基础答疑教师端还可以有两个进阶功能第一个是“待解答问题提醒”——教师登录后在首页看到自己负责的分类下还有多少个未回答问题这个数据通过一条简单的分组查询就能实现但展示出来会非常亮眼。第二个是“答疑统计”按周统计回答数、被采纳数做成简单的柱状图或表格工作量不大但能让系统的“教学辅助”属性更立体。2.3 管理员端与“砍需求”清单管理员端负责系统的日常运营用户管理禁用、启用账号、问题分类管理新增、编辑、删除分类、问题内容审核删除违规问题或回答。还有一个可选项是数据大盘总用户数、总问题数、总回答数、每日新增趋势。这些数据用简单的COUNT查询就可以完成可以做成ECharts图表放首页。设计完功能后最重要的一步是列“砍需求”清单。很多毕设失败在范围蔓延做着做着就想加即时聊天、在线考试、视频课堂、积分商城、支付功能。我建议这些都不要做。原因很简单第一这些功能独立性强与问答主链路关系不大加了反而让系统臃肿第二答辩时评委一旦追问到这些扩展模块的技术细节你很难保证每个点都能答得圆满。好的范围控制是把主链路做完整、做精致而不是占满所有可能的坑位。3. 技术选型判断哪些组件值得进依赖清单3.1 Spring Boot版本与ORM选型Spring Boot 的版本选择我一般建议直接用 2.7.x而不是追新用 3.x。原因是毕业设计阶段你大概率会遇到网上各种资料和开源代码2.7 的生态最成熟遇到的兼容问题最少。3.x 虽然也稳定但部分依赖和写法有差异网上查解决思路时容易浪费时间。这不是说 3.x 不好而是毕设的核心目标是顺利跑通和完成论文没必要在版本兼容性上多冒险。ORM 我推荐用 MyBatis Plus。它的优势很直接内置了单表 CRUD 方法不需要像原生 MyBatis 一样为每个实体手写 XML 映射同时保留了手写 SQL 的能力分页、多表关联、复杂查询可以自己控制。Spring Data JPA 也可以做但对多数学生来说JPA 的懒加载和级联操作比 MyBatis Plus 更容易踩坑调试成本更高。如果让我给一个确定性很高的组合那就是Spring Boot 2.7.x MyBatis Plus 3.5.x MySQL 8.0。3.2 前端框架Vue 2还是Vue 3前端框架取决于你自己的熟练度。如果你从头开始学我给的建议是直接学 Vue 3 Vite。Vue 3 的 Composition API 写起来逻辑更紧凑Vite 启动速度比 Webpack 快非常多调试体验也好。但如果你已经跟着老教程学过 Vue 2也不要为了“追新”临时切换。毕业设计的重要原则是“用自己最熟悉的技术栈”而不是“用最新版本”。Vue 2 的 Options API 对新手反而更直观数据、方法、生命周期函数分得清清楚楚。配合 Element UI 或 Element Plus 组件库管理后台的表格、表单、弹窗基本一天就能搭完。前端和UI框架的选型最终要服务于“在限定时间内做出稳定可演示的系统”。3.3 JWT、Redis和文件存储的取舍认证方案我建议用 JWT不要用 Session。前后端分离项目里JWT 是无状态认证的标配后端不需要保存会话状态前端把 token 放在请求头里即可。实现 JWT 的代码量不大核心是登录时生成 token、拦截器解析 token、返回 401 让前端跳登录。这个方案是很多真实项目的做法答辩时也容易解释。Redis 是另一个常见取舍点。说实话毕设的核心场景不使用 Redis 也完全能跑缓存热点问题、存验证码这些事情用数据库也能实现。但如果你的系统已经融入了 Redis比如把首页热门问题列表缓存起来设置 30 分钟过期刷新后从缓存读这会是一个非常好的扩展点。考虑到 Redis 在 Java 岗位面试中出现频率很高我建议做进系统里工程量不大但展示效果和答辩谈资都会上一个台阶。文件存储方面头像上传直接用本地磁盘存储即可不要引入对象存储服务。本地存储的流程是前端上传文件到后端接口后端把文件写入项目配置的 upload 目录再把访问路径返回给前端。答辩时评委问到文件存储你能讲清楚路径拼接、文件类型校验、大小限制就足够了。4. 数据库设计六张核心表的结构与字段取舍4.1 用户表一个角色字段解决三类人群用户表是整个系统的基础。我设计时没有把学生、教师、管理员拆成三张表而是放在同一张 user 表里通过 role 字段区分角色取值 0 表示学生、1 表示教师、2 表示管理员。这样做的理由是三类用户的基本信息高度重合都是昵称、账号、密码、头像、个人简介拆表反而会带来大量冗余和关联逻辑。角色不同只影响操作权限和页面展示并不影响数据存储方式。用户表的关键字段如下id、username登录账号、password加密存储、nickname昵称、avatar头像路径、role角色、gender性别、major专业/院系可选、create_time、update_time。需要注意两点一是密码必须加密不要存明文答辩时讲到安全性时这是最基本的隐藏得分点二是 create_time 和 update_time 都设置数据库默认值 CURRENT_TIMESTAMP避免后端每次插入都要手动赋值。4.2 问题表与回答表核心业务数据的落脚点问题表question是系统的核心实体。常见字段包括id、user_id提问人、category_id所属分类、title标题、content问题详情正文、status状态0 待解答 / 1 已解决 / 2 已关闭、view_count浏览量、like_count点赞数、is_top是否置顶、create_time、update_time。标题一般限制在 50 到 100 个字符content 使用 text 类型不要在实体里用 VARCHAR 存大段文本。这里有一个新手很容易踩的坑如果内容包含多段文本和图片text 字段默认只有 64KB富文本编辑器上传的图片建议存 URL不要把图片转成 Base64 直接塞进数据库否则后期数据量上来后数据库体积会迅速膨胀查询也会变慢。另一个容易忽略的点是建立索引user_id 和 category_id 是高频查询条件建普通索引即可状态 status 也可以建索引title 字段不需要建索引需要搜索时用 LIKE 查询或全文索引解决。回答表answer的字段则包括id、question_id所属问题、user_id回答人、content回答内容、is_accepted是否被采纳、like_count、create_time。is_accepted 默认值是 0提问者采纳某条回答后置为 1。一个问题上只需要一个被采纳的回答在“采纳最佳答案”的业务接口里要记得先把这个问题下之前的 is_accepted 全部重置为 0再更新当前选中回答的字段避免出现多个被采纳答案的数据脏状态。4.3 互动类表与消息表别小看这些“小表”除了核心表和回答表还要设计四张互动与辅助表分类表、点赞表、收藏表、通知表。分类表category字段最简单id、name、sort。不同课程就是一条分类记录教师按分类关联课程。点赞表like_record要注意的是同一个人对同一个问题只能点赞一次所以在 question_id 和 user_id 上要建唯一联合索引后端插入时捕获唯一索引冲突异常提示“你已经点过赞了”。收藏表favorite的结构类似同样用联合唯一索引防止重复收藏。通知表notification是很多学生容易漏掉的设计。实际业务中学生提问后教师回答提问者最好能收到一条未读消息提醒回答被采纳时回答者也应该收到通知。通知表的字段主要是id、user_id接收人、type类型1 回答通知 / 2 采纳通知 / 3 系统通知、content、is_read、create_time。有了这张表个人中心“我的消息”功能就能做起来系统完整度明显提高。有人可能觉得通知做起来麻烦但如果想让系统在答辩时有亮点这个功能投入产出比很高。以下是一个简化版的问题表建表语句可以直接拿去调整CREATE TABLE question ( id bigint(20) NOT NULL AUTO_INCREMENT, user_id bigint(20) NOT NULL COMMENT 提问人id, category_id bigint(20) DEFAULT NULL COMMENT 分类id, title varchar(100) NOT NULL COMMENT 标题, content text COMMENT 问题详情, status tinyint(4) DEFAULT 0 COMMENT 0待解答 1已解答 2已关闭, view_count int(11) DEFAULT 0 COMMENT 浏览量, like_count int(11) DEFAULT 0 COMMENT 点赞数, is_top tinyint(1) DEFAULT 0 COMMENT 是否置顶, create_time datetime DEFAULT CURRENT_TIMESTAMP, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_user_id (user_id), KEY idx_category_id (category_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT问题表;5. 后端接口落地从登录鉴权到提问回答的完整链路5.1 统一返回结构与全局异常处理写后端接口前先把“规范”定下来。接口返回格式统一成 Result 对象包含 code、message、data 三个字段。这样做的好处是前端所有请求都走同一套解析逻辑拦截器处理异常时也有统一出口。Data public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(success); result.setData(data); return result; } public static T ResultT error(String message) { ResultT result new Result(); result.setCode(500); result.setMessage(message); return result; } }配合 Result 的还要有全局异常处理。用 RestControllerAdvice 注解定义一个全局异常处理器捕获业务异常、参数校验异常、未知异常。这样接口内部不需要到处写 try-catch代码会干净很多。参数校验推荐在实体类字段上加 NotBlank、NotNull 这类校验注解异常处理器里统一返回“参数不合法”的提示前端拿到错误提示直接展示交互体验也更好。5.2 登录鉴权JWT的完整流程JWT 登录流程看起来简单真正落地时容易漏掉几个细节。完整流程是这样的用户提交账号密码后端查数据库验证密码是否正确验证通过后用用户的 id、用户名、角色生成 token返回给前端。前端把 token 存在 localStorage 或 pinia/vuex 中之后每次请求在请求头里加上 Authorization: Bearer 前缀。后端写一个拦截器或过滤器在进入 Controller 之前解析请求头里的 token。解析成功就把用户信息放入 ThreadLocal 或请求上下文后续的业务逻辑随时能拿到当前登录用户解析失败直接返回 401前端收到后用路由守卫跳转登录页。这里最容易被忽略的点有两个一是拦截器要正确排除登录、注册、首页列表等公开接口否则会一直报未登录二是 token 过期时间的设置一般设为 2 小时过期后前端要能收到明确的提示而不是报一个看不懂的 500 错误。5.3 提问与回答的接口设计提问接口采用 POST /api/question参数是标题、正文、分类ID。后端创建记录时从登录上下文里取出 user_id 作为提问人。校验标题长度和正文是否为空是基本操作容易忽略的是对内容中的敏感词做简单过滤或者至少做 HTML 标签的过滤。回答接口的设计同样要考虑业务边界回答者能否对自己提出的问题作答严格来说可以但从业务规则看为了避免刷采纳最好是提问者不能采纳自己的回答。这个业务规则可以用简单的查询判断来实现回答时把 question 的 user_id 和当前用户 id比较如果相等则给出提示。这样的小细节会让答辩演示时显得考虑周全。5.4 分页、搜索、点赞与收藏的实现分页查询是整个系统最常用的接口。MyBatis Plus 提供分页插件配置一个 PaginationInnerInterceptor 就能用 Page 对象分页。前端传 pageNum 和 pageSize后端返回总记录数、总页数和当前页数据列表。问题列表页需要展示分类名称和提问人昵称这属于典型的跨表信息补充可以选择直接写一个多表关联的 SQL也可以用查询完问题列表后批量查询用户信息的方式后者在小数据量下更简单也能避免复杂 JOIN 的坑。搜索功能推荐先用 MySQL 的模糊查询实现title LIKE CONCAT(%, keyword, %) 或 content LIKE 同样方式。数据量在几千条时性能完全够用不需要引入 Elasticsearch。如果想让答辩有亮点可以提一句“当前基于数据库模糊查询后续数据量增大时可以平滑迁移到全文搜索引擎”这比实际引入一套搜索引擎更划算。点赞和收藏接口要注意幂等性。点赞接口先查点赞记录表是否存在数据存在则提示“请勿重复点赞”不存在则插入记录并让 question 表的 like_count 1。为了性能更推荐让前端在已经点赞状态下禁用按钮后端也保留幂等判断双保险。取消点赞则相反删除记录并 -1。收藏功能逻辑完全一致不用重复造轮子。6. 前端页面与前后端联调别让问题卡在浏览器里6.1 页面清单与路由结构前端页面按照角色拆分大体可以规划成三类页面游客和登录用户都能看的问题浏览页、问题详情页登录用户专属的提问页、个人中心页、消息通知页管理员的用户管理、分类管理、数据统计页。路由设计上采用前端路由守卫控制访问权限。Vue Router 提供了 beforeEach 钩子在每次路由跳转前判断如果访问需要登录的页面且本地没有 token就跳转到登录页如果访问管理员页面但当前用户角色不是管理员就跳转到首页。这种“守门”逻辑写在前端是基础写在后端拦截器中更安全两边都要有前端管体验后端管安全。页面清单可以按表格方式梳理模块页面核心内容用户模块登录页 / 注册页登录表单、注册表单、身份选择问题模块问题列表页分类筛选、热度/最新/未解决 Tab 切换、分页问题模块问题详情页问题内容、回答列表、采纳标记、点赞、收藏提问模块发布问题页标题输入、富文本正文、分类下拉选择个人中心个人主页我提的问题、我的回答、我的收藏、消息通知管理模块后台首页数据统计图表、待处理问题列表管理模块用户与分类管理表格 新增/编辑/删除6.2 Axios封装、Token携带与跨域处理前端所有请求建议统一封装到一个 request.js 文件中。主要做三件事创建 axios 实例并设置 baseURL请求拦截器中从 localStorage 取出 token放入请求头 Authorization 字段响应拦截器中统一处理 codecode 为 200 时返回 datacode 为 401 时清除 token 并跳转登录页。跨域问题在前后端分离开发中几乎必现。前端开发服务器默认是 localhost:5173后端接口是 localhost:8080端口不同就构成跨域。解决方案有两种一种是在后端的 WebMvcConfigurer 里配置跨域映射允许指定来源和方法另一种是利用 Vite 的 proxy 代理配置把前端请求转发到后端地址。两种方案都有效我推荐用 Vite 代理因为生产部署时前端页面本来就要通过 Nginx 代理到后端开发环境和生产环境的处理方式保持一致减少环境差异带来的问题。6.3 富文本编辑器与联调翻车现场发布问题时正文需要一个富文本编辑器。可选方案很多常见的是 wangEditor 或 TinyMCE 等开源组件。选编辑器时注意两点一是组件要支持图片上传接口定制点击工具栏图片按钮后把图片上传到后端接口返回 URL再插入编辑区域二是编辑器输出的 HTML 要能回显详情页需要用 v-html 渲染。联调阶段最常见的翻车现场我总结有这三个一是前端传参格式和后端实体字段名不一致比如前端用了驼峰命名后端实体转了驼峰MyBatis Plus 默认开启驼峰映射就没问题但如果全局配置不一致就会导致字段全部为 null二是日期格式后端返回的时间是时间戳或特定格式字符串前端如果不做格式化页面上会显示一串数字或者 UTC 时间解决办法是在后端统一配置 Jackson 的日期格式化或者在实体类的日期字段上使用 JsonFormat 注解三是登录接口明明返回了 token但后续请求仍报未登录排查思路是打开浏览器控制台的网络面板确认请求头 Authorization 有没有正确带过去。7. 论文文档与答辩演示让评委快速看懂你的系统7.1 论文结构从绪论到测试一个不少论文的整体结构按学校模板要求来一般包含摘要、绪论、相关技术介绍、需求分析、系统设计、系统实现、系统测试、总结展望、参考文献。这里最需要注意的是需求分析和系统设计不能“贴规格书”要围绕你的实际页面和实际业务逻辑写。需求分析章节写清楚三个角色的用例配用例图然后对每个核心需求做描述。系统设计章节先写体系结构设计说明前后端分离下前端、后端、数据库的交互流程再画系统功能结构图、数据库ER图、核心表结构。系统实现章节按模块展开每个模块放关键代码片段和截图重点描述实现思路比如“登录模块通过JWT实现无状态认证用户登录成功后返回token前端将其存储并在请求头中携带”。系统测试章节要有测试用例表测试编号、测试项、测试步骤、预期结果、实际结果。很多人忽略这个部分但答辩时评委翻论文往往最先看的就是测试用例是否真实。一个可行的做法是整理一份 20 到 30 条测试用例覆盖登录、提问、回答、搜索、点赞、收藏、管理员管理等功能并附上“测试通过”的结论。7.2 图表规范用例图、ER图、时序图怎么画论文中图表数量和质量直接影响印象分。最少要有以下五类图系统功能结构图、用户用例图、数据库ER图、登录时序图、系统架构图。画图工具不用纠结用 Word 自带的图形工具或在线画图工具都能出结果关键是层次清晰、线条整齐、标注规范。用例图画三个角色各自的用例学生有注册、登录、提问、回答、点赞、收藏教师有答疑、采纳、查看统计管理员有用户管理和分类管理。ER图以表格形式展现实体关系注意标注主键、外键和数量关系。时序图重点画登录流程和提问流程展示前后端交互时的请求顺序。这些图不要到写论文时才临时补建议在开发过程中边画边整理因为开发的时候思路最清楚。7.3 答辩演示的关键操作顺序答辩时的现场演示顺序设计得好评委就能快速理解系统。我的建议顺序是先展示系统首页介绍总体功能演示用户注册登录强调 JWT 无状态认证顺带展示个人信息页演示学生发布问题的完整流程输入标题、选择分类、写正文、提交切换到另一个账号教师身份回答刚才的问题演示回答功能回到学生账号查看消息通知、采纳最佳答案展示“已解答”状态的变化演示搜索功能和分类筛选展示管理员端的数据统计和管理操作。现场演示最容易出问题的环节有两个网络环境和测试账号。一定要提前把本地项目启动好浏览器页面刷新干净几个账号的密码写在便利贴上避免当场临时注册。还要准备一份应急方案如果前端页面加载慢可以先展示论文中的截图和核心代码不要干等页面响应。8. 踩坑复盘几个最影响毕业进度的隐藏雷区8.1 时间字段在JSON序列化里的时区问题有段时间我接到一个学生的求助说问题列表接口返回的 createTime 总比数据库里少了 8 个小时。排查到最后原因是服务器时间和数据库时区配置不一致后端 Jackson 序列化时把数据库的本地时间按 UTC 时区处理了。解决办法也简单在 application.yml 里配置 spring.jackson.time-zoneGMT8数据库连接 URL 上加上 serverTimezoneAsia/Shanghai。这类问题看起来细但卡住时很耽误进度建议一开始就配置好。8.2 外键约束与N1查询的取舍数据库表设计时是否使用物理外键我建议不用。原因有两点物理外键会导致删除问题、删除用户时产生级联限制删除分类时要先处理该分类下的所有问题不然数据库直接报错从性能角度高并发场景下数据库外键校验本身也是额外开销。毕设系统在逻辑上补充好业务约束即可比如删除分类前先检查该分类下是否存在问题。多表关联时还有一个常见问题查询问题列表后还要逐条查用户昵称导致 N1 条 SQL。解决办法就是前面提到的先查列表拿到所有 user_id 集合再一次性批量查询用户信息最后在内存中组装返回结果。8.3 XSS防护富文本内容不能直接渲染前端用 v-html 渲染富文本内容后端如果不做任何处理确实存在跨站脚本攻击风险用户可以在回答内容中写入一段脚本在他人浏览器中执行。毕设阶段至少要做到两层防护后端存入数据库前对内容进行过滤使用 HTML 过滤器工具类去除 script 标签和危险的 on* 事件属性前端展示时再对内容做一次转义或过滤。答辩时主动提到 XSS 防护是明显的高分回答点。8.4 前端路由刷新404与部署细节如果使用 Vue Router 的 history 模式部署到服务器后直接访问某个子路由比如访问 /question/12 刷新页面会报 404。原因是 Nginx 默认找不到对应的物理文件。解决方法是在 Nginx 配置中添加 try_files $uri $uri/ /index.html; 这样的配置让所有路由请求都回退到 index.html 入口。很多学生开发环境没问题部署到服务器就白屏基本都是这个原因。另外部署时的静态资源路径Vite 打包的默认引用路径是绝对路径如果部署在子路径下需要在 vite.config.js 中设置 base 参数。这次整理的完整链路基本可以覆盖从选题、需求、开发到答辩的全过程。如果你准备选这个题目我的最大建议是不要追求功能大而全把提问、回答、采纳、搜索、通知这条主链路做扎实把表结构设计理由和关键接口实现逻辑讲清楚就已经是水平线以上的作品了。过程中遇到报错很正常用控制台报错信息配合搜索引擎逐行排查多数问题都能在半小时内解决。真正需要花时间的反而是把业务规则想清楚比如采纳逻辑、点赞幂等、权限边界这些想明白了代码只是表达问题的手段。