企业官网建设流程全解析

项目标题这行字，我第一眼看到的感觉是：这是一个典型的“毕设/练手级”前后端分离管理系统，但它的价值点在于业务场景非常具体——文学创作社交论坛。SpringBoot+Vue+Java+MySQL+MyBatis这套组合，放到今天依然是中小型系统中非常稳的选型。这个项目既不是纯后台的CRUD练习，也不是花里胡哨的Demo，而是一个有真实业务闭环的论坛系统：作者写作品、管理员审核、读者评论点赞、标签分类管理。如果你正想找一个能完整练手前后端分离、又能在简历上写清楚业务亮点的项目，我觉得这个方向很合适。

这篇文章我打算用实战复盘的方式，把我做这类系统时涉及到的需求拆解、数据库设计、后端接口实现、前端页面落地、部署排错这些环节都过一遍。很多内容是基于我自己做类似项目的常见实践补充出来的，不一定和某个特定开源仓库完全一样，但整体思路和关键代码写法可以直接参考。

1 项目到底在做什么，为什么值得做

1.1 先理清业务角色和功能边界

文学创作社交论坛，核心不是“论坛”两个字，而是围绕“创作”展开的内容生产与消费闭环。在我拆解这个项目的时候，第一时间把用户分成三类：普通读者、作者、管理员。一个人可以既是读者又是作者，所以角色最好设计成用户表上的一个字段，而不是单独建一套作者认证体系，除非你要做实名、签约作者这种重度业务。

普通读者端的核心诉求是找内容、看内容、反馈内容。找内容靠分类和标签筛选，也可以靠搜索框；看内容需要作品详情页和章节阅读页；反馈内容就是评论、点赞、收藏。这三个动作看起来简单，但并发场景下很考验接口设计。作者端则要提供作品创建、章节编辑、草稿保存、投稿审核、数据统计这些能力。管理员端最核心的是内容审核，因为文学创作论坛内容量大，如果审核不过关，后面就会演变成内容安全问题，所以审核列表、驳回原因、状态流转这些功能一个都不能少。

把功能边界划清楚之后，整个项目的开发顺序也就出来了：先做用户注册登录，再做作品模块，再做审核流，最后补评论点赞收藏这些社交动作。很多新手上来就写点赞接口，结果作品模块还没影儿，逻辑全是空的，后面返工成本很高。

1.2 技术选型不是拍脑袋

SpringBoot+Vue+MySQL+MyBatis这套组合在2025年依然值得选，不是因为“大家都在用”，而是它解决的问题刚好匹配这个项目：

SpringBoot负责把后端工程的配置简化到极致，一个内嵌Tomcat就让部署变得非常简单，开发阶段一个Application类直接跑起来。MyBatis虽然不如MyBatis-Plus写起来省事，但它把SQL掌控力留给了开发者，在这个项目里我要写多表关联、动态条件查询，XML里手写SQL反而更直观。Vue3的组件化开发非常适合论坛这种多页面、多状态的场景，单页应用切换流畅，配合Element Plus做后台管理界面效率极高。MySQL不用多说，中小型论坛的数据量完全够用，事务支持和全文索引都可靠。

可能有人会问，为什么不加Redis？我在项目早期也没加，因为点赞、浏览计数这些热点数据在用户量没上来之前，直接查数据库配合唯一索引就足够稳定。如果后面要扩展，再把计数器迁到Redis，用定时任务刷回MySQL，这是后话，但不影响当前架构的正确性。

2 数据库设计：先把表结构定清楚

2.1 从实体关系到核心表

数据库设计是整个项目里面最不能省的一步。我见过太多人没画清楚关系就写代码，后面发现作品和章节对不上、评论查不出用户名、统计数量全是0，最后只能重构表。这个系统的实体关系其实很清晰：

一个用户有多部作品，一部作品属于一个作者。一部作品包含多个章节，章节按sort_no排序。一个用户可以评论多个作品/章节，一条评论可以有父评论形成楼中楼。一个用户可以点赞多个作品，一个作品可以被多个用户点赞。一个作品可以有多个标签，一个标签也可以挂在多个作品上。一个作品归属一个分类，分类是一棵简单的两级树就够用。

这些关系捋清楚之后，表就是十张左右，我列一下核心的：user，category，work，chapter，comment，user_like，user_favorite，tag，work_tag，audit_record。audit_record可能很多人会忽略，其实很重要，因为管理员审核通过或驳回的操作需要留痕，出了纠纷可以追溯。

2.2 几张核心表的字段拆解

以work表为例，字段设计我会这样写：id主键，author_id关联用户表，title作品标题，summary作品简介，cover_url封面图，category_id分类，status状态，word_count字数，like_count点赞数，favorite_count收藏数，comment_count评论数，create_time创建时间，update_time更新时间，is_delete逻辑删除标记。

这里有个设计习惯我想特别提一下：评论数、点赞数我直接冗余在了work表里，而不是每次都去count子表。原因是论坛首页要展示一堆作品的点赞数和评论数，如果每个作品都实时count一次，一个列表接口会变成N+1查询，数据库压力非常大。冗余虽然有数据一致性问题，但在这个业务场景下完全可以通过事务和定时任务去兜底，性价比很高。

章节表单独拆出来也很有必要。一部连载小说可能有几百章，如果所有内容都塞在一张表里，单行数据会很大，列表查询会变慢，编辑时锁表时间也会变长。拆成chapter表之后，作品表负责元数据，章节表只负责内容和排序，两个表的职责边界非常清楚。

下面是我个人的建表风格，核心字段写出来，大家建表时可以参考：

CREATE TABLE `work` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `author_id` bigint(20) NOT NULL COMMENT '作者ID', `title` varchar(200) NOT NULL COMMENT '作品标题', `summary` varchar(1000) DEFAULT NULL COMMENT '作品简介', `cover_url` varchar(500) DEFAULT NULL COMMENT '封面图', `category_id` bigint(20) DEFAULT NULL COMMENT '分类ID', `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '0草稿 1待审核 2已发布 3被驳回 4已下架', `word_count` int(11) NOT NULL DEFAULT '0' COMMENT '总字数', `like_count` int(11) NOT NULL DEFAULT '0', `favorite_count` int(11) NOT NULL DEFAULT '0', `comment_count` int(11) NOT NULL DEFAULT '0', `create_time` datetime NOT NULL COMMENT '创建时间', `update_time` datetime DEFAULT NULL COMMENT '更新时间', `is_delete` tinyint(1) NOT NULL DEFAULT '0', PRIMARY KEY (`id`), KEY `idx_author_id` (`author_id`), KEY `idx_category_status` (`category_id`, `status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='作品表';

状态字段我建议大家用tinyint不要用varchar，状态迁移用数字可读性确实差一点，但性能和约束能力都好很多，而且在后端写枚举类做映射，代码层面反而更规范。

2.3 设计时我踩过的几个坑

第一个坑是字符集。建库如果不指定utf8mb4，默认字符集在插入emoji表情时直接报错Incorrect string value，论坛评论里用户发个表情是很正常的事情，所以建库SQL里必须加上CHARSET=utf8mb4。第二个坑是时间字段，我建议统一用datetime，不要混合timestamp，否则后面做统计查询时，时区问题会让人很崩溃。第三个坑是逻辑删除，评论、作品这些核心表一定要有is_delete字段，但点赞表、收藏表不要做逻辑删除，直接物理删，因为它的意义就是一条关系记录，删除后重新点赞反而更自然。

另外，唯一索引一定要到位。点过赞之后不能重复点赞，这是业务硬约束，与其在代码里先查一遍再插入，不如直接在表上加联合唯一索引，数据库层面挡住重复数据，代码逻辑就算漏了也不会出大问题。

3 后端核心实现：SpringBoot + MyBatis

3.1 工程结构与基础配置

后端工程我习惯按功能分包，而不是按技术层分包。也就是com.forum.controller、com.forum.service、com.forum.mapper之外，再按业务模块划分包，比如user、work、chapter、comment、admin。这样做的优点是：当你想看某个业务模块的完整代码时，直接进一个包就能看全流程，不用在各个层级之间反复跳。

核心配置都在application.yml里，下面这段配置是我每次搭建类似项目都会先写好的一版：

server: port: 8080 servlet: context-path: /api spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/forum?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false username: root password: 123456 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai mybatis: mapper-locations: classpath:mapper/*.xml configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

map-underscore-to-camel-case这个配置一定要打开，否则数据库里的author_id映射不到JavaBean的authorId，查出来全是null。日志打印也建议在开发阶段打开，这样能直接在控制台看到MyBatis生成的SQL和参数，排查问题效率翻倍，上线前再关掉。

3.2 JWT登录态与请求拦截

这个项目是前后端分离，Session方案天然不适用，我选了JWT做无状态认证。流程很简单：用户登录成功后，后端用userId和role生成一个带过期时间的token返回给前端；前端把token存到localStorage；后续每次请求在Authorization头里带上，后端用一个HandlerInterceptor统一解析验证。

拦截器里有个细节要特别注意：登录接口、注册接口、首页作品列表接口、作品详情接口都要放进白名单，否则用户还没登录就什么都看不了，那种体验非常差。很多新手会把拦截器加到所有路径上，结果登录接口自己都被拦住了，反复调不通。

@Component public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); if (token != null && token.startsWith("Bearer ")) { token = token.substring(7); } try { Claims claims = JwtUtil.parseToken(token); request.setAttribute("userId", claims.get("userId")); request.setAttribute("role", claims.get("role")); return true; } catch (Exception e) { response.setStatus(401); response.getWriter().write("{\"code\":401,\"message\":\"登录已过期，请重新登录\"}"); return false; } } }

这里的逻辑虽然简单，但包含了两个容易忽视的点：一是token前缀Bearer的截取，前后端约定必须一致；二是解析失败时直接返回401响应体，而不是抛异常往后抛，否则会变成500让前端一脸懵。

3.3 作品发布与审核流程的实现

作品发布是这个系统最核心的业务，状态流转一定要设计严谨。我先定义状态枚举：0草稿、1待审核、2已发布、3被驳回、4已下架。作者的操作为：创建作品时是草稿，可以编辑内容；点击投稿后状态变成待审核；管理员审核通过变成已发布；审核不通过变成被驳回，同时写一条驳回原因；已发布作品也可以被管理员主动下架。

这里最容易出错的地方是状态跳转校验。比如已发布的作品不能再提交审核，被驳回的作品必须编辑后才能重新提交。我在Service层写了一个状态机方法，每次变更状态前先判断当前状态是否合法。

@Override @Transactional(rollbackFor = Exception.class) public void audit(Long workId, Integer status, String reason) { Work work = workMapper.selectById(workId); if (work == null) { throw new BusinessException("作品不存在"); } if (!work.getStatus().equals(WorkStatus.PENDING.getCode())) { throw new BusinessException("该作品当前状态不允许审核"); } work.setStatus(status); work.setUpdateTime(new Date()); workMapper.updateById(work); AuditRecord record = new AuditRecord(); record.setWorkId(workId); record.setOperatorId(CurrentUser.get().getUserId()); record.setAction(status == 2 ? "pass" : "reject"); record.setReason(reason); auditRecordMapper.insert(record); }

注意我在审核方法上加了@Transactional。因为更新作品状态和插入审核记录必须在一个事务里，如果先改了作品状态、后面插入审核记录失败，那整个状态就错乱了。事务的rollbackFor一定要写成Exception.class，否则抛出非RuntimeException时事务不会回滚，这是很多人踩过的坑。

3.4 用XML手写动态SQL的列表查询

前台的作品列表需要支持多条件筛选：分类、标签、状态、关键词、发布时间排序、最热排序。这种需求用MyBatis的XML动态SQL写起来非常顺手。

<select id="selectWorkPage" resultType="com.forum.vo.WorkVO"> SELECT w.id, w.title, w.summary, w.cover_url, w.like_count, w.comment_count, u.nickname AS authorName, c.name AS categoryName FROM work w LEFT JOIN user u ON w.author_id = u.id LEFT JOIN category c ON w.category_id = c.id <where> <if test="categoryId != null"> AND w.category_id = #{categoryId} </if> <if test="keyword != null and keyword != ''"> AND (w.title LIKE CONCAT('%', #{keyword}, '%') OR w.summary LIKE CONCAT('%', #{keyword}, '%')) </if> AND w.status = 2 AND w.is_delete = 0 </where> ORDER BY <choose> <when test="sort == 'hot'">w.like_count DESC</when> <otherwise>w.create_time DESC</otherwise> </choose> LIMIT #{offset}, #{pageSize} </select>

这个SQL有两个关键点。第一个是LEFT JOIN，查询列表时把作者昵称和分类名称join出来，避免在Java代码里循环查表，全部一次查出。第二个是WHERE条件，我把“已发布”和“未删除”这种固定条件直接写在where标签里，作为一个全局兜底，防止条件拼接出错时查出草稿内容。

动态SQL还有一个非常实操的点：新手经常在用 拼接条件时，因为第一个条件前面带了AND导致SQL报错，所以我会把固定条件放在 之后，保证至少有一个无条件约束存在。上面这个语法里，第一个if前面没有AND，后面的if都用AND开头，配合 标签会自动去掉最前面的AND，这是比较稳妥的写法。

4 前端实现细节：Vue3 + Element Plus

4.1 前端工程搭建与目录规划

前端我用的Vue3 + Vite + Pinia + Vue Router + Element Plus，这套组合是目前Vue生态里最顺手的。Vite的冷启动速度比Webpack快太多，开发体验完全不一样；Pinia比Vuex写法更简洁，省了很多样板代码。

目录结构我建议按视图和功能混合组织：

src ├── api # 接口请求模块，按业务拆分 │ ├── user.js │ ├── work.js │ └── admin.js ├── assets ├── components # 通用组件 │ ├── WorkCard.vue │ └── Pagination.vue ├── router │ └── index.js ├── store │ └── user.js ├── utils │ └── request.js ├── views │ ├── Home.vue │ ├── login/Login.vue │ ├── work/WorkDetail.vue │ ├── write/WriterCenter.vue │ └── admin/AdminAudit.vue └── App.vue

api目录单独抽出来是必做的一步，因为前端所有请求都封装在api模块里，后端接口变动时只需要改一个文件，不用在页面里到处找。很多小项目把axios请求直接写在组件里，开始只有两三个接口还行，后面会长到完全没法维护。

4.2 Axios封装、登录状态与路由守卫

Axios封装是前端工程质量的分水岭。我的做法是统一实例里设置baseURL，请求拦截器里从Pinia或localStorage取token，加在请求头上；响应拦截器统一处理后端返回结构，遇到401自动跳登录页，其他业务错误统一Message提示。

import axios from 'axios' import { ElMessage } from 'element-plus' import router from '@/router' import { useUserStore } from '@/store/user' const request = axios.create({ baseURL: '/api', timeout: 10000 }) request.interceptors.request.use(config => { const userStore = useUserStore() if (userStore.token) { config.headers.Authorization = 'Bearer ' + userStore.token } return config }) request.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { ElMessage.error(res.message || '请求失败') return Promise.reject(new Error(res.message)) } return res }, error => { if (error.response && error.response.status === 401) { const userStore = useUserStore() userStore.logout() router.push('/login') } ElMessage.error(error.response?.data?.message || '网络异常') return Promise.reject(error) } ) export default request

看了这段代码，你应该能理解为什么我不在组件里直接写axios。组件只关心业务数据，token注入、错误处理、登录过期这些横切逻辑全在拦截器里做掉了，每个页面减少十几行重复代码。

路由守卫我这里分了两层。第一层是登录权限：凡是需要登录才能访问的页面，如果没有token就跳登录页。第二层是角色权限：后台管理页只有role为admin的用户才能访问。

router.beforeEach((to, from, next) => { const userStore = useUserStore() if (to.meta.requiresAuth && !userStore.token) { next('/login') return } if (to.meta.requiresAdmin && userStore.role !== 'admin') { next('/403') return } next() })

这套写法不难，但很实用。把权限逻辑集中在路由守卫里，比在每个页面去判断角色要省心太多，而且不会漏。

4.3 创作中心与作品详情页的实现思路

创作中心是这个项目前端最有挑战的部分，因为它不是一个简单的表单页，而是多步骤创作流程。我的设计是左侧作品列表，右侧章节编辑区。点击作品后展示章节列表，每章可以独立编辑标题和正文，然后保存草稿或提交审核。

为了降低用户流失率，我做了两个细节。第一个是本地上稿暂存：每次编辑内容自动调用保存草稿接口，而不是等用户手动点保存，当然这个动作要加防抖；第二个是章节拖拽排序，让连载作者调整章节顺序时不用重新输入序数。

作品详情页则要处理三个核心信息流：正文阅读、章节目录、评论区。正文阅读我用了简单的分页加载，一页一章；章节目录做成侧边抽屉，点击章节后局部刷新正文内容区，而不是整个页面跳转。

评论区有个常见问题是父子评论的嵌套，如果后端返回的是扁平数组，前端就要自己构建树结构。我建议后端直接按parent_id和create_time排序返回，前端在递归组装时注意层级深度限制，最多两级就够了，再深会出现DOM层级过深和缩进错乱。

4.4 富文本编辑、图片上传与安全过滤

作者写小说、散文，正文肯定不能只用一个textarea，我用的是富文本编辑器，创作中心里的章节内容就用富文本去编辑。但富文本编辑器的安全风险要想清楚：用户粘贴过来的内容可能包含script标签、内联事件，如果直接入库再原样渲染，就是一个存储型XSS漏洞。

后端在做内容保存时必须做HTML白名单过滤，把script、iframe、on*事件全部剥掉，只保留p、br、img、strong这些常用标签。前端展示时我也会再做一层转义兜底，双保险。

图片上传这里，开发环境我直接把图片存到本地目录，配置一个静态资源映射让前端能访问。生产环境我建议接入MinIO，对象存储的好处是图片访问走独立域名，可以减轻应用服务器磁盘压力。

@PostMapping("/upload") public Result<String> upload(@RequestParam("file") MultipartFile file) { if (file.isEmpty()) { return Result.error("文件不能为空"); } String originalFilename = file.getOriginalFilename(); String ext = originalFilename.substring(originalFilename.lastIndexOf(".")); String fileName = UUID.randomUUID().toString().replace("-", "") + ext; String datePath = new SimpleDateFormat("yyyyMMdd").format(new Date()); File dir = new File(uploadPath + "/" + datePath); if (!dir.exists()) { dir.mkdirs(); } file.transferTo(new File(dir.getAbsolutePath(), fileName)); String url = "/upload/" + datePath + "/" + fileName; return Result.success(url); }

文件名必须重命名，这个习惯一定要养成。直接用用户原始文件名，一是中文和特殊字符会导致URL编码问题，二是同名文件会互相覆盖。用UUID生成文件名是最省心的。

5 联调、部署与常见问题排查

5.1 前后端联调阶段的高频问题

联调阶段是报错最多的阶段，我梳理几个必定会遇到的问题。

首先是跨域。开发时前端跑在5173端口，后端跑在8080端口，两个端口不同就是跨域。解决方式是在后端写一个CorsFilter，允许指定来源访问；但上线后我建议走Nginx反向代理，让前端静态资源和后端API处于同一个域名之下，这样就没有跨域问题了。很多人在本地把Axios的baseURL写成http://localhost:8080/api，上线后忘了改成/api，结果一片404，所以在部署时我会把开发环境和生产环境的baseURL拆成不同环境变量。

其次是Long类型的精度丢失。数据库表主键是bigint，返回给前端时在JS里超过Number最大值会丢失精度。如果后面你用了雪花ID，这个问题立刻就会出现。解决方式是在Jackson配置里把Long序列化为字符串。

第三是日期格式问题。后端返回的LocalDateTime默认序列化出来的格式是带T的ISO格式，前端如果不处理，页面上直接显示一串字母。我在后端配置了全局Jackson格式为yyyy-MM-dd HH:mm:ss，前端再配合dayjs做格式化，两边统一。如果不统一，列表页的时间列会乱得一塌糊涂。

5.2 从本地到服务器的部署步骤

这个项目部署起来其实不复杂，但每个环节都容易出细节问题。我把完整步骤理一遍。

第一步准备服务器环境：装JDK8+、MySQL5.7/8.0、Nginx。MySQL导入项目里的schema.sql，注意建库时指定utf8mb4字符集。

第二步后端打包：在项目根目录执行mvn clean package -DskipTests，生成的jar包通过ftp或scp传到服务器，用java -jar forum-server.jar启动。为了让服务在后台稳定运行，我用的是systemd配置服务脚本，设置Restart=always，省得进程一崩还得手动拉起来。

第三步前端打包：在vue项目里执行npm run build，dist目录上传到服务器，比如放到/opt/forum-web。

第四步配置Nginx，核心配置如下：

server { listen 80; server_name your-domain.com; root /opt/forum-web; index index.html; location /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 $uri $uri/ /index.html; } client_max_body_size 10m; }

location / 里的try_files是Vue Router history模式必须加的，否则用户刷新详情页时Nginx会返回404。location /api/做API反向代理，这样前端请求/api开头的地址后，Nginx会转发给后端8080端口。client_max_body_size必须设置，默认值是1m，不改的话上传封面图稍微大点就413了。

5.3 常见错误速查表

我整理了一个速查表，这几类问题是论坛项目里反复出现的，大家可以直接按表排查。

这个表看起来平淡，但每个都是真实发生过的。特别是第一和第二项，拦截器白名单和token持久化，我见过太多人在这两个问题上折腾一整天。

5.4 几个值得长期保持的编码习惯

第一，MyBatis的XML文件里动态SQL拼接时，建议统一用 嵌套，不要自己在SQL里写where 1=1，虽然能解决and开头问题但代码很难看。第二，所有列表接口都必须分页，不管现在数据量有多大，这是习惯而不是需求。第三，涉及金额、状态流转的操作必须加事务，而且事务里不要捕捉异常吞掉，否则回滚逻辑会失效。

还有一点是关于日志的。开发阶段把MyBatis的SQL日志打印打开，出问题时直接看控制台；但是上线前一定要关掉，因为生产环境打印全量SQL会导致日志文件暴涨和性能下降。可以用logstash或基于SpringBoot的日志框架来分级控制，但最小可用方案就是logback.xml里调整成info级别。

6 一些个人经验复盘

6.1 如果重新做一次，我会怎么改

这个项目如果我再做一遍，最大的改动会是把“作者创作”和“读者阅读”彻底拆成两个子系统来思考，而不是在同一个服务里堆功能。倒不是说一定要微服务，而是说，在代码结构上，创作端的作品保存、章节编辑、审核提交，和阅读端的详情查询、评论列表，其实是两类不同的访问模式。前者是低频写操作，后者是高频读操作。如果把读写混在一起，后面做缓存优化时你会非常痛苦。

另外，我会在项目初期就把搜索方案定下来。只靠MySQL的LIKE查询在数据量过万后就会变得很慢，如果一开始就预留搜索的表结构，或者直接引入Elasticsearch/OpenSearch，后面做全文检索就不会伤筋动骨。论坛内容的搜索和筛选是这个项目的核心体验，不能等到数据量大了才去补救。

6.2 给想拿这个项目练手的人三条建议

第一，不要急着写代码。花两天时间把所有表结构设计好，把状态流转图画明白，再开始动手，整体效率反而更高。第二，一定要自己从头搭一遍工程，不要直接用别人整合好的脚手架。SpringBoot+Vue这套组合的配置细节非常多，只有自己踩过坑才能说真正掌握了。第三，把异常处理和参数校验当成一等公民来做，一个接口没有参数校验，传入空值直接空指针，这种代码在简历上是减分项而不是加分项。

最后说一句实在话：这类论坛系统的技术点其实不难，难的是把内容审核状态、点赞防刷、评论排序、数据一致性这些业务细节处理干净。当你把这些细节都扛下来，这个项目的含金量就真的出来了。