企业官网建设流程全解析

前两年给一家教育公司搭过一套课程答疑系统，用的就是SpringBoot+Vue+MyBatis+MySQL这套组合，那时候踩了不少坑，也沉淀了不少经验。今天把这个项目的完整实现思路、数据模型、核心代码细节和部署注意点整理出来，希望对正在做同类系统或者打算用这套技术栈做毕业设计、公司内部项目的朋友有点帮助。

这个系统说白了就是解决一个很实际的问题：学生在学习课程过程中有疑问，需要一个统一的地方提问，老师能集中回答，管理员能管理课程和内容审核。跟微信群里面你一句我一句完全不一样，答疑系统要有结构化的问题列表、分类、检索、指派、回复、采纳、统计这些机制。文中涉及SpringBoot的工程组织方式、MyBatis的XML写法和缓存处理、MySQL的表设计和查询优化、Vue前端的路由与组件通信，以及M3U8视频点播、MinIO对象存储接入这些周边能力。适合有Java基础和前端基础、想完整跑通一个前后端分离企业级项目的开发者参考。

1. 画清楚业务边界：答疑系统的核心模块与用户角色

1.1 三类用户角色与权限设计

先别急着写代码，业务边界理不清楚，代码写再多都是白搭。企业级课程答疑系统最典型的用户角色是三类：学生、教师（讲师）、管理员。

学生是提问方，核心诉求是快速把问题描述清楚、能有人回复、回复能解决问题。所以学生端需要：发布问题、补充问题描述、查看回复、采纳某个回复、追问。教师是回答方，核心诉求是高效处理问题，所以教师端需要：查看指派给自己的问题、回答问题、引用课程章节内容、打回或标记重复问题。管理员负责整体运营，需要：管理用户（包括禁用账号）、管理课程分类、指派答疑任务、审核内容（过滤广告和敏感词）、查看数据统计。

权限这一块建议做成RBAC（基于角色的访问控制）模型，不要硬编码在业务代码里。我之前看到有人把角色判断直接写在Service里，后面要加个助教角色，代码改到怀疑人生。

1.2 功能模块优先级怎么排

一个完整的企业级答疑系统，功能可以拆成两条线：核心链路和辅助支撑。

核心链路就是“提问 -> 分诊 -> 回答 -> 采纳 -> 归档”。这条链路必须做扎实，它是系统存在的意义。提问要有富文本编辑能力（支持代码块、Markdown）；分诊要支持自动按课程分配、手动指派；回答要有草稿和状态流转（待处理、已处理、已关闭）；采纳要能触发统计和通知。

辅助支撑包括：课程管理、用户管理、消息通知（站内信+邮件）、数据看板、敏感词过滤、操作日志。这些不需要一开始全做，但架构上要留好扩展位。比如消息通知，建议直接用一张message表+MQ异步解耦，别把通知逻辑写在业务Service里。

1.3 业务状态机设计

答疑主题（question）的状态流转是系统里最容易写乱的地方。我推荐设计五个状态，对应数据库里的status字段：

• PENDING：待处理，学生提交后默认状态
• ASSIGNED：已指派，教师接单但未回答
• ANSWERED：已回答，至少有一条有效回复
• CLOSED：已关闭，提问者采纳了某条回复或主动关闭
• REOPENED：重新开启，学生不满意回答重新发起

这个状态机的好处是，管理后台可以按状态维度做队列调度，教师端也可以清晰地看到自己的工作列表。同一个问题有多次回复，但状态是跟着“问题”走的，不是跟着“回复”走的。这一点在设计表结构的时候要特别注意。

2. 技术选型：SpringBoot+Vue+MyBatis+MySQL这套组合为什么能打

2.1 后端框架选型的现实考量

市面上后端框架不少，SSM、Spring Boot、Spring Cloud体系、Go的Gin、Python的FastAPI都有各自的拥趸。但如果是做企业级业务管理系统，SpringBoot依然是目前综合性价比最高的选择。

理由不复杂：第一，生态成熟，Spring家族相关的中间件、文档、人才储备都非常多，招人容易，维护成本相对可控。第二，SpringBoot的自动配置和约定优于配置，可以把大量时间花在业务逻辑而不是框架组装上。第三，Java本身的类型安全和大厂背书，在金融、教育、政企这一类注重稳定性的场景里，决策风险小。

当然，如果项目规模极其庞大、服务拆分要求极高，那可以再引入Spring Cloud Alibaba之类的微服务体系。对于答疑系统这个体量来说，单体应用绰绰有余。我之前见过有人给几千用户的系统硬上微服务，最后排查个问题都要翻半天日志，得不偿失。

2.2 MyBatis还是MyBatis-Plus

这个项目标题写的是MyBatis架构，实际上我在开发过程中用的是MyBatis-Plus做增强，但核心SQL还是MyBatis的XML方式。

MyBatis最大的魅力是SQL可控，复杂的联表查询、动态条件拼接，写在XML里清晰直观，DBAreview起来也比较舒服。而MyBatis-Plus则把单表CRUD、分页、乐观锁这些样板代码消掉了，开发效率提升明显。

我的实践组合是：单表操作直接用MyBatis-Plus的BaseMapper，多表联查、复杂统计用自定义XML。两条腿走路，既保证了效率，又保证了复杂查询的可控性。

2.3 前端Vue与数据库MySQL的定位

前端选择Vue，核心原因有两个：一是Vue的响应式数据模型对后台管理类应用的适配度非常高，表单联动、列表筛选、状态切换这类交互写起来很顺手；二是Vue的生态组件丰富，Element UI/Element Plus、富文本编辑器、Markdown组件、视频播放器都有成熟的封装。

MySQL是这套系统里最不性感但最重要的组件。答疑系统的数据特征非常契合关系型数据库：结构化、强一致、事务性要求高（比如采纳答案要同时更新回复状态和问题状态）。MySQL的InnoDB引擎提供了行级锁和事务，再配合Redis做热点缓存，数据层基本不用担心。

3. 数据库设计：核心表结构与关键SQL细节

3.1 用户、课程与答疑主题三张核心表

数据库设计是整个系统的地基。我这边整理出的核心表大致如下：

用户表（sys_user）

• id：主键
• username：登录名
• password：BCrypt加密后的密码
• real_name：真实姓名
• role：角色（STUDENT/TEACHER/ADMIN）
• course_ids：教师关联的课程ID，多个用逗号分隔，或者用关联表
• status：账号状态（0正常，1禁用）
• create_time：创建时间

这里有一个细节，教师的课程关联不要用逗号分隔存字符串，否则后面统计和按课程指派会很痛苦。正确做法是建一张teacher_course关联表，哪怕是学生选课，也要建student_course表。

课程表（course）

• id、course_name、description、cover_url、status、create_time

答疑主题表（question）

• id
• course_id：关联课程
• student_id：提问学生
• title：问题标题
• content：问题内容（富文本HTML或Markdown）
• status：状态（对应前面说的状态机）
• assignee_id：被指派的教师
• view_count：浏览数
• answer_count：回复数
• accepted_answer_id：被采纳的回复
• create_time、update_time

3.2 回复表、审核表与消息表

答疑回复表（answer）

• id
• question_id：关联答疑主题
• teacher_id：回复教师
• content：回复内容
• is_accepted：是否被采纳
• create_time

内容审核表（audit_log）

• id
• target_type：审核对象类型（QUESTION/ANSWER）
• target_id：对象ID
• audit_status：通过/拒绝
• audit_user：审核人
• audit_remark：审核备注
• create_time

审核不一定要做成独立表，如果业务简单，直接在question和answer表上加audit_status字段也行。但独立表的好处是能留痕，企业级系统过等保或者内部审计的时候，操作日志和审核记录是硬要求。

消息通知表（sys_message）

• id
• user_id：接收人
• message_type：类型（新回复/被采纳/系统通知）
• title、content
• is_read：是否已读
• create_time

3.3 建表SQL的几个坑

第一，所有表都要带create_time和update_time，并且update_time建议ON UPDATE CURRENT_TIMESTAMP自动更新。第二，text字段类型不要用在索引上，如果要按问题标题做模糊搜索，建议先用LIKE '%keyword%'顶着，数据量大了再上Elasticsearch或者MySQL全文索引。第三，外键约束可以直接不用，逻辑外键就足够了。企业级系统为了避免删除时的级联麻烦，普遍不用物理外键，靠应用层保证一致性。

敏感词过滤功能不需要建表，把敏感词库放在配置文件或者一个sys_dict字典表里就够了，每次新增回复的时候走一遍DFA算法检测。

4. 后端落地：SpringBoot工程结构与核心代码实现

4.1 分层结构与Maven多模块

后端工程我建议按Maven多模块组织，至少拆成两个：course-answer-common（公共模块：实体类、工具类、统一返回结果）和course-answer-server（启动模块：Controller、Service、Mapper）。

这种拆分有好处，公共模块可以单独打成jar包，如果以后要写定时任务、消息消费者之类的子服务，直接引用common模块就行了。我在实际项目中还会把Mapper接口和XML文件放在同一个包路径下，这样避免扫描配置出错。

核心依赖版本我用的是SpringBoot 2.7.x，对应Java 8。如果是新项目，直接上SpringBoot 3.x + JDK17也没问题，但要注意MyBatis-Plus和部分中间件的兼容性。开发期间我遇到过SpringBoot版本太高导致的配置项变化，最典型的是SpringBoot 3.x把javax包名改成了jakarta，代码里import的包全要换。

4.2 统一返回结果与全局异常处理

企业级项目不可能每个接口都返回裸数据，必须有统一的响应体。我定义了一个Result类，结构是：

public class Result<T> implements Serializable { private Integer code; private String message; private T data; private Long timestamp; }

code=200表示成功，code=500表示系统异常，code=400表示参数校验失败，code=401表示未登录或token失效。所有接口的返回值一律是Result包装之后的对象。全局异常处理用@RestControllerAdvice统一拦截，业务异常（如问题不存在、无权操作）抛自定义BusinessException，未知异常记录日志后统一返回“系统繁忙”。

这套东西在写代码的时候会感觉多了一些样板活，但到了联调和排查问题阶段，优势非常明显——前后端对接只要对着code和message就能定位问题，不用翻日志去猜返回结构。

4.3 MyBatis核心配置与XML显式SQL

先说配置，MyBatis这边的关键配置项有：

mybatis-plus: mapper-locations: classpath*:mapper/**/*.xml type-aliases-package: com.example.entity configuration: map-underscore-to-camel-case: true 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

map-underscore-to-camel-case必须开启，否则create_time映射不到createTime。log-impl设置为StdOutImpl，开发阶段可以在控制台直接看到SQL语句，排查问题效率极高。逻辑删除配置是MyBatis-Plus的杀手锏，deleted字段不用自己手动set，框架会自动追加条件。

XML里最常用的是动态SQL。举一个按条件查询答疑列表的典型写法：

<select id="selectQuestionPage" resultType="com.example.entity.Question"> SELECT q.id, q.title, q.status, q.answer_count, q.create_time, u.real_name AS studentName, c.course_name AS courseName FROM question q LEFT JOIN sys_user u ON q.student_id = u.id LEFT JOIN course c ON q.course_id = c.id <where> <if test="courseId != null"> AND q.course_id = #{courseId} </if> <if test="status != null"> AND q.status = #{status} </if> <if test="keyword != null and keyword != ''"> AND (q.title LIKE CONCAT('%', #{keyword}, '%') OR q.content LIKE CONCAT('%', #{keyword}, '%')) </if> </where> ORDER BY <choose> <when test="sortField == 'hot'">q.view_count DESC</when> <otherwise>q.create_time DESC</otherwise> </choose> </select>

动态SQL里的where标签会自动处理第一个条件前面的AND，这个机制要记住，别自己写WHERE 1=1那种老掉牙的写法。LIKE查询这里走了全表扫，数据量小没问题，一旦超过几十万条，建议单独做搜索引擎或者改造为前缀匹配。

4.4 一个完整提问接口的实现链路

以“学生发布问题”这个核心场景为例，完整链路是：

1. 前端调用POST /api/question/create，提交courseId、title、content
2. 后端Controller层接收，用@Validated做基础校验
3. Service层先做业务校验（课程是否存在、用户是否是学生）
4. 调用Mapper插入question记录，初始status为PENDING
5. 如果课程设置了默认指派教师，则更新assigneeId
6. 发送消息通知（MQ异步）
7. 返回Result.success(questionId)

这里有个细节：内容安全审核不能丢。我在Service层加了一个ContentSecurityUtil，用DFA算法做敏感词检测，一旦命中就直接返回业务异常，提示用户“内容包含敏感词”。后面如果要接入AI审核，只需要替换这个Util的实现即可。

发布之后，学生端列表页能立即看到问题，教师端的工作台也会出现待办。这部分我用WebSocket做了实时提醒（MQ推送新的待办数量），但WebSocket不是必须的，用轮询也能接受。启动阶段不建议上太复杂的东西，先保证主流程闭环。

5. 前端实现：Vue的组件化开发与交互细节

5.1 前端工程结构和路由设计

前端我是用Vue CLI创建的项目，整体目录结构：

src ├── api │ ├── question.js │ ├── answer.js │ ├── user.js │ └── course.js ├── assets ├── components │ ├── RichEditor.vue │ ├── VideoPlayer.vue │ └── QuestionCard.vue ├── router │ └── index.js ├── store │ └── user.js ├── utils │ └── request.js └── views ├── student │ ├── QuestionList.vue │ ├── QuestionDetail.vue │ └── AskQuestion.vue ├── teacher │ ├── Workbench.vue │ └── AnswerQuestion.vue └── admin ├── UserManage.vue ├── CourseManage.vue └── Dashboard.vue

路由我用了动态路由和路由守卫配合。用户登录之后，后端返回该用户的角色和菜单权限，前端用addRoute动态挂载。这样做的好处是，学生访问教师路由直接404，从入口上就杜绝了越权。路由守卫则负责检查本地是否有token，没有就强制跳转登录页。

5.2 富文本编辑器与Markdown渲染

答疑系统最核心的输入是问题描述。如果只支持纯文本，程序员问问题画个流程图、贴段代码都没办法。所以编辑器这里必须上富文本或Markdown。

我选用的是wangEditor（富文本）加highlight.js（代码高亮）的组合。为什么不选Quill？坦白讲，Quill在vue里的封装确实也成熟，但wangEditor的菜单配置更简单，尤其是插入代码块、图片上传这两个功能，几乎开箱即用。

编辑器里的图片上传是另一个容易踩坑的地方。开发阶段我直接把图片转成Base64塞进content里，结果一条问题带三张图，接口返回体直接几十KB，列表页渲染变慢。后来把所有图片都改成了MinIO对象存储，上传接口返回URL，content里只存图片地址。这一步建议一开始就做，后面再来改造成本翻倍。

5.3 视频答疑场景：M3U8播放与MinIO上传

课程答疑的视频场景主要是回放答疑直播，或者教师上传录播讲解。视频点播这一块的实践经验是：不要用MP4大文件直接在线播放，建议转码成HLS（M3U8切片）再播放。MP4的兼容性虽然好，但文件大、拖动进度条要下载整段，体验很差；M3U8把视频切成一个个小ts分片，支持自适应码率，网页端直接HLS.js播放非常流畅。

前端播放器这块，我用的video.js搭配videojs-contrib-hls插件，几行代码就能播放：

this.player = videojs(this.$refs.videoPlayer, { sources: [{ src: this.videoUrl, type: 'application/x-mpegURL' }] });

videoUrl就是后端返回的M3U8地址，云点播的话一般是鉴权URL，自己用FFmpeg转码的话直接指向MinIO的bucket路径。

MinIO接入SpringBoot其实很简单。引入minio依赖，配置好endpoint、accessKey、secretKey，写一个MinioService封装一下上传和下载的签名URL生成。生成签名URL的好处是bucket不用设成public，文件链接带时效性，安全性高很多。

5.4 列表页的分页与状态筛选

答疑列表页是整个系统交互最频繁的地方。我做了一个组合筛选：状态Tab（全部/待处理/已回复/已关闭）、课程下拉、关键词搜索、排序切换（最新/最热）。每一个条件变化都会触发重新请求接口，后端返回分页结果。

这里前端要注意的是防抖。关键词搜素输入框加了300ms的防抖，不然每敲一个字母就调一次接口，后端压力大，前端也卡。分页组件用的Element Plus的Pagination，页码从1开始，后端分页参数是pageNum和pageSize。

热门问题的排序我做了个轻量逻辑：view_count * 0.6 + answer_count * 1.2，再按这个权重倒序排列。这个公式是我拍脑袋定的，实际运营数据反馈还行。如果要做更科学的推荐，可以考虑引入Caffeine本地缓存，把热榜数据缓存5分钟。

6. 前后端联调、部署与上线运维要点

6.1 跨域问题：前后端分离联调必踩的坑

开发阶段前端跑在8080端口，后端跑在8081端口，接口一调就是跨域。解决方式我在后端加了一个CORS全局配置：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/api/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

生产环境部署的时候，我通常会把Vue打包后的dist目录放到SpringBoot的static目录下，作为单包运行，这样跨域问题直接消失，也更方便部署到一台服务器上。如果非要完全分离部署（前端Nginx，后端Tomcat），那Nginx上要配置反向代理，把/api的请求转发到后端端口。

6.2 MySQL初始化与启动常见问题

数据库这一层，新人最容易翻车的几个问题：

第一，MySQL版本和驱动不匹配。Java 8配合mysql-connector-java 8.0.x没问题，一旦用了MySQL 8+，连接驱动会自动带上SSL协商，测试环境经常报SSL connection error。解决方案是连接串加参数：

jdbc:mysql://localhost:3306/course_answer?useSSL=false&allowPublicKeyRetrieval=true&serverTimezone=Asia/Shanghai&characterEncoding=utf8

第二，数据库初始化文件必须带字符集设置。建议建库的时候直接执行：

CREATE DATABASE course_answer DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

不要用默认latin1，否则中文插入进去直接乱码。

第三，MySQL8默认认证插件是caching_sha2_password，有些老一点的数据库连接工具会连不上。可以简单地把用户改成mysql_native_password插件，虽然安全性弱一点，但在内网开发环境问题不大。

6.3 部署时的资源与环境规划

答疑系统这个体量，一台2核4G的云服务器就完全够跑。内存分配上我建议：MySQL占用1G，SpringBoot应用（JVM）占用1.5G，剩下给操作系统和缓存。JVM参数要调，不要默认的堆内存，我用的是：

java -jar course-answer-server.jar --spring.profiles.active=prod -Xms1024m -Xmx1536m -XX:+UseG1GC

静态资源（图片、视频）尽量走MinIO或者云OSS，不要把文件落在应用服务器的本地磁盘。否则每次发版清理磁盘都是麻烦事，而且应用服务器如果要扩容，文件不在本地才好扩展。

MySQL的定时备份建议至少每天一次，使用mysqldump全量备份：

mysqldump -uroot -p course_answer > /backup/course_answer_$(date +%Y%m%d).sql

这个命令配合crontab，凌晨3点执行，保留最近7天的备份就够了。

7. 上线后遇到的典型问题与排查经验

7.1 页面白屏与Vue打包后路由404

Vue项目npm run build之后，dist目录放到SpringBoot的static下面，刷新页面就404。原因是Vue是SPA，路由走的History模式，刷新时按实际路径请求了后端，后端没有这个路径对应的接口，自然就404了。

解决方案是两个：一是后端配置一个fallback，把所有非/api的请求转发到index.html；二是前端改用hash模式，URL变成/#/的形式。hash模式有丑但简单，History模式美观但需要后端配合。我的建议是使用History模式加后端配置，正规项目没人愿意看到URL带#。

7.2 并发发帖导致的重复数据与答疑状态异常

有一阵子系统里出现了同一个学生提交了多条一模一样的提问，排查下来是网络波动导致前端请求重发。前端做了一下提交按钮的loading禁用，加上后端用Redis的幂等键（学生ID+标题哈希值）做了唯一性校验，问题就解决了。

状态异常则是事务问题。比如学生采纳答案，同时要更新answer表的is_accepted和question表的status、accepted_answer_id，这两个更新操作必须是同一个事务，否则中间出错就会出现“答案已采纳但问题还是已回答状态”这种不一致。

@Transactional(rollbackFor = Exception.class) public void acceptAnswer(Long questionId, Long answerId) { // 更新回复为采纳 // 更新问题状态为CLOSED }

7.3 MyBatis缓存导致的脏读

开发早期，我曾经在MyBatis里开了二级缓存（全局缓存），结果遇到了修改一个问题之后，其他线程查询出来还是旧数据的脏读问题。后来排查发现是不同Mapper操作同一张表，缓存没有及时刷新。

MyBatis的二级缓存是namespace粒度的，也就是说QuestionCache只在QuestionMapper的namespace里生效，如果另一个Mapper直接UPDATE了question表，这个缓存不会被自动清理。

解决方案很简单：企业级业务系统默认不要开MyBatis二级缓存，把缓存交给Redis或Caffeine在Service层控制。数据库的底表数据一致性永远比缓存带来的那点性能提升值钱。

7.4 富文本导致的XSS注入

这个一定要提，因为答疑系统天然是富文本场景，而富文本是XSS攻击的高发区。我在前端编辑器和后端渲染层都做了转义处理，但最开始只在输出层做了简单过滤，导致用户在问题内容里插入了script标签直接在管理后台执行。

后来规范做法是双重过滤：前端编辑器粘贴时过滤危险标签，后端入库前再用白名单过滤（允许p、br、img、code、pre等标签，过滤script、iframe、on*事件属性）。不要相信任何前端传来的内容，后端必须再做一道防线。

8. 复盘总结与几个值得说的经验

这个项目从零到一完整跑通，前后大概花了两周多时间，但真正写业务代码的时间不到一周，剩下一半时间全花在了环境配置、兼容性排查和联调上。所以说，拿到一套完整的SpringBoot+Vue+MyBatis+MySQL源码，最重要的不是代码本身，而是能不能理解每一条配置、每一个设计决策背后的原因。

关于环境兼容性，再唠叨一句Java版本的事。SpringBoot 2.7对应JDK8，SpringBoot 3.x对应JDK17，国内很多云服务器的默认JDK版本各不相同。装Java环境的时候先确认项目pom.xml里的版本和要求，再选择对应的JDK，省得后面各种NoSuchMethodError。

如果后续还想扩展，我建议可以做三件事：一是把Redis接进来，缓存热帖和用户会话，性能再上一个台阶；二是用EasyExcel导出答疑统计报表，管理员做数据汇报的时候非常有用；三是接一个流媒体服务，把录播答疑的视频切片流程自动化。这个项目骨架是健康的，往哪个方向生长都有余地。

最后分享一个心得：企业级系统的核心不是炫技，而是把所有关键的路径跑稳。答疑、回复、采纳、统计，这些环节每一个都要能追溯。做项目的过程中多留日志、多埋点、多用统一异常处理，等到线上出了问题，你会发现当初那些“多此一举”的设计全都在救你的命。