企业官网建设流程全解析

搞毕设的时候，我看到很多同学在选题阶段就把方向定成了“基于Spring Boot+Vue的在线商场后台管理系统”，光是这个组合的标题我们学校一届就能出七八个。说白了，这个题目的生命力在于技术栈经典、业务场景成熟、开发量适中，既有后端建模和权限控制的干货，又有前端组件化和联调的实操空间，最重要的是——它足够落地，不会让你做到一半发现做不出来。

我自己的项目也是从这个方向起步的。当时从拿到题目到最终交源码、论文（就是标题里那个lw）、部署文档和讲解视频，前后花了差不多三周。这篇文章就把我做这个项目的完整思路、核心实现、踩过的坑、以及最后怎么把材料打包成交付级水准的经验全部分享出来。如果你是正在选型或者已经确定这个题目的同学，这篇内容可以帮你少走一大截弯路。

1. 需求拆解与技术选型：这个项目为什么能成为经典毕设

1.1 选题之前先想清楚：这道题到底在考什么

很多同学拿到“在线商城后台管理系统”这个题目后，第一反应是“商城不就是商品列表加购物车吗”。如果真这么想，做出来的东西大概率会被导师打回。你要先想明白，一个叫“在线商城后台管理系统”的项目，考察的核心其实是三件事。

第一件是后台管理的业务闭环。它不是一个用户下单的前台商城，而是一个运营人员使用的管理端。这意味着你主要处理的是商品管理、分类管理、订单管理、用户管理、轮播图配置、库存和上下架状态这些运营动作。关键词是“管理”，不是“浏览”。

第二件是权限控制。管理后台天然带角色划分，比如超级管理员、商品运营、订单专员。不同角色能看到的菜单不同，操作权限也不同。这一块是导师最常追问的点，也是论文里最能写深的地方。

第三件是前后端分离的实现方式。Spring Boot 提供 RESTful API，Vue 负责页面渲染和交互。两者之间通过 JSON 通信，你需要处理跨域、鉴权、异常统一封装、路由守卫这些前后端分离下的典型问题。

把这个逻辑想清楚了，你就能明白为什么这题目经久不衰——业务清晰但不过度复杂，技术栈主流且考察点集中，非常适合用来检验一个学生是否完整掌握了 Java Web 全栈开发的基本功。

1.2 版本选型：不用最新，但要用稳定搭配

版本选择我建议直接照搬一套经过社区验证、资料最多的组合。我当时用的搭配如下表所示，这个组合在部署时几乎不会遇到版本层面的奇葩问题：

这里多说一句关于 Vue 版本的选择。虽然 Vue 3 是趋势，但我在实际做项目时发现，Element UI 对 Vue 2 的支持成熟度远高于 Element Plus 对 Vue 3 的支持——尤其你用到表格、树形控件、动态表单这类组件时，网上能搜到的现成解决方案绝大多数是基于 Vue 2 写的。做毕设追求的是快速交付和低风险，不需要在版本前沿性上冒险。

2. 数据库建模与后端核心链路：先把地基打扎实

2.1 从需求反推表结构，一张图看清业务关系

后台管理系统的表设计一定要围绕业务角色来展开。我最终交付的表结构一共有 9 张核心表，分成四个层次：

• 用户与权限层：用户表、角色表、菜单表、用户角色关联表、角色菜单关联表，这 5 张表构成了 RBAC 权限模型的基础。
• 商品层：商品分类表、商品信息表。商品挂在分类下面，一对多关系。
• 订单层：订单表、订单明细表。订单明细冗余了商品快照信息，这样即使商品后来下架或改名，历史订单依然能查到当时购买的商品名称和价格。
• 运营层：轮播图表。这个是后台管理首页的配置项，属于锦上添花的模块，但能体现你对业务细节的考虑。

具体到建表的关键字段，比如商品表，最核心的字段我建议至少包含：商品名称、商品主图、商品价格、库存、销量、上下架状态、分类ID、商品简介。 价格字段一定要用 decimal(10,2)，千万别用 float 或 double，否则后面算金额会出现小数点精度问题。我在刚开始设计表时图省事用了 double，结果订单金额出现 19.99 存成 20.000000001 的情况，查了半天才发现是字段类型埋的雷。

订单表则要单独拎出来说。订单号建议用时间戳加随机数生成，不要用数据库自增ID做主键暴露给前端。订单状态字段用 tinyint 存储，同时用状态码常量类管理，比如 0 待付款、1 待发货、2 待收货、3 已完成、4 已取消。这样代码里到处都是魔法数字的问题也能顺手解决掉。

2.2 RBAC 权限模型：数据库层怎么设计才算严谨

在线商城后台管理系统的权限模型，是导师最爱的提问点，也是论文里必写的技术难点。RBAC（基于角色的访问控制）的核心理念非常直白：权限不直接挂在用户身上，而是先挂在角色上，再把角色分配给用户。

具体到实现，我把菜单表设计成自关联结构，通过 parent_id 字段表示父子层级，正好对应用户登录后左侧菜单的嵌套展示逻辑。菜单分为目录和按钮两种类型，目录决定你能看到哪些页面，按钮决定你能在页面上看到哪些操作按钮。这里有个容易被忽略的点：很多人只做了菜单权限，没有做按钮权限，导致不同角色进了同一个页面，看到的功能完全一样。我的做法是后端在返回用户信息时，连同当前用户所有权限标识（比如“product:add”“order:delete”）一并返回，前端根据这个标识集合用 v-if 控制按钮显示，同时后端在接口层再做一次权限拦截。前端控制的是体验，后端控制的是安全，两层缺一不可。

以下是我项目中用到的核心用户表结构示例：

CREATE TABLE t_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL, nickname VARCHAR(50), email VARCHAR(100), avatar VARCHAR(255), status TINYINT DEFAULT 1 COMMENT '1启用 0禁用', create_time DATETIME DEFAULT CURRENT_TIMESTAMP );

密码字段我这里用了 BCrypt 加密存储，绝对没有人会直接在 controller 里接收明文密码然后往数据库里塞。现成的 spring-security-crypto 包里有现成的 BCryptPasswordEncoder，不需要引入整套 Spring Security，也能获得可靠的加密能力。

2.3 JWT 鉴权 + 拦截器：保证每个接口都是安全的

后台系统的所有接口，除了登录接口外，其余都应该校验用户身份和权限。我用的是 JWT 加拦截器的方案，整体思路简单可靠。

用户登录成功后，后端生成一个 token，里面包含了用户ID、用户名、角色编码等信息，并设置了 24 小时的过期时间。前端拿到 token 后存储在 localStorage 里，每次请求在 axios 拦截器中把 token 放进请求头的 Authorization 字段。后端写一个拦截器，在请求进入 controller 之前先校验 token 是否存在、是否有效。

拦截器里还有一个细节值得分享——token 过期和用户被禁用的情况要分开处理。我只在拦截器里做 token 的合法性校验，用户是否仍然有效则在需要查询用户信息的业务场景中校验。这样拦截器的职责保持单一，不会出现“token 有效但用户已被禁用，依然能访问接口”的漏洞。

权限拦截我则没有全部依赖拦截器去写死，而是采用自定义注解的方式。定义一个@RequirePermission("product:add")注解，在需要权限控制的接口方法上标注，再由一个 AOP 切面统一校验当前用户是否拥有该权限码。这样代码非常整洁，控制器里看不到任何权限判断逻辑，所有校验都集中在一个切面里。这个设计如果写进论文，会成为答辩时一个很大的加分点。

2.4 商品与订单模块的接口设计：常规 CRUD 之外的坑

商品模块除了基础的增删改查，要注意的是列表接口一般都要带条件查询和分页。条件包含商品名称模糊搜索、分类筛选、上下架状态筛选。分页我直接用 MyBatis Plus 的 Page 对象，接收 current（页码）和 size（每页条数）两个参数，返回的结果统一封装为 PageResult 结构，前端表格组件可以直接绑定。

订单模块比商品模块费心思一点，因为订单涉及状态流转变更。我的建议是设计一个统一的订单状态更新入口，通过状态机思想控制流转合法性。举个例子，已取消的订单不允许再变成待发货，已完成订单不允许往回改成待收货。后端在更新状态前先查一次当前状态，做一次合法性校验。虽然多了一次数据库查询，但能避免很多脏数据问题。

所有接口的返回结构我统一封装为{ code: 200, message: 操作成功, data: ... }。 前端在 axios 响应拦截器里统一判断 code 是否为 200，不是则弹出错误消息并 reject。错误码的语义要清晰，200 成功、400 参数错误、401 未登录或token失效、403 无权限。这样前后端联调时，只看返回码就能定位绝大多数问题。

3. 前端管理后台落地：从路由表到页面的完整实现思路

3.1 为什么选了 Vue 2 + Element UI 的管理端方案

后端接口设计完成后，前端开发的关键就是搭出一套符合后台管理系统使用习惯的页面框架。管理后台的前端本质上就是三件事：布局、表格、表单。

布局用 Element UI 的el-container实现，左侧菜单、顶部导航、中间内容区三段式。这个模式管理类系统基本通用，用户学习成本低，也最不容易出视觉上的问题。

表格用el-table，配合el-pagination做分页。表单用el-form配合校验规则。剩下就是大量重复但必要的页面代码——每个管理模块一个页面，内部结构高度相似。很多同学觉得这种工作枯燥，但说实话，正是这种重复劳动让我把 Vue 的组件通信、表单校验、表格数据回显这些基本功练得比较扎实。

3.2 动态路由实现：不同角色登录后看到不同菜单

动态路由是后台管理系统中一个非常核心的前端难点，它的意义在于：后台返回的菜单数据决定前端生成哪些路由，而不是所有路由都写死在代码里。

具体实现分为三步：

1. 用户登录后，调用/user/info接口获取当前用户信息，包括用户基本信息、角色标识、按钮权限集合、以及菜单列表。
2. 前端根据菜单列表递归生成 Element UI 的侧边栏菜单结构。
3. 用router.addRoutes方法动态注册路由。前端在路由表中只保留固定的 login、首页、404 三个路由，其余路由全部动态挂载。

这里我踩过一个很典型的坑：页面刷新后动态路由会消失，因为存储在 Vuex 里的状态被清空了。解决方式是刷新时重新请求用户信息，再重新生成路由。我当时的方案是在路由守卫beforeEach中判断 Vuex 中是否存在用户信息，如果不存在就重新拉取并动态注册路由，注册完成后调用next({ ...to, replace: true })重新进入目标路由，确保动态路由生效。

3.3 axios 封装与前端鉴权拦截器配置

前端所有请求都通过一个统一封装的 request 模块发出。请求拦截器统一携带 token，响应拦截器统一处理结果。下面是我当时封装的响应拦截器核心代码：

service.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { this.$message.error(res.message || '请求失败') if (res.code === 401) { location.href = '/login' } return Promise.reject(new Error(res.message)) } return res }, error => { this.$message.error(error.message || '网络异常') return Promise.reject(error) } )

这段代码逻辑很简单，却解决了整个项目中最容易出问题的一环——错误信息的统一处理。如果没有这层拦截，每个页面都要自己写错误判断，代码重复量惊人，而且容易漏掉 401 跳转登录页的逻辑。

路由守卫方面，我在main.js的全局前置钩子里判断了用户是否已登录，未登录则重定向到登录页；已登录但访问登录页时则重定向到首页。另外，针对按钮级权限，我实现了一个v-hasPermi自定义指令，用法是v-hasPermi="['product:add']"，当前用户没有对应权限码时自动删除该 DOM 元素。这样按钮权限的收敛就变得非常优雅，页面代码里基本看不到权限判断的逻辑。

4. 部署文档、论文和讲解视频：把项目包装成“交付级”

4.1 环境部署文档：别让导师在你的项目上卡在启动环节

很多同学的毕设死在最后一个环节——环境部署。代码写得再好，导师拿到手跑不起来，印象分直接腰斩。部署文档的重要性怎么强调都不为过。

我的部署文档写了 11 页，从 JDK 环境变量配置、MySQL 建库建表、Redis 启动验证、Maven 打包命令、前端编译命令，到最终访问地址和默认账号，全部按步骤截图说明。这里有几个关键点：

• 数据库脚本要包含建库和建表，并且插入必要的初始数据，包括默认管理员账号。默认密码我设为admin123，并在文档里明确写出。
• 前后端端口配置写清楚：nginx 监听 80 端口，代理到 Vue 前端，前端请求动态转发到后端 8080 端口。
• 文档中每一步之前先写预期结果，比如“执行这一步后，控制台输出 Started XxxApplication，表示后端启动成功”，方便导师确认这一步是否执行到位。

另外尤其要注意，我用的 MySQL 8.0 版本，需要显式配置serverTimezone=Asia/Shanghai时区参数，否则数据库连接会直接报时区错误，这个坑非常经典。

4.2 代码注释与源码结构：阅卷人第一眼看重什么

交源码这件事，很多同学的理解是“代码能跑就行”。这是一个大误区。导师看源码第一眼不会看逻辑，而是看结构。

我的源码目录结构做了明确的分包：controller、service、mapper、entity、config、common、utils。 其中common放统一返回结果类和异常处理类，config放跨域配置、拦截器注册配置。这个结构一眼就能让人看出你熟悉企业级项目的分层思想。

注释方面，关键业务方法我写了两层注释：第一层说明方法功能，第二层说明核心业务逻辑的流转。但我也没做那种逐行注释的冗余操作，因为那反而会让代码显得很外行。比如订单状态更新方法，我写的是“更新订单状态，前置校验当前状态是否允许流转到目标状态”，这就够了。

4.3 讲解视频的准备思路：8 分钟讲清楚别人看不见的设计决策

讲解视频（很多学校要求提供演示讲解）要控制时长，8 分钟到 12 分钟比较合理。我的录制思路是按“项目介绍 → 核心功能演示 → 代码亮点讲解”三步走。

功能演示环节不要追求把所有页面都点一遍，要挑三个最有代表性的场景：一个是多角色登录看到的菜单差异，二是商品列表的分页与条件查询，三是订单状态流转的完整流程。这三个场景分别对应权限、CRUD、状态管理三大技术要点。

代码亮点讲解环节更关键，我要重点讲五分钟内讲不清但实际很重要的内容。我最终选了 JWT 拦截器逻辑和动态路由实现这两块。讲的时候不要读代码，而是用“这里我为什么要这么写”的角度展开，把设计思考讲出来。录制的几段视频我都是边操作边说话，这样比后期配音自然得多。

4.4 论文（lw）的章节编排：怎么把项目过程写成一篇及格的论文

论文方面的经验，核心原则是“技术选型有对比，设计实现有图，测试结果有数据”。我的论文大纲大致分六章：

• 第一章绪论，写项目背景和意义，重点描述线上商城管理效率低下的痛点。
• 第二章关键技术介绍，写 Spring Boot、Vue、MyBatis Plus、JWT 四块，每个技术都要写“为什么选择它”。
• 第三章系统分析，写可行性分析、功能需求分析、用例图。
• 第四章系统设计，写总体架构图、功能模块设计、数据库表设计（E-R 图和表结构说明）。
• 第五章系统实现，按模块展示核心代码截图并配实现说明。
• 第六章系统测试，写功能测试用例表，列出测试步骤、预期结果、实际结果，全部打勾通过。

这里有一个拿高分的细节：功能测试用例表至少要有 12 条以上，覆盖正常流程和异常流程。比如“新增商品时商品名称为空，点击提交，系统提示校验错误”这类边界用例，能体现你确实考虑过异常场景，而不仅仅是跑通了主流程。

5. 开发过程中的高频坑：这些错误你很可能也会踩

5.1 跨域问题：前后端分离第一个拦路虎

前端在 8080 端口，后端在 9090 端口，第一次联调必报跨域错误。控制台报错信息是 “CORS policy: No 'Access-Control-Allow-Origin' header”，我最早遇到时一脸懵，后来真正把它研究明白后才知道，跨域不是前端能单方面解决的，需要后端配合开启跨域支持。

我在后端写了一个CorsConfig，实现了WebMvcConfigurer接口，重写addCorsMappings方法，允许所有来源访问后端接口，允许所有请求方法，允许携带凭证。开发环境下这样配置没问题，生产环境如果前端后端同域部署，则可以不用开启。这个逻辑在答辩时也经常被问到，最好能讲清楚“为什么开发时要开、生产时为什么可以不开”。

5.2 静态资源配置：上传的商品图片无法访问

上传图片功能是后台管理系统很常见的一个需求。我在实现时遇到的问题是：通过后台上传的图片文件保存到了服务器本地磁盘，但当图片路径拼接到前端访问时，出现了 404 错误。

排查后发现原因是 Spring Boot 默认不会把本地磁盘路径映射为静态资源路径。处理方式是在配置类中新增一个资源映射器：把/uploads/**路径映射到本地磁盘的实际上传目录。这样图片链接就能正常访问了。这个点虽然小，但属于实际开发中必然会遇到的资源处理问题，导师问到时能答得上来会显得经验很足。

5.3 数据库时间字段的时区问题

订单创建时间在数据库里存的正确，但实体类属性取出来后发现时间少了 8 个小时。这是非常经典的时区问题。解决方案是在数据库连接 URL 上加上serverTimezone=Asia/Shanghai，同时在 Jackson 的配置中设置日期格式化模式。

我用的日期类型全部是LocalDateTime，配合 MyBatis Plus 的自动填充字段功能，在插入数据时统一填充create_time，这样代码里基本看不到手动设置当前时间的代码，非常方便。

5.4 路由守卫死循环：跳转逻辑里埋的隐形炸弹

动态路由和路由守卫配合时，最容易出死循环问题。我的场景是：用户登录后刷新页面，路由守卫发现 Vuex 没有用户信息，于是请求后端重新获取，然后调用addRoutes动态注册路由，再重定向到目标路由。这一通操作里如果next()和redirect处理不好，就会陷入“未登录 → 跳转登录页 → 登录页配置了无条件重定向到首页 → 跳转首页时又校验未通过”的死循环。

解决方式是使用NProgress配合一个标记变量来控制，判断当前路由是否在whiteList白名单中（比如 login 和 404），在白名单中就直接放行。另外在重定向到登录页时，显式判断目标路由是否等于当前路由，相等则直接next()终止循环。

6. 交付前最后再检查这三件事

源码能跑通、文档写完，不意味着可以交付了。我在最终提交前有一个检查清单，每次做毕设都按这个标准过一遍。

第一件事是验证全流程可复现。我会在完全干净的环境里（重装系统后的虚拟机）严格按照部署文档从头到尾来一遍，从安装 JDK 到启动项目再到登录页面。这个过程能发现文档中遗漏的步骤，也能发现代码依赖中漏配置的环境变量。我在实际验证中就曾发现文档里忘写了 MySQL 要设置lower_case_table_names=1这一步，因为 Linux 环境默认表名区分大小写，而我的建表语句混用了大小写。

第二件事是数据初始化完备性。系统交付的初始数据应该包含一个完整的演示数据闭环：管理员账号、测试用的角色、至少两个不同权限的测试账号、分类数据、10 条以上商品数据、几条不同状态的订单数据。这样导师拿到手一登录，看到的不再是一个空荡荡的系统，而是可以直接上手操作的有真实感的现场。

第三件事是代码仓库的整理。我会把整个项目目录完整导出一份，排除掉 node_modules、target 这类编译产物目录，保留完整源码、数据库脚本、README 文件、部署文档和讲解视频。README 里写清楚项目简介、技术栈、启动方式、默认账号，这样任何人拿到压缩包后都能快速了解项目全貌。

折腾完这一整套，你会发现做这个项目的收获远不止拿到一个毕设成绩。前后端分离中的接口约定、鉴权流程、异常处理规范、主子模块的设计拆分，这些都是日后真正进入开发岗位后每天都要打交道的日常。尤其Spring Boot + Vue这套组合，你在网上随便搜岗位要求，Java后端开发十有八九要求熟悉它。即便你毕业之后不打算做Java方向，这套从需求到交付的完整闭环经验，放到任何一个开发岗位上都是通用的。

最后分享一个做这类项目时很实用的思维：不要把它当成一个作业，而是当成一个真实要上线的产品来做。从用户角色区分到异常场景覆盖，从部署文档的截图精度到代码注释的阅读体验，你投入的每一分额外精力，都会在答辩时变成导师眼中的亮点。务实的做法是，先跑通主流程，再迭代完善细节——记住，一个功能完整、文档齐全、能稳定运行的商城后台，远比一个功能堆砌但频频报错的项目更有价值。