企业官网建设流程全解析

说起来挺奇怪的，网上打着“SpringBoot + Vue + MySQL 管理系统源码”旗号的项目不少，但真正能让你在半小时内跑起来的，其实没几个。要么是数据库脚本缺字段，要么是前端依赖版本冲突，要么是配置文件里写死了别人的本地路径。我最近拿到一套“网站信息管理系统源码”，后端是 SpringBoot，前端是 Vue，数据库用的 MySQL，标题里明确写了“可直接运行”。本着验证的心态我把整套流程走了一遍，从建库到后台登录，再到发布第一条文章数据，整个过程确实顺。这篇文章就把这套系统的功能拆解、核心实现逻辑和完整运行步骤写清楚，给正准备做类似管理系统、或者在为课程设计找参考项目的朋友一份真实可用的操作底稿。

1. 这个“网站信息管理系统”到底管什么——项目全景拆解

1.1 核心功能模块一览

这套系统说白了就是一套通用内容管理后台，核心是管“网站上要展示的信息”。我把它拆开看了一遍，功能模块做得比较克制，没有堆一堆用不上的东西，每个模块都能对应到实际业务场景。

从这个功能列表能看出来，这套系统的定位很清晰：它不是一个功能堆砌的“大而全”平台，而是一个给中小型官网、企业站、课程设计项目做内容维护的通用后台。如果你需要往里面加业务，比如商品管理、订单管理，架构上是有扩展空间的，但那是二次开发的事。

1.2 技术选型为什么是经典的老三样，而不是追新

我看到有不少人在问“为什么不用 Spring Cloud”“为什么不用 Vue 3 + Vite”，这里我多说两句。

很多管理类系统，尤其是信息管理、内容发布这类业务，最大的诉求其实不是高并发、分布式，而是稳定、可维护、资料多。SpringBoot 加 MySQL 的组合，在国内的 Java 开发者里存量最大，遇到问题一搜就有答案；Vue 2 和 Element UI 的搭配经过大量生产项目验证，组件行为稳定，文档齐全。这套源码没有整那些花活，反而好落地。

从二次开发角度看，SpringBoot 的自动装配大幅减少了配置时间，只需要关注 Controller、Service、Mapper 三层逻辑；Vue 2 的单文件组件和 Element UI 的现成表格、表单、弹窗组件能让后台界面的开发速度提升一个量级；MySQL 作为关系型数据库，对于后台管理系统这种“增删改查 + 统计筛选”的场景是天然契合的。技术选型不是越新越好，而是越匹配场景越好。

1.3 拿到源码后的第一件事：先看目录结构，别急着敲命令

很多人下载源码后第一反应就是打开 IDE 直接跑，结果跑出一个大花脸报错。我的习惯是先花十分钟看看目录结构，心里有数了再动手。

这套源码的根目录一般分两个子工程，一个backend（SpringBoot），一个frontend（Vue）。后端包结构是典型的controller - service - mapper - entity四层：

com.site.admin ├── config // 跨域、拦截器、资源映射等配置类 ├── controller // 接口入口 ├── entity // 数据库实体类 ├── mapper // MyBatis-Plus 数据访问层 ├── service // 业务逻辑层 ├── common // 统一响应结果、异常处理 └── util // JWT、MD5 等工具类

前端结构是 Vue 标准的工程组织方式：

src ├── api // 按模块封装的接口请求 ├── router // 路由配置 ├── store // 用户状态管理 ├── views // 页面组件（login/article/category/banner/user/setting） ├── layout // 后台整体布局（侧边栏+顶栏） └── utils // axios 封装、token 处理等

目录清爽的项目，通常代码风格也不会差到哪去。看完结构之后，再去对应application.yml、package.json、数据库脚本这三处关键的配置，就可以进入正式运行环节了。

2. 后端 SpringBoot 核心实现——接口、鉴权与文件上传

2.1 基于 Controller-Service-Mapper 三层结构的接口设计

后端整体是标准的业务三层写法，Controller 不写业务、Service 不写 SQL、Mapper 只做数据访问。这种分层的好处是改动某一层不影响其他层，比如你要把 MyBatis-Plus 换成 JPA，只需要重写 Mapper 层和实体注解，Controller 和 Service 的接口契约都不用动。

核心接口我列一下，你拿到源码后可以直接在浏览器里验证（需要先启动后端）：

这里有个细节值得留意：接口统一以/api开头，这是后端和前端的一层“约定”。开发环境前端通过代理把/api转发到localhost:8080，生产环境 Nginx 也只要转发这一个路径就行，不用每个接口单独配代理。

统一响应体也做得规整，所有接口返回的都是同一个结构：

public class Result<T> { private Integer code; // 200 成功，500 失败，401 未登录 private String message; private T data; public static <T> Result<T> ok(T data) { Result<T> r = new Result<>(); r.setCode(200); r.setMessage("操作成功"); r.setData(data); return r; } public static <T> Result<T> fail(String message) { Result<T> r = new Result<>(); r.setCode(500); r.setMessage(message); return r; } }

前端拿响应的时候只判断code就行，不需要关心 HTTP 状态码怎么变。这种约定在前后端分离项目里非常重要，能在很大程度上减少联调时你问我答的沟通成本。

2.2 JWT 登录鉴权是怎么串起来的

后台管理系统第一个要解决的问题就是“谁可以进来看、谁可以操作”。这套系统用的是 JWT（JSON Web Token）方案，而不是传统的 Session。

为什么是 JWT？关键原因是前后端分离。前端是独立部署的页面，后端是独立服务，如果用 Session，就得考虑 Session 共享、跨域携带 Cookie 等一系列问题；而 JWT 把用户凭证信息加密后直接发给前端，前端每次请求在请求头带上这个 token 即可，后端既不存状态，也不依赖 Cookie，天然适合这种架构。

登录流程简单说就是三步：

// 第一步：校验用户名密码 User user = userService.login(username, md5(password)); if (user == null) { return Result.fail("用户名或密码错误"); } // 第二步：生成 JWT token String token = Jwts.builder() .setSubject(user.getUsername()) .claim("role", user.getRole()) .setExpiration(new Date(System.currentTimeMillis() + 7 * 24 * 3600 * 1000)) .signWith(SignatureAlgorithm.HS256, jwtSecret) .compact(); // 第三步：返回给前端 return Result.ok(token);

加密方式用的是经典的两层组合：密码存库前做 MD5，登录成功后的 token 用 JWT 签名。要注意的是，密码 MD5 在正式生产环境里已经算不上强加密，如果这套系统要上线到公网，建议换 BCrypt 这类加盐哈希，代码改动也不算大，就是util里加一个加密工具类，再把登录校验处换一下。

有了 token 之后，后端的拦截器会拦截除登录接口以外的所有请求，从请求头里取出Authorization字段校验 token 是否有效、是否过期：

@Component public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); if (StringUtils.hasText(token) && JwtUtil.validateToken(token)) { return true; } response.setStatus(401); return false; } }

这套逻辑本身不复杂，但值得学习的是“白名单”的概念——登录接口、图片访问路径这些本来就不需要带 token 的请求，要在WebMvcConfigurer里放行，否则会把自己卡死。

2.3 文章分页与多条件查询的实现思路

文章管理是整个系统的核心模块。列表页要支持按标题模糊搜索、按栏目筛选、按上下线状态筛选，还要分页，这套查询在 MyBatis-Plus 里面写起来非常顺手。

LambdaQueryWrapper<Article> wrapper = new LambdaQueryWrapper<>(); wrapper.like(StringUtils.hasText(title), Article::getTitle, title) .eq(categoryId != null, Article::getCategoryId, categoryId) .eq(status != null, Article::getStatus, status) .orderByDesc(Article::getIsTop) .orderByDesc(Article::getCreateTime); Page<Article> page = new Page<>(pageNum, pageSize); articleMapper.selectPage(page, wrapper);

这里有个容易被忽略的细节：like、eq这些方法的第一个参数是布尔表达式，只有条件成立时才会追加这个查询条件。比如用户在查询参数里没传title，StringUtils.hasText(title)就是 false，这个模糊查询条件就不会被拼进 SQL。这是 MyBatis-Plus 最实用的特性之一，能避免你手动写一堆if判断去拼接查询条件。

分页插件在config包里配置了一个MybatisPlusInterceptor，添加了分页拦截器，所以上面selectPage才能正常生效。如果你拿到源码后自己加新的分页接口，一定记得确认这个配置存在。

置顶文章的排序也很有讲究：置顶的排前面，按置顶 DESC，再按创建时间 DESC。这样既能保证重要内容一直在列表头部，又不会让时间字段完全失效。

2.4 文件上传与静态资源映射

后台管理离不开图片上传，文章封面、轮播图、Logo 都要传。这套系统采用的是最直接的本地磁盘存储方案：前端把文件通过 POST 请求传给后端，后端保存到配置的磁盘路径，然后把可访问的 URL 返回给前端。

核心代码逻辑大致是这样：

@PostMapping("/upload") public Result<String> upload(@RequestParam("file") MultipartFile file) { // 生成唯一文件名，防止重名覆盖 String originalFilename = file.getOriginalFilename(); String ext = originalFilename.substring(originalFilename.lastIndexOf(".")); String newFileName = UUID.randomUUID().toString().replace("-", "") + ext; // 保存到配置的本地路径 File dir = new File(uploadPath); if (!dir.exists()) { dir.mkdirs(); } file.transferTo(new File(dir, newFileName)); // 返回浏览器可访问的 URL return Result.ok("/uploads/" + newFileName); }

如果你只做完上面这几步，很快会发现问题：上传成功了，但浏览器访问图片返回 404。原因很简单——SpringBoot 默认不会把本地磁盘上的/uploads/目录暴露成静态资源，需要手动配置映射：

@Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/uploads/**") .addResourceHandler("file:" + uploadPath); }

这个/uploads/**路径要和上传返回的 URL 对应好。以后做二次开发如果加了新的上传类型，比如 PDF、视频，也要走同一套映射逻辑。

3. 前端 Vue 工程——路由守卫、请求封装与页面实现

3.1 为什么是 Vue 2 + Element UI，以及能少踩哪些坑

拿到源码看package.json就能发现，这套系统用的是 Vue 2 和 Element UI，而不是 Vue 3 和 Element Plus。很多读者会纠结要不要升级，我的态度是：不需要，也不建议一上来就升级。

这套源码里大量组件、方法都是基于 Vue 2 响应式原理和 Element UI 的组件 API 写的，比如表格的el-table、表单的el-form、弹窗的el-dialog。Vue 3 虽然兼容大部分写法，但 Element Plus 的很多属性名、事件名、插槽方式都做了调整，直接跑起来会有一堆警告和样式错位。如果你对 Vue 3 没有刚需，就用源码自带的版本。

Vue 2 的另一个实际优势是相关报错的搜索命中率极高。一个编译错误复制到搜索引擎里，基本第一页就能找到解法和原因分析，对于刚接触前端工程的人来说，被卡住的时间会大幅缩短。

3.2 路由模式和登录守卫，为什么用 hash 不用 history

这套前端路由用的 Vue Router 的 hash 模式，也就是地址栏里带#/的那种。我看到不少新手会疑惑：history 模式地址栏更干净，为什么不选它？

原因很实在：hash 模式下的路由变化不会向服务器发请求，刷新页面、直接访问子路由都不会报 404。而 history 模式依赖服务器配置 rewrites，如果你把打包后的 dist 放到 Nginx 里但没配try_files，用户一刷新后台页面就是白屏。这套源码为了做到“可直接运行”，选择 hash 模式是最稳的方案。

再看登录守卫，代码写在router/index.js里：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') if (to.path === '/login') { return next() } if (!token) { return next('/login') } next() })

逻辑很简单：没有 token 一律踢回登录页。有了这个守卫，你在没登录的情况下直接访问/#/article/list，会先跳到登录页，登录成功后再回到目标页面。应用级别的访问控制有了基本保障。

3.3 axios 统一封装——拦截器里做的事比你想的多

前端 API 请求全部走utils/request.js里封装好的 axios 实例。封装的核心思路是：把 token 注入、错误提示、状态码处理全部收敛到拦截器里，每个业务接口只需关注自己的数据和 URL。

const service = axios.create({ baseURL: '/api', timeout: 10000 }) // 请求拦截器：自动携带 token service.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = token } return config }) // 响应拦截器：统一处理业务状态码 service.interceptors.response.use( response => { const res = response.data if (res.code === 200) { return res } this.$message.error(res.message || '请求失败') return Promise.reject(new Error(res.message)) }, error => { if (error.response && error.response.status === 401) { localStorage.removeItem('token') location.href = '/#/login' } this.$message.error('网络异常，请稍后重试') return Promise.reject(error) } )

这段代码里最值得关注的是 401 处理：token 过期或被篡改时，后端返回 401，前端拦截器统一清掉本地 token 并跳转登录页。这种“一处鉴权、全局生效”的机制，保证了任何接口的未授权响应都能让用户回到登录页重新认证。

我在实际二次开发时习惯再给 axios 实例加一个service方法，把export request(options) { return service(options) }暴露出去，这样在页面里写接口调用会非常紧凑，代码可读性也高。

3.4 后台管理页面怎么组织，几个关键页面实现要点

整个后台页面围绕layout展开，左侧是菜单栏，右侧是顶栏加内容区。所有页面组件都通过router-view渲染在内容区里。这种布局模式是后台管理系统的事实标准，如果你要加一个新的功能模块，照着现有页面的结构复制一个目录出来就行。

文章列表页是典型的el-table+el-pagination组合。表格列包括标题、栏目、状态、是否置顶、浏览量、创建时间、操作按钮。状态列用el-tag展示，上线是绿色、草稿是灰色，一眼扫过去整个表的结构状态非常清晰。操作列有编辑、删除、上下线切换，用的是el-button link风格，避免操作按钮堆在一起显得臃肿。分页组件绑定current-page和page-size，切页时重新拉接口，并保持在当前页不回弹。

文章编辑页我多说一句。这个页面的关键点不在表单校验，而在于“编辑回显”和“上传封面”。打开编辑页时，要根据路由参数里的文章 id 请求详情接口，把数据填充到表单里；要特别注意日期格式，后端返回的createTime是数组或者时间戳，需要做格式化转换。封面上传用的是上传组件，上传成功拿到返回的 URL 后再把 URL 写入表单隐藏字段，提交表单时一起传给后端。如果你是自己写页面，最常踩的坑就是把整个File对象传给了后端，而不是传 URL，导致数据库里存了一堆不可访问的二进制路径。

4. MySQL 数据库设计与初始化数据——表结构决定业务边界

4.1 六张核心表的结构设计

数据库脚本一般在项目根目录的sql/site_cms.sql里。建库建表语句我核对过，每一张表的字段都覆盖了业务所需的最小集合，没有冗余，也没有奇怪的关联。

这里特别注意site_config这张表，它是“一种通用配置方案”的体现——用键值对存储任意站点配置项，比如site_name、site_logo、icp_number。你不需要为了一个配置项加一个字段，只需要加一行记录即可。这种设计非常适合后台管理系统里“随时可能要加配置”的场景。

4.2 表之间的关联关系怎么设计

核心关联关系只有两条：

• article.category_id关联category.id，一篇文章属于一个栏目，一个栏目下有多篇文章。前端展示文章列表时通常会 JOIN 栏目表查栏目名，列表页显示的是什么栏目就是这么来的。
• sys_user和article之间通过author字段关联，表示文章的创建人。这里选的是冗余用户名的方案，而不是存 user_id 再 JOIN，省了一次表关联查询。对内容管理系统来说作者名是稳定不常变的，所以这种冗余是可接受的。

栏目表自身通过parent_id实现树形结构，根栏目的parent_id = 0。查询栏目树时后端一次性查出所有栏目数据，在内存里递归组装成树结构返回前端。这种实现方案在栏目量不大的时候性能完全足够，不用上递归 SQL 这种复杂写法。

4.3 初始化数据里藏着登录入口

数据库脚本的末尾，有一段初始化数据，里面写死了第一个管理员账号。默认账号一般是admin，密码是admin123或123456，具体以脚本里的INSERT语句为准。我建议拿到脚本后先打开看这段，因为数据库导入成功以后，登录用的就是这组账号。

如果你要改默认密码，不要在数据库里直接改了一个 MD5 值就完事，而是先去util包里找到 MD5 工具类，跑一个 main 方法生成新的 MD5 串，再替换到数据库里。直接把明文密码写进INSERT是新手常犯的错误，数据库一旦泄露，所有账号都裸奔。

5. 跑通整个项目的完整操作路径——从环境准备到登录后台

5.1 环境版本清单

明确地说，这套系统对环境的要求不高，但版本必须匹配。我在干净的机器上实测的版本组合如下：

我特别强调一下 Node 版本。如果你电脑装的是 Node 18 以上，npm install的时候很容易出现 node-sass 编译失败、OpenSSL 报错这类问题。这个锅不在这套源码，而在旧版本依赖和新版 Node 的兼容性上。最省心的做法是装一个 Node 16.20.x，然后用npm install装依赖，基本不会出问题。

5.2 三步修改配置文件

跑通这套系统，需要动到的配置文件就三个。

第一个是前端的.env.development（或者vue.config.js里的开发环境代理配置），确认开发服务器端口和代理目标地址即可。第二个是后端的application.yml，把数据库名、用户名、密码改成你自己的。第三个是上传路径配置。

以application.yml为例，关键部分是这样：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/site_cms?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 你的数据库密码 servlet: multipart: max-file-size: 10MB max-request-size: 20MB custom: upload-path: D:/projects/upload/ jwt-secret: 自定义一段随机字符串

如果 MySQL 装在本机，地址就是localhost:3306，数据库名要和导入的库名一致。上传路径建议配成一个绝对路径，Windows 注意盘符存在，否则文件会创建失败。

5.3 完整启动顺序与验证方法

启动顺序有讲究，后端和前端谁先谁后都行，但数据库必须先就绪。

1. 先用 Navicat 或命令行创建数据库：CREATE DATABASE site_cms DEFAULT CHARACTER SET utf8mb4;，然后导入site_cms.sql。
2. 在 IDEA 里以 Maven 方式导入后端项目，等依赖下载完成后启动Application类。启动成功后控制台会出现 SpringBoot 启动横幅，然后在浏览器访问http://localhost:8080/api/auth/info，不带 token 应该得到 401 响应，说明鉴权拦截器已生效。
3. 进入前端目录，执行npm install，然后npm run dev。看到编译成功提示后，浏览器访问http://localhost:8081，跳转到登录页。
4. 输入默认管理员账号密码，登录成功后会进入后台首页，看到仪表盘和侧边栏菜单，说明整个前后端链路已打通。

如果你想验证更多，可以立刻创建一个轮播图，上传一张本地图片，再回到前台首页刷新，看 Banner 是否展示。这一套流程走通，说明数据库、文件上传、静态资源映射、接口调用全部正常。

6. 我在实际运行中踩过的坑——配置、跨域与打包部署

6.1 MySQL 8.x 的时区与 SSL 连接报错

这是我遇到的第一个坑，而且是最常见的坑。如果你用的是 MySQL 8.x，没在 JDBC 连接串里配置时区，启动后端时会直接抛异常，提示The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized。

解决办法就是在application.yml的连接串尾部拼接：

url: jdbc:mysql://localhost:3306/site_cms?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai

serverTimezone=Asia/Shanghai解决时区识别问题，useSSL=false是关掉 SSL 加密连接请求。MySQL 8 默认会尝试建立 SSL 连接，如果服务端 SSL 配置不完善，控制台里会刷一堆 SSL 连接失败的错误日志，虽然不影响功能，但会严重干扰排查其他问题。

6.2 前端跨域，用代理而不是改后端 CORS

前端登录时如果遇到跨域报错，千万不要上来就把后端全局 CORS 打开。虽然 SpringBoot 里加一个@CrossOrigin或全局配置能立刻“解决”问题，但这等于把安全边界全部打开，任何来源的网页都可以调你的接口，生产环境是隐患。

这套源码正确且安全的跨域方案是前端代理。开发环境下，在vue.config.js里配置：

devServer: { port: 8081, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }

这样浏览器访问的是8081端口的页面，页面里的请求/api/xxx由 Node 开发服务器转发到8080端口，浏览器端看到的请求是同源的，自然不存在跨域问题。生产环境则交给 Nginx 做反向代理，后端不需要开放 CORS。

6.3 Vue 打包后扔进 SpringBoot 的坑

很多教程会告诉你把前端npm run build之后的dist目录扔到 SpringBoot 的src/main/resources/static下，后端启动后就能用一个端口同时服务页面和接口。这样做确实可行，但有两个麻烦。

第一，hash 路由模式下的访问没问题，但如果你改了路由模式为 history，直接刷新子路由会 404。第二，前端打包时接口地址必须改成相对路径/api，不能写死http://localhost:8081，否则打包后在自己的服务器上访问时，请求会指向一个不存在的目标。

我实际跑部署时更推荐用 Nginx 分开部署：静态文件交给 Nginx，接口反向代理到后端 Java 进程。这样前后端可以独立升级，也不会被 SpringBoot 的静态资源处理拖累性能。如果你只是本地验证，用dist放进static的方式图省事是可以的，但要把代理和路径问题先处理好。

6.4 上传图片在页面上显示 404

最后说一个很多人都会踩的坑：上传图片返回了 URL，数据库里也有路径，但页面上就是显示不出来。原因几乎都出在后端的静态资源映射上。

你需要在后端配置类里确保有这个配置：

@Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/uploads/**") .addResourceHandler("file:" + uploadPath); }

注意file:后面的路径末尾要有/，而且路径要和application.yml里配置的上传路径一致。Windows 上路径用D:/xxx/这种正斜杠写法，避免转义问题。配置完成后重新启动后端，再用上传返回的 URL 在浏览器直接访问一次，能显示图片就说明链路通了。

我个人的经验是，前端代码的问题通常有日志可查，后端代码的问题通常有报错可看，唯独这种静态资源映射问题，控制台里干干净净，页面就是一片灰，最容易让人束手无策。以后遇到前端图片 404，第一反应检查资源映射配置，而不是去重写前端代码。

最后再说点我的真实体会

整套系统跑下来，这个源码最大的价值不是“功能高级”，而是“骨架干净”——它用一套最标准的 Java 后端 + Vue 前端 + MySQL 的组合，把一个典型的网站信息管理系统需要的模块完整呈现了出来。对想做毕设、课设、或者公司内网小型内容系统的人来说，这个起点非常合适。真正在实际开发里，你大概率不是从零开始写基础模块，而是从这类成熟源码上做二次扩展。比如我就在这基础上给文章模块加过标签功能，给用户模块加过部门字段，整个过程因为原项目分层清晰，改动范围控制得很小。希望这份拆解和踩坑记录能帮你少走几步弯路，把它真正变成你自己的项目。