课程答疑系统听起来简单，真做起来全是坑
说实话，凡是在 Java Web 课程设计里做过答疑系统的人，刚开始都把它当“小项目”看——不就一个提问、一个回答、一个用户登录嘛。真正动手之后才发现，光是把提问、回答、评论、通知、权限这几件事串起来，就足够把一个半吊子全栈折腾到怀疑人生。
这套 SpringBoot2 + Vue3 + MyBatis-Plus + MySQL8.0 的课程答疑系统源码，正好卡在“课程设计复杂度”和“真实企业技术栈”之间。它没有微服务那些让人头晕的概念，也没有 JSP 那种十年前的老古董写法，而是用了前后端分离的主流套路：后端 SpringBoot2 + MyBatis-Plus，前端 Vue3 + Element Plus（或类似组件库），数据库 MySQL8.0。如果你是正在做 Java Web 毕业设计、课程设计，或者想从单体项目开始练全栈能力，这套代码的阅读价值非常高。
这篇文章不是把源码贴出来给你抄，而是带你把“答疑系统”这个题目从头到尾拆一遍：为什么要这么设计、核心功能怎么落地的、环境怎么搭、哪些地方最容易翻车。尽量用我实际踩过的坑来换你少走弯路。
1. 先想清楚：一个好用的课程答疑系统到底要解决什么问题
1.1 从需求出发的功能模块拆解
很多人的课程设计任务书写得天花乱坠，什么“智能化问答推送”“多维度学习行为分析”，但落到实际系统里，最刚需的功能翻来覆去就那么几个：用户注册登录、问题发布、问题回答、评论互动、通知提醒、个人中心、后台管理。
我见过不少答辩现场，学生把 PPT 吹得很大，结果演示的时候连“老师能不能删除学生提问”这种基础权限都做不出来。所以做这个系统之前，第一件事不是敲代码，而是把角色和权限模型画清楚。
这套答疑系统典型的角色是三种：学生、老师（助教）、管理员。学生负责提问和回答问题（可以允许学生之间互答），老师负责解答和审核问题，管理员管用户、问题分类和系统公告。对应到权限设计上，就是普通用户能干嘛、老师多了哪些能力、管理员又有哪些独有入口。
这里有一个特别容易忽略的点：问题状态机。问题不是只有“已发布”和“未发布”两种状态。合理的设计至少要有：待审核（可选）、待回答、已回答、已关闭、已删除。老师回答之后问题自动变成已回答；超过一定时间没人回答，可以允许学生自己关闭或者系统标记为悬而未决。这套源码里如果你的状态字段只设计成 int 型，建议至少预留三四个状态位，不然后面加需求会很痛苦。
1.2 为什么选 SpringBoot2 + Vue3 + MyBatis-Plus 这套组合
先说结论：这套组合在 2024、2025 年依然是 Java 后端课程设计和中小型真实项目里很稳的选型。
SpringBoot2 看起来比 SpringBoot3 旧了一点，但它生态最成熟。网上随便搜一个问题，几乎都有对应的解决方案；大部分公司的老系统也还跑在 SpringBoot2 上，答辩的时候面试官问起来，你不会因为“太新”而卡壳。Vue3 则是现在前端的主流，组合式 API 写起来比 Vue2 的 Options API 更接近真实业务代码，而且新项目上手 Vue3 基本是默认选项。
MyBatis-Plus 最香的地方就是少写 SQL。单表 CRUD 你几乎不用写 mapper XML，QueryWrapper 和 LambdaQueryWrapper 直接捞数据。我的实测感受是，答疑系统里 80% 的数据库操作都是单表查询，剩下的 20% 才是多表关联，而这个 20% 恰好能锻炼你手写 SQL 的能力。因此它不是“玩具框架”，而是能起到教学过渡作用的实用工具。
MySQL8.0 则是当前生产环境的主流版本，默认字符集 utf8mb4，对中文、表情符号都很友好。课程答疑系统里用户内容里出现 emoji 的概率不低，你要是用了 MySQL5.7 或者更老的版本，字符集配置没弄对，表情符号入库直接报错。这一点后面会单独讲。
1.3 用 MySQL8.0 要注意的版本特性与踩坑预判
MySQL8.0 相比 5.7 的变化很隐蔽，但对新手极不友好。我第一次把 5.7 的建表 SQL 丢到 8.0 上跑，直接报错Expression #1 of ORDER BY clause is not in GROUP BY clause...。原因就是 8.0 的 sql_mode 默认开启了ONLY_FULL_GROUP_BY，而很多 5.7 时代能跑通的 SQL 在 8.0 上直接废掉。
解决办法有两个：要么改写 SQL，让 select 的非聚合列都出现在 group by 中；要么在数据库配置里关掉 ONLY_FULL_GROUP_BY。我的建议是尽量改 SQL，因为考试和面试的时候，面试官可不会允许你关 sql_mode。
另外 MySQL8.0 默认认证插件是caching_sha2_password。如果你用老版本的 Navicat 或者驱动连不上，大概率是这个原因。我之前就用 5.1.x 的 mysql-connector-java 去连 8.0，报错Public Key Retrieval is not allowed，当时真的愣了半天，后来把驱动换成mysql-connector-j8.0.x 才解决。
2. 源码结构盘点：带你快速摸清前后端工程边界
2.1 后端目录结构与包设计逻辑
拿到源码之后，第一步不是急着跑起来，而是把后端的目录结构看一遍。一个合格的后端项目，包结构本身就能说明设计思想。
这套答疑系统的后端大体上遵循常见的分层结构：
com.example.qa ├── config // 配置类：跨域、MyBatis-Plus分页插件、拦截器 ├── controller // 接口层：接收前端请求、返回统一结果 ├── service // 业务层：核心逻辑都在这里 │ └── impl ├── mapper // 数据访问层：继承BaseMapper ├── entity // 数据库实体类 ├── dto // 前端交互对象：入参DTO、出参VO ├── common // 公共类：统一返回结果、异常处理、常量 └── utils // 工具类：JWT、日期、字符串工具有人可能会问：为什么 entity 和 dto 要分开？直接用实体类接收前端的参数不行吗？理论上是行得通的，但实际项目里前端传入的数据往往比数据库字段多（比如确认密码、验证码），或者我们希望返回给前端的数据比数据库字段少（比如隐藏用户密码字段）。如果直接用实体类，字段暴露风险特别大。
我建议你在读源码的时候，重点看 controller 层是不是够“薄”。如果 controller 里堆了大量业务代码，那说明 service 层拆分不合理。一个标准的 controller 方法应该只是：接收参数、校验参数、调用 service、返回结果。参数校验可以用@Validated注解去完成，而不是手动 if-else 写一堆判断。
2.2 前端 Vue3 项目结构与页面路由安排
前端工程打开后，先看 src 目录下的几个关键目录。Vue3 项目的复杂度往往藏在 views、router、store、api 这四个地方。
src ├── api // 封装axios请求 ├── assets // 静态资源 ├── components // 公共组件 ├── router // 路由配置 ├── store // 全局状态管理 ├── views // 页面组件 │ ├── login │ ├── student │ ├── teacher │ └── admin └── utils // 前端工具函数实际答疑系统里前端路由要解决两个核心问题：一是登录鉴权（没登录不能进页面），二是角色权限（学生不能访问管理员页面）。源码里通常会在 router 的全局前置守卫里做这两个判断。
我建议你重点看 api 目录里的封装方式。不要在每个页面里直接写 axios.get，而是把请求集中封装在一个 js 文件里，统一处理 token（通过拦截器设置请求头）、统一处理错误码（比如 401 跳登录页）。这是我见过很多课程设计和真实项目中最大的差距所在。
Vue3 项目里很容易忽略一件事：环境变量。Vite 的项目里，开发环境接口地址写死http://localhost:8080是没有问题的，但后面部署上线如果你还写死，前端页面就得重新打包。建议一开始就用环境变量区分开发环境和生产环境。
2.3 数据库表设计思路（以问答、讨论为核心）
答疑系统的核心表实际不超过十张，但是表之间的关系要想清楚。
用户表、问题表、回答表、评论表、通知表、分类表、附件表这些是基础。以我个人经验，表设计的时候有四个关键点：
第一，用户表不要存明文密码。哪怕这是课程设计，也用 BCrypt 加密一下，不然答辩的时候老师一眼看出密码是明文，印象分会掉一大半。Spring Security 自带 BCryptPasswordEncoder，SpringBoot2 里引入很方便。
第二，问题表需要冗余“回答数量”和“浏览数量”这类统计字段。有同学用 count(*) 实时统计，数据量小的时候没问题，但以后回答多了，每打开一次问题页面就要做两次 count 查询，性能会越来越差。冗余字段的代价是更新时需要额外维护，但答疑系统答一次题只更新一条记录，这点代价完全值得。
第三，评论表通常设计成可以无限层级的。课程答疑系统里，评论一般分为“问题的评论”和“回答的评论”。如果要支持多级回复，表设计上建议使用parent_id字段，0 表示顶级评论，非 0 表示回复某条评论。这样做前端的“展开/收起回复”功能会容易很多。
第四，附件表不要跟问题表耦合太紧。你设想一个场景：用户提问时可以上传图片，回答时也可以上传文件。如果附件表只放question_id，那回答里的附件就存不进去了。更合适的做法是让附件表记录biz_type（关联类型：问题或回答）和biz_id（关联记录的主键）。
3. 核心功能实现拆解：从登录鉴权到提问回答的完整链路
3.1 登录鉴权与 JWT 方案落地要点
课程答疑系统的登录鉴权方案，主流选择是 JWT（JSON Web Token）。为什么不用 Session？因为前后端分离以后，后端接口要同时服务 Web 端和未来的移动端，Session 在跨域和集群环境下不太方便，JWT 无状态，天然适合接口鉴权。
JWT 落地时有几个容易搞错的地方：
签发 token 时，payload 里不要放敏感信息，一般只放userId和username。权限信息可以不放进 token，每次登录后从数据库查询用户角色并放进内存即可，或者用 Redis 缓存起来。JWT 的过期时间也别设太长，我见过有人直接设 7 天，客户端改了密码之后旧 token 依然有效，这其实是一个安全漏洞。
实际项目里我一般这么做：
// 生成JWT String token = Jwts.builder() .setSubject(String.valueOf(user.getId())) .claim("username", user.getUsername()) .claim("role", user.getRole()) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() + 2 * 60 * 60 * 1000)) // 2小时过期 .signWith(SignatureAlgorithm.HS256, secretKey) .compact();后端的拦截器对需要登录的接口做解析校验。学生、老师、管理员的接口权限不同，可以用自定义注解@RequireRole加在 controller 方法上，然后在拦截器里统一判断。这是我比较推荐的方式，比在业务代码里手动判断要优雅得多。
前端 Vue3 这边，拿到 token 之后放在哪？有人喜欢放 localStorage，有人放 sessionStorage。放 sessionStorage 的缺点是关闭浏览器就失效了；放 localStorage 的缺点是存在 XSS 风险，但课程设计阶段通常可接受。如果你想把项目做得再专业一点，可以考虑把 token 放进 httpOnly Cookie，但这样会引入 CSRF 防御的问题，复杂度会提升一大截。我的建议是：课程设计用 localStorage + 请求拦截器，生产项目再考虑更严格方案。
3.2 提问、回答、评论的接口设计细节
在答疑系统里，最核心的一组接口是围绕问题的 CRUD 以及关联操作。
提问的时候，前端提交表单包含标题、内容、分类 ID，有时还有附件列表。这里最容易出的问题是没有做“附件与问题”的事务关联。用户上传了图片，但点提交的时候网络中断，图片已经传到服务器了，数据却没有入库，于是服务器上多了一堆垃圾文件。好的做法有两个方向：方案一，先提交问题数据拿到主键 id，再上传附件关联这个 id；方案二，用定时任务定期清理“孤立附件”（附件表中有记录但对应的问题不存在的文件）。
回答功能的核心不是插入一条回答记录，而是“插入回答 + 更新问题状态 + 生成通知”这三个操作要保证一致性。你想想，学生提交答案后，如果问题状态没从“待回答”变成“已回答”，那学生再刷新页面，看到问题还是未解决，这种体验是非常差劲的。这里用事务注解@Transactional就能搞定，MyBatis-Plus 跟 Spring 事务的配合是很顺畅的。
评论功能相对简单，但分页查询时有个常见问题：你要先查“顶级评论”的列表，然后再查询每条顶级评论下的“子评论”。如果逐条查询子评论，就会出现经典的 N+1 问题。虽然课程设计的数据量下性能看不出差异，但如果你希望代码更专业，可以先把问题 ID 列表查出来，然后用一次 IN 查询把所有子评论捞出来，再在内存里组装。这也是面试官很喜欢问的一个点。
3.3 通知模块与消息推送的实现思路
答疑系统的通知模块，决定了系统的“活跃度”。如果你做了回答功能但没有通知功能，学生提问后永远不知道自己提的问题被回答了，必须手动刷新页面去看，这跟二手市场买东西不推送消息差不多。
通知的触发场景主要有这几种：有人回答了我的问题、有人评论了我的回答、我的问题被管理员关闭或删除、系统发布了新公告。
通知模块最简单的设计方案是“库表 + 轮询”。通知表设计成：
CREATE TABLE sys_notification ( id BIGINT PRIMARY KEY COMMENT '主键', user_id BIGINT NOT NULL COMMENT '接收通知的用户ID', content VARCHAR(500) NOT NULL COMMENT '通知内容', type TINYINT NOT NULL COMMENT '通知类型：1回答 2评论 3系统', related_id BIGINT COMMENT '关联的业务ID', is_read TINYINT DEFAULT 0 COMMENT '0未读 1已读', create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间' );前端在页面顶部展示未读数量，每隔 30 秒或 60 秒调用一次“获取未读通知数”的接口。这个方案实现成本低、容易理解，适合课程设计。如果要上生产，可以用 WebSocket 或者 SSE（Server-Sent Events）做实时推送，但系统的复杂度会明显上升。我的建议是先把轮询方案做出来，能跑通了再考虑升级，别一上来就搞 WebSocket，很容易在鉴权、心跳、断线重连这些细节里迷失。
4. 环境搭建与部署实战：从零跑通这套系统
4.1 MySQL8.0 的安装与初始化（含 Windows/Linux 两条路径）
很多同学拿到源码之后，第一关不是代码跑不起来，而是 MySQL8.0 装不上或者装完连不上。
Windows 上装 MySQL8.0，我建议直接用官方安装包（mysql-installer-community），一路 Next 就能装完。但要注意两个细节：安装过程中会让你选择认证插件，尽量选Use Strong Password Encryption，默认的caching_sha2_password就行；安装完成后去服务管理里把 MySQL80 服务启动起来。
如果安装时忘了配置 root 密码，别慌，用管理员权限打开命令行，停服务、以skip-grant-tables模式启动、改密码、刷新权限，一套操作下来十分钟搞定。
Linux 上安装，以 CentOS 系为例，先下载对应的 rpm 包或用 yum 仓库安装：
# 安装MySQL8.0（示例，不同版本号按需调整） wget https://dev.mysql.com/get/mysql80-community-release-el7-3.noarch.rpm rpm -ivh mysql80-community-release-el7-3.noarch.rpm yum install -y mysql-server systemctl start mysqld grep 'temporary password' /var/log/mysqld.log临时密码在日志里，登录之后先改密码。如果提示密码强度不够，可以用SHOW VARIABLES LIKE 'validate_password%';查看相关规则，先设置一个复杂密码，后面再按需调整。
数据库建好后，最重要的一步是修改权限和字符集。课程答疑系统要支持中文和 emoji，建库语句建议指定 utf8mb4：
CREATE DATABASE qa_system DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;4.2 后端 SpringBoot2 启动配置与常见启动报错排查
后端跑起来之前，先把application.yml（或 application.properties）里的数据源配置改好：
server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/qa_system?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false username: root password: yourpassword driver-class-name: com.mysql.cj.jdbc.Driver mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0最常见的启动报错是Access denied for user 'root'@'localhost' (using password: YES)，这说明数据库密码不对或者权限没开。还有一个高频错误是Unknown database 'qa_system'，就是你还没建库就直接启动了，先执行上面那条 CREATE DATABASE 语句。
如果你启动之后发现接口报错Public Key Retrieval is not allowed，在 JDBC URL 里加上allowPublicKeyRetrieval=true即可。这个参数我几乎每次用 MySQL8.0 都会碰到，建议顺手写上。
另外要注意 MyBatis-Plus 的分页插件配置。MyBatis-Plus 3.x 的分页插件需要手动配置MybatisPlusInterceptor，不配置的话分页查询会查全表，然后内存分页，数据量小的时候没感觉，数据一多就明显变慢。
4.3 前端 Vue3 的 Node 环境与 npm 启动流程
Vue3 项目跑起来之前，装 Node.js LTS 版本就行。Vue3 官方要求 Node 14+，但我建议直接用 Node 18 或 20，避免一些老版本 npm 依赖解析失败的问题。
进入前端项目目录后：
npm install npm run dev如果你发现 npm install 非常慢，大概率是网络问题，可以换成淘宝镜像源：
npm config set registry https://registry.npmmirror.com这里我踩过一个大坑：Vue3 + Vite 项目默认监听localhost，如果用手机或者局域网 IP 访问，会显示拒绝连接。需要在 Vite 配置里指定 host：
// vite.config.js server: { host: '0.0.0.0', port: 3000, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }前端启动后，如果页面报跨域错误，优先检查 Vite 的 proxy 是不是配置正确。开发时用 proxy 是为了绕过浏览器的跨域限制，后端也可以配合做跨域配置，但最终还是推荐前端 proxy + 后端不需要额外跨域配置的组合，因为线上部署时前端和后端通常会被 Nginx 反向代理到同一个域下，跨域问题自然就消失了。
5. 避坑手册：我在这套系统上踩过的真实问题
5.1 MyBatis-Plus 的批量插入坑与优化
MyBatis-Plus 提供了saveBatch方法，很多人以为它是生成一条INSERT INTO ... VALUES (...),(...)的批量 SQL，实际上在默认实现里，它是通过循环调用单条插入完成的。数据量小的时候没问题，数据量一大，几百上千条就会比较慢。
解决方案有两个方向，一是用自定义 SQL 写一条真正的批量插入：
<insert id="insertBatch"> INSERT INTO qa_answer (question_id, user_id, content, create_time) VALUES <foreach collection="list" item="item" separator=","> (#{item.questionId}, #{item.userId}, #{item.content}, NOW()) </foreach> </insert>二是引入ExecutorType.BATCH的 SqlSessionTemplate。但这通常需要额外配置，对课程设计来说，自定义 SQL 方式足矣。
另外使用saveBatch时注意，如果实体类设置了逻辑删除字段，批量插入时这个字段的默认值可能不会自动填充，导致查出来的数据被逻辑删除过滤掉。这个坑很隐蔽，你可能只看到“插入成功但查不到数据”，甚至不会去想是逻辑删除字段的问题。
5.2 Vue3 组件通信与响应式丢失的处理
Vue3 里ref和reactive的区别，很多人背得滚瓜烂熟，但实际写代码时还是会遇到响应式丢失的问题。
最典型的场景是从接口拿到数据后直接赋值给 reactive 对象：
const form = reactive({ title: '', content: '' }) // 错误做法：直接替换整个对象会丢失响应式 form = res.data // 正确做法：逐字段赋值，或者用 Object.assign Object.assign(form, res.data)另一个常见问题是 props 直接解构后失去了响应性。Vue3 的setup(props)里，如果一个子组件接收了一个question对象，然后const { title } = props，此时title就不是响应式的了。你这个页面如果需要根据 props 的新值去重新请求数据，一定要用watch监听props.question的变化，而不是直接解构。
还有组件通信的选择问题。答疑系统里，一个页面内的父组件与子组件通信，优先用defineProps和defineEmits。如果要跨页面共享用户信息，用 Pinia（Vue3 官方推荐的状态管理库）而不是 Vuex。当前这套源码如果用的还是 Vuex，你可以考虑迁到 Pinia，迁移成本很低，但写起来舒服很多。
5.3 跨域、文件上传、雪花ID等容易翻车的小细节
跨域的坑，上面提过了，开发环境优先用 Vite proxy。如果后端自己也配了@CrossOrigin或者全局跨域CorsFilter，前端又用了 proxy，等于做了两遍跨域处理。有些场景下会产生“两次 OPTIONS 预检请求”的冗余。所以我的习惯是：要么纯前端 proxy，要么纯后端 CORS，不要两边同时开。
文件上传的坑主要在大小限制。SpringBoot2 默认单文件最大 1MB，如果学生想上传课件或者截图，超过 1MB 后端直接报MaxUploadSizeExceededException。需要在配置里调整：
spring: servlet: multipart: max-file-size: 20MB max-request-size: 50MB同时，前端也要在 axios 里设置timeout，不然大文件上传时请求时间过长，前端会先超时断开。
雪花 ID 的坑跟文件上传没啥关系，但属于 MyBatis-Plus 体系下容易踩的。MyBatis-Plus 默认主键策略是 ASSIGN_ID，也就是雪花算法生成 19 位的长整型 ID。这个 ID 传到前端之后，JavaScript 的 Number 类型精度不够，会出现“后几位变成 0”的问题。经典案例是你在前端点击编辑，提交后后端拿到的 ID 变成了另一个数，然后接口报数据不存在。
解法很简单，后端返回给前端时把 Long 型 ID 转成 String：
@JsonSerialize(using = ToStringSerializer.class) private Long id;或者全局配置 Jackson 把 Long 转 String。这一点很多新手根本意识不到，但它确实是个高频问题。
6. 从课程设计到生产部署：这套源码还可以怎么扩展
6.1 把单体改成微服务需要动哪些地方
有些同学拿了这套源码，想在毕业设计里加一句“采用微服务架构”来提升复杂度。我的建议是：如果你想清楚了再做，不要为了写而写。
答疑系统本身业务量不大，强行拆微服务只会增加大量与业务无关的复杂度。但如果一定要拆，优先考虑把“用户服务”和“问答服务”拆开，因为两者的业务边界相对清晰。原本的 SpringBoot2 单体工程里，用户相关的 controller、service、mapper 整体搬到一个新工程，问答相关的搬到另一个工程。
拆分之后你会立刻遇到两个问题：一是如何处理服务间调用，推荐用 OpenFeign；二是用户信息和权限校验怎么共享，常见方案是网关层统一鉴权、解析 JWT，然后在请求头里向下游传递 userId。加上 Nacos 做注册中心和配置中心，整个项目的复杂度确实上去了，但你要想清楚，答辩老师问你“拆完之后解决了什么痛点”，如果你答不上来，反而减分。
6.2 缓存、搜索、性能优化三个方向的实战建议
答疑系统跑一段时间后，问题列表会变慢，这是很自然的。优化顺序我建议是：先加索引，再加缓存，最后才上搜索引擎。
加索引是最容易见效的。问题表按create_time创建时间倒序查询，如果数据量大了，create_time字段上要有索引；按分类标签筛选时，category_id字段也要有索引。加了索引之后你会发现，大多数慢查询立刻就能解决。
缓存主要缓存两类数据：一类是热点数据，比如热门问题和公告；另一类是高频统计，比如问题总数、未读通知数。实现技术是 Redis + Spring Cache。但你也要注意，加了缓存之后会引入缓存一致性、缓存穿透、缓存击穿这些问题。答疑系统场景下，内容以读为主，写操作不算频繁，只要在写入时主动删除缓存即可。
搜索这块，如果只是按标题模糊查，MySQL 的LIKE '%keyword%'在数据量小的时候能凑合用。但搜索场景复杂了，比如支持全文检索、按相关度排序、搜索高亮，MySQL 就扛不太住了。这时候才值得引入 Elasticsearch。之前的热搜词里有“elasticsearch springboot2”，说明很多人也在关注这个方向。我的建议是，课程设计阶段先用 MySQL 的 LIKE 或 FULLTEXT 索引做简单搜索，把业务跑通；如果要在简历里体现亮点，可以单独抽一个微服务模块来实现搜索功能，让项目的主线保持简单、清晰。
最后说一句部署。前后端分离项目最省成本的部署方式是：前端npm run build构建出 dist 静态文件，后端打包成 jar 包，Nginx 同时托管前端静态资源并反向代理/api到本机的 8080 端口。这是最接近真实生产环境、又不需要额外购买多台服务器的方案。如果你连 Nginx 都没听过，花一天时间把它跑通，它带给你的收益远超那些花哨的技术名词。
这套答疑系统源码说到底是一个“麻雀虽小、五脏俱全”的全栈练习样本。我从第一次跑通它到现在，踩过的坑基本都在上面了。如果你正在用它做课程设计或者学习参考，我建议你花一个晚上把目录结构和数据库表关系画清楚，再花一天把所有接口的调用链捋顺，最后再亲手写两个新功能，比如“问题规范检测”或者“常见问题置顶”。这个过程比单纯跑起来看效果要重要得多，也是把别人的代码真正变成自己能力最快的方式。
