企业官网建设流程全解析

开门见山说一句：装修公司真正需要的从来不是一个展示型官网，而是一套能把客户、设计师、施工队、预算、材料、进度全部串起来的内部管理系统。这套在线装修管理系统，就是这个定位——基于 SpringBoot 后端、Vue 前端、MySQL 数据库的前后端分离项目，代码结构规整，配置完整，导入 IDE 配好环境就能跑。我花了一下午时间把它完整跑通，又从业务逻辑层面过了一遍代码，这篇就把项目拆开讲清楚，包括它到底管理了什么、技术选型为什么是这一套、数据库怎么设计、接口权限怎么做、前端页面怎么接，以及“可直接运行”这五个字背后需要你注意哪些坑。

1. 这个项目解决的痛点：装修行业的信息断层全在这里

1.1 纸质单据和微信群撑不起一个装修项目

做过装修行业软件的人应该深有体会：一个普通家装项目，从客户咨询到最终验收，中间至少要经过量房、设计、报价、签合同、材料采购、施工交底、水电木瓦油各工种进场、节点验收、竣工保洁十几个环节。每个环节都涉及不同角色：业主要看进度，设计师要传图纸，工长要报材料计划，采购要核价格，财务要管分期款。传统做法是微信群加 Excel，信息散落在每个人的聊天记录和本地表格里，一旦某个环节出问题，想追溯责任方就得翻几个月的聊天记录。

这套在线装修管理系统把核心流程搬到了线上：业主在线提交装修需求，管理员分配设计师，设计师上传设计方案和报价单，施工阶段工长按节点更新进度并上传现场照片，业主可以对每个节点确认或提出整改意见。所有操作都有记录，状态可查询，责任边界清清楚楚。

1.2 系统里的角色和权限边界

项目采用典型的 RBAC 模型，内置了四类角色：

• 业主：查看自己的订单进度、确认设计方案、节点验收、在线评价
• 设计师：接收分配的设计任务、上传设计图纸、提交材料清单和预算
• 施工管理员：创建施工计划、更新各节点进度、上传工地照片、登记材料进场
• 系统管理员：用户管理、订单分配、全部流程监控、基础数据维护

这四类角色对应到前端就是四种不同的操作界面。权限控得不严的话，业主能打开施工管理页面，设计师能改别人的订单，那这套系统反而会制造混乱。所以我特别关注了项目里的权限设计，后面会详细拆解。

1.3 一个典型的业务闭环是什么样

以最常见的“新房装修”为例，跑一遍主流程：

1. 业主注册账号，填写房屋信息、面积、风格偏好、预算区间，提交装修申请。
2. 管理员在后台看到新申请，审核通过后分配给某个设计师。
3. 设计师上传量房图和设计方案，录入主材清单和预算报价。
4. 业主在线查看方案，满意则确认，不满意可填写修改意见退回。
5. 方案确认后，施工管理员创建施工计划，按“拆改-水电-瓦工-木工-油漆-安装-保洁”节点逐步推进。
6. 每个节点开始时更新状态，完工后上传照片，业主确认后进入下一节点。
7. 全部节点完成后，业主做竣工确认和评价。

这套流程里，状态的每一步流转都有据可查。系统管理的核心不是“记录信息”，而是“驱动流程”。

2. 技术选型拆解：为什么偏偏是 SpringBoot + Vue + MySQL

2.1 后端选 SpringBoot，图的是生态成熟和上手快

这个项目没有引入微服务、没有用 Spring Cloud，后端就一个 SpringBoot 应用，打包后是一个可直接运行的 JAR。我当时看代码第一感觉是：选型很务实。

SpringBoot 在这个场景下的优势有几个：自动配置省掉了大量 XML 配置，内嵌 Tomcat 让部署变成一条命令，Spring Security 整合 JWT 做认证授权是标准方案，生态里 MyBatis-Plus 这类增强工具又能把单表 CRUD 的效率拉满。对于一个需要快速交付、稳定运行的装修管理后台来说，这属于“稳赚不赔”的组合。

要注意的是 SpringBoot 版本。项目用的是 2.x 系列，对应 JDK 8。如果你本地装的是 JDK 17 甚至 21，跑 2.x 老项目大概率会遇到依赖兼容问题。实际启动时我先检查了pom.xml里的 SpringBoot 版本，再决定用哪个 JDK。如果是 SpringBoot 3.x，要求 JDK 17 起步。这两者的切换不算复杂，但很容易在一开始就把新人卡住。

2.2 前端选 Vue，核心是组件化和生态

前端用的是 Vue 2 + Element UI。如果按现在的时间点看，Vue 3 才是新项目的默认选择，但很多现成源码和公司内部系统仍然跑在 Vue 2 上。这套系统选 Vue 2 并不奇怪，Element UI 对应的管理后台组件丰富，表格、表单、弹窗、分页这些后台高频组件都是现成的，改改配置就能用，不需要从零手写。

Vue 的核心价值在组件化：一个装修订单的进度时间线、一个材料清单表格、一个权限控制按钮，都可以抽成独立组件。项目里的 src/views 下按角色分目录，比如 owner、designer、admin、constructor，每个页面维护自己那块业务，代码不会乱成一锅粥。

前端请求用 Axios，全局做了拦截器，请求头自动带 token，响应里遇到 401 就跳登录页。状态管理用的 Vuex，登录用户信息、权限列表这类全局数据放在 store 里，刷新页面后通过本地缓存恢复。这套模式在后台管理系统里属于标配，稳定。

2.3 数据库选 MySQL，业务数据量决定了没必要上重武器

装修管理系统的数据量级，撑死也就是几百个并发用户、几十万条订单记录，MySQL 完全扛得住。项目里 SQL 用得很规矩，核心表都建了索引，订单表关联查询基本走主键和业务外键，不会有性能瓶颈。

连接层用的是 MyBatis-Plus，这个选择很聪明。MyBatis-Plus 在我眼里是一个“写了等于没写”的 ORM：单表查询直接用selectById、selectPage这些封装好的方法，复杂的多表关联再手写 XML。项目里的用户管理、材料管理这些模块几乎全是单表 CRUD，用 MyBatis-Plus 能省掉大量重复的 Mapper XML。

2.4 为什么没有引入 Redis 和消息队列

也有人会问，都做管理系统了，为什么不加 Redis 做缓存，用 RabbitMQ 做消息推送。我的看法是：要分场景。这个项目核心操作是状态流转和记录查询，数据库压力不大，Redis 缓存带来的收益有限，反而引入额外组件会提高部署门槛。消息推送方面，项目先用招聘轮询或简单的待办提醒就能满足，不需要引入一套消息中间件。“可直接运行”的关键就是依赖越少越好，你来一个 Redis，用户还得先装 Redis，那就不叫直接运行了。

3. 数据建模思路：从 8 张核心表看懂装修业务

3.1 用户权限表：三个基础表撑起 RBAC

打开数据库脚本，最先看到的是sys_user、sys_role、sys_user_role三张表。sys_user存的是用户基本信息，包含用户名、密码（BCrypt 加密后的密文）、真实姓名、手机号、状态字段。密码绝不能用明文存储，这一点项目做得没问题。

sys_role表里预置了owner、designer、constructor、admin四种角色。sys_user_role是关联表，一个用户可以有多个角色，虽然这个项目里每个用户理论上是单一角色，但多对多的结构保留了扩展性。将来如果出现“设计施工一体”这种复合角色，不需要改表结构。

权限控制不是简单判断角色名，而是通过角色关联菜单和按钮权限。不过在这个项目里，接口层主要用角色做粗粒度控制，细粒度到按钮级别在前端通过v-permission指令实现，后端接口同样会做二次校验。防止有人绕过前端直接调接口。

3.2 业务主表：装修订单表的是一切的源头

核心业务表是decorate_order，它几乎集中了业务全流程的所有关键字段：

• 业主 ID：关联 sys_user，表明这单是谁的
• 房屋信息：所在小区、楼栋、户型、面积
• 装修需求：风格偏好、预算区间、期望开工日期
• 状态字段：待分配、设计确认、施工中、待验收、已完成、已取消
• 设计师 ID、施工管理员 ID：分配给哪个设计师，哪个工长负责
• 创建时间、更新时间

这张表的设计逻辑很清楚：所有业务动作都围绕订单展开，先有订单，才能有后续的设计、施工、进度记录。状态字段用varchar存英文枚举值，比如PENDING,DESIGN_CONFIRMED,UNDER_CONSTRUCTION,COMPLETED，比存中文更规范，也方便后端枚举类判断。

3.3 子业务表：设计、材料、进度分工明确

design_plan表存设计方案，核心字段是订单 ID、方案名称、设计说明、图纸附件 URL、预算总金额、状态（待确认/已确认/已退回）。图纸不是直接存进数据库，而是存文件的访问路径。这个项目把上传文件保存在本机磁盘目录，数据库只记录路径。如果将来要上云，换成 OSS 对象存储，只需要改文件上传的工具类，表结构不用动。

material_info表存主材清单，字段包括材料名称、规格型号、单位、数量、单价、总价、品牌、采购状态。它和设计关联，也可以独立维护。这个表最容易被忽略的一点是“数量和单价分开存”，而不是直接存一个总价。这样万一价格调整，只需要改单价，数量不变，总价自动重算。如果设计时偷懒只存总价，后面统计和变更会很痛苦。

construction_progress表是整个系统里最直观的部分。每条记录包含订单 ID、节点名称（如“水电改造”）、计划开始日期、计划完成日期、实际开始日期、实际完成日期、进度状态、施工说明、现场照片 URL。查询某个订单的进度时，按节点序号排序返回，前端渲染成时间线。这里有个细节：状态不是简单的“完成/未完成”，而是细分了“待开始、进行中、待业主确认、已完成”。业主确认之后才推进到下一节点，这就是流程管控的意义。

3.4 数据字典与状态流转设计

项目里用一张sys_dict表维护数据字典，比如房屋类型、风格枚举、节点名称、材料分类。数据字典的好处是，页面上要加一个选项不用改代码和表结构，往字典表插一条记录就行。

状态流转是这类系统的核心逻辑。以装修订单为例：

• 待分配 → 设计确认 → 施工中 → 待验收 → 已完成
• 设计确认阶段可以退回到待分配
• 施工过程中任何节点被业主否决，订单不会回退到初始状态，只是当前节点状态变为“需整改”

状态流最好在后端用枚举类做统一约束，而不是在前端随意跳转。这个项目的 Controller 层有多个状态判断，Service 层也有相应的校验。我实际测试过，如果前端绕过按钮直接用 POST 请求把订单状态改成已完成，后端会返回“状态流转非法”的错误，安全防护是真实的。

4. 后端接口与权限设计：JWT 登录和 RBAC 到底怎么落地

4.1 认证流程：一次 POST 请求换一个 token

系统登录接口是/api/auth/login，请求体是用户名和密码。后端校验通过后，用 JWT 生成一个 token 返回给前端。前端把 token 存在 localStorage，之后每次请求在请求头里加Authorization: Bearer <token>。

JWT 的核心是“无状态”：服务器不保存会话信息，用户身份就编码在 token 里。后端需要一个拦截器或过滤器在每次请求时解析 token，验证签名，取出用户 ID 和角色信息。Spring Security 里通过自定义OncePerRequestFilter实现，把解析出的用户信息放到SecurityContextHolder里供后续使用。

具体流程我也在本地断点跟过一遍，JwtAuthenticationFilter先判断请求头有没有 token，没有就直接放行让 Spring Security 的匿名过滤器处理；有 token 则解析，如果 token 有效则加载用户信息和权限列表，然后构造UsernamePasswordAuthenticationToken放进上下文。这套逻辑是所有 Spring Security + JWT 项目的标准范式，可以用到其他任何后台系统上。

4.2 接口权限：方法级别注解控制角色访问

在 Controller 层，项目用@PreAuthorize("hasAnyRole('ADMIN','DESIGNER')")这类注解做接口权限控制。比如创建设计方案接口只允许设计师和管理员访问，确认设计方案接口只允许业主和管理员访问，更新施工进度接口只允许施工管理员和管理员访问。

这里有一个很多新手容易踩的坑：hasRole默认会对角色名自动加ROLE_前缀。如果数据库里角色标识是ADMIN，注解里要写hasRole('ADMIN')，但 Spring Security 在底层比较的是ROLE_ADMIN。如果配置权限时忘了这个前缀，明明有权限也会返回 403。

我翻了项目代码，它在实现UserDetails时已经把角色名统一加了ROLE_前缀，所以权限注解能正常工作。这个细节看似不起眼，实际排查 403 时能让新手卡好几个小时。

4.3 核心接口拆解：设计确认和施工进度更新的逻辑

以“业主确认设计方案”为例，接口路径类似POST /api/design/{id}/confirm。后端逻辑分四步：

1. 根据方案 ID 查方案，判断方案是否存在。
2. 判断方案归属的订单是否属于当前登录业主。
3. 判断方案状态是否为“待确认”，如果不是则抛业务异常。
4. 更新方案状态为“已确认”，同时把关联订单状态从“设计确认”更新为“待施工”。

从代码里能看出设计者把业务校验写得很克制，没有把一堆 if 塞在 Controller 里，而是抽了一个DesignPlanService处理核心逻辑，Controller 只负责接收参数和返回统一响应。这就引出一个项目里很值得学习的点：统一返回体Result<T>，包含 code、message、data 三个字段，前端 Axios 响应拦截器里判断 code 是否为 200。这样一来，后端无论返回正常数据还是业务异常，整体结构都是一致的。

施工进度更新的接口要考虑的东西更多。每次更新不仅是改一条进度记录，还要校验当前施工节点是否轮到它。比如“瓦工”节点还没开始，“油漆”节点不能直接标完成。代码里维护了一个节点顺序表，用sort_order字段排序，更新时检查前一个节点是否已完成。这种串行校验的写法值得记下来，很多流程类系统的核心难点就在这。

4.4 统一异常处理和参数校验

项目里的全局异常处理使用@RestControllerAdvice，捕获三类异常：业务异常（自定义BusinessException）、参数校验异常、系统级异常。返回格式统一是{code: 500, message: "xxx", data: null}。前端拿到非 200 的 code 直接弹 message，不需要逐个接口处理错误。

参数校验用@Validated+@NotBlank、@NotNull这些注解，DTO 字段上做声明式校验。比如创建订单时，房屋面积必须大于 0，手机号必须符合正则。这样做的好处是 Controller 层不会堆一堆手写的 if 判断，代码一眼扫过去就知道哪些字段必填。

5. Vue 前端怎么承接业务：路由、状态管理和页面交互

5.1 目录结构：按业务角色分的 view，不按组件类型分

前端的src/views下不是常见的src/views/system、src/views/order这类按模块分，而是按角色分。打开项目能看到owner、designer、constructor、admin四个目录。对于这个特定项目来说，按角色分目录反而更清晰，因为每个角色看到的页面集合差异很大，不同角色之间几乎没有共用页面。

公共组件放在src/components里，比如订单状态标签、图片上传组件、进度时间线组件。公共 API 请求统一放在src/api下，按业务模块拆文件，比如order.js、design.js、progress.js。一个页面里不要直接写 axios，统一走封装的request.js，方便维护。

5.2 路由守卫和动态侧边栏

前端登录后，根据用户角色动态生成可访问的菜单。这一步不是简单地在前端router.beforeEach里判断角色然后跳转，而是后端登录接口返回用户信息时带上角色和菜单权限列表，前端把菜单列表存到 Vuex，动态渲染侧边栏。

路由守卫的逻辑是：

1. 判断本地有没有 token，没有就跳转/login。
2. 有 token 但本地没有用户信息，调/api/auth/info拉取用户详情和权限。
3. 根据权限判断当前路由是否可访问，无权访问跳 403 页面。

这里有个很容易忽略的问题：刷新页面后 Vuex 数据会丢失，所以用户信息必须同步持久化到 localStorage，刷新后再从本地恢复，而不是刷新后每次都重新登录。项目里在这块做了兼容，刷新后先读 localStorage 恢复用户信息，再发一次请求验证 token 是否有效。

5.3 Vuex 状态管理里放了什么

项目状态管理只放了三类全局数据：用户信息、菜单权限、订单缓存。

用户信息包括用户 ID、用户名、角色列表，页面渲染时经常要判断当前角色决定显示哪些按钮。菜单权限决定了侧边栏的渲染结果。订单缓存主要用于业主端“我提交的订单”列表，因为订单查询接口相对较重，切换页面时不希望频繁重新请求。

Vuex 的模块划分是标准的modules方式：user.js、app.js、order.js，每个模块有独立的 state、mutations、actions。典型用法是在 action 里调用 API，拿到数据后 commit mutation 更新 state。这套写法虽然比直接ref定义一个响应式对象繁琐，但胜在数据变更可追踪，适合管理后台这种需要多人协作维护的项目。

5.4 关键页面交互怎么实现的

业主端最重要的页面是“装修进度详情页”。页面顶部是订单基本信息卡片，中间是步骤条，展示整个装修生命周期：提交申请、设计确认、施工中、竣工验收。下面是大时间线，每个施工节点对应一条记录，包含节点名称、计划时间、实际时间、施工说明、现场照片。时间线组件通过v-for循环渲染construction_progress列表，根据状态打上不同颜色的标签。

设计师端最核心的页面是“上传设计方案”。表单里除了填写方案名称和设计说明，还要上传图纸文件。项目里的上传组件封装了el-upload，批量上传后把返回的文件 URL 拼成数组，提交表单时一并传给后端。具体到el-upload的坑是：它默认用 AJAX 上传，需要设置action属性为后端接口，同时通过headers带上 token。如果不带 token，上传接口会被 401 拦截，但提示很隐晦，经常让人以为是文件格式问题。

管理员端最亮眼的是首页的统计看板，用 ECharts 展示本月新增订单数、各状态订单分布、各设计师在手订单数。这些数据来自后端的/api/dashboard/stats聚合接口，一次请求返回多个统计数据，前端拆开渲染。这种一个页面只要一个接口的做法能减少请求次数，也方便维护。

5.5 前端样式复用和自定义主题

Element UI 自带一套蓝色主题，项目里用 SCSS 变量覆盖了主色，改成偏绿色的装修行业风格。这个改动在styles/variables.scss里，改$--color-primary即可。如果你拿到源码想换品牌色，这是最快的方式，不用去每个组件里调样式。

6. “可直接运行”背后的启动流程和踩坑实录

6.1 本地跑起来需要准备什么

我把“可直接运行”理解为：代码下载后，只要你的电脑装了 JDK、Maven、Node.js、MySQL，按文档步骤操作就能跑。实际启动需要的环境是：

后端项目是标准的 Maven 结构，pom.xml集中在根目录，直接用 IDEA 打开等待依赖下载完成就行。前端是独立的vue目录，需要单独npm install。

6.2 数据库初始化的正确姿势

项目根目录一般会带sql文件夹，里面是init.sql或decoration.sql。这个初始化脚本建库建表，同时插入初始管理员账号和字典数据。我在 MySQL 8.0 里执行时遇到一个坑：脚本里如果有中文注释或数据，需要保证 MySQL 客户端的字符集是 utf8mb4，否则中文内容会变成乱码。

推荐用命令行执行：

mysql -u root -p < sql/init.sql

如果 MySQL 8.0 默认认证插件是caching_sha2_password，而项目里数据库驱动是mysql-connector-java5.x 版本，连接时会报Unable to load authentication plugin 'caching_sha2_password'。解决办法有两个：一是换用 8.x 的驱动，二是把数据库用户改成mysql_native_password。项目里如果用的是 MySQL 5.7，则不会有这个问题。

6.3 后端配置修改的三个地方

打开application.yml，重点看三块配置：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/decoration?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: root redis: # 项目未强制依赖 Redis，这里的配置一般可忽略

第一是端口号，默认 8080，如果被占用要改。第二是数据库连接地址，必须改成你本地 MySQL 的账号密码。第三是时区，MySQL 8.0 驱动要求带serverTimezone，否则会报时区错误。这里有个典型的启动报错：The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized，看到这个基本就是缺少 serverTimezone 参数。

JWT 密钥一般在application.yml里的自定义配置段，比如jwt.secret。默认值是一个随机字符串，生产环境必须改掉，否则 token 可以被逆向伪造。这个项目里把密钥直接写在配置文件中，开发没问题，上生产前一定要改成环境变量注入。

6.4 前端启动步骤和跨域处理

前端启动流程：

cd vue npm install npm run dev

默认开发服务器跑在http://localhost:9528，通过 Vite 或 Webpack 的代理把/api转发到后端 8080。代理在vue.config.js里配置：

module.exports = { devServer: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } };

如果不用代理直接用 axios 调http://localhost:8080/api，会因为跨域被浏览器拦截，就算后端配置了@CrossOrigin，一开始也会踩坑。所以我建议开发环境始终走代理，前端代码里用相对路径/api，这样部署时只要把前端的/api请求反向代理到后端服务即可。

6.5 我实际遇到的几个报错和排查思路

报错一：Port 8080 was already in use.

后端启动失败，原因是 8080 被占用。排查步骤：netstat -ano | findstr 8080查看 PID，如果是无用进程直接杀掉，或者改application.yml里的端口号，同时记得同步修改前端代理目标地址。

报错二：java.sql.SQLException: Access denied for user 'root'@'localhost'

数据库账号密码不对，不是代码问题。检查application.yml里的 username 和 password 是否和本地 MySQL 一致。新人最容易在这里卡住，因为默认密码可能不是 root。

报错三：npm ERR! code ELIFECYCLE

前端启动失败，通常不是 because 代码问题，而是 Node.js 版本太高，项目依赖里某个包编译不过。Vue 2 + Element UI 的老项目，Node 14/16 最稳。我用 Node 18 试过，node-sass编译报错，后来卸载重装 Node 16 就好了。如果你不想切 Node 版本，可以考虑把node-sass换成sass，不过这会牵扯到兼容性调整，不推荐新手折腾。

报错四：请求接口 404

如果登录页能出来但登录请求 404，先确认后端是否启动成功，再看前端代理是否生效。打开浏览器开发者工具，看网络请求实际访问的 URL。如果请求地址是http://localhost:8080/api/auth/login，说明代理没起效；如果是http://localhost:9528/api/auth/login且代理配置正确，那就是代理转发问题。

7. 从“能跑”到“好用”：这套源码的扩展空间和个人体会

7.1 消息通知和工作流可以补上

当前项目在“待办提醒”上只做了站内消息表，没有前台主动推送。实际运营中，设计师提交方案后业主并不知道，必须自己点进去看。这里有两个轻量改进思路：一是前端加一个定时轮询，每 30 秒调一次消息接口；二是引入 WebSocket，后端在状态变更时主动推送。不用上消息队列，单机 WebSocket 完全够用。如果订单量再大，再考虑引入 Redis 发布订阅。

7.2 文件存储本地化终究是过渡方案

项目里的图纸和工地照片存在本机磁盘，这在单机部署下没问题，但多台服务器或容器化部署时文件就不同步了。建议改成 OSS/MinIO 的对象存储：后端封装一个FileStorageService接口，本地实现和 OSS 实现切换即可。数据库里已经存的是 URL 路径，换存储方案不影响前端页面。

7.3 订单状态机值得独立成一个模块

当前状态流转分散在 Service 里，虽然逻辑正确，但状态越来越多时不好维护。更优雅的做法是用状态机模式，定义每个状态允许的事件和下一个状态。比如“施工中”状态下，只有所有子节点都已完成才能触发“待验收”。这样把校验规则集中到一处，加新状态时不会影响原有流程。

7.4 关于这套源码本身，我的结论是

我见过太多号称“可直接运行”的项目，实际下载后要么缺配置文件，要么依赖版本不兼容，要么数据库脚本缺失。这套装修管理系统在完整性上做得很到位：数据库脚本、后端配置、前端代理、默认账号一应俱全，只要环境匹配，从下载到看到登录页大约只需要半小时。对于正在做毕业设计、想快速搭一套后台管理系统、或者准备接装修行业软件外包的人来说，它的参考价值都不低。

项目里最有学习价值的部分不是页面多炫，而是“状态流转”和“权限控制”这两个点。看懂了订单状态怎么一步步推进，你就理解了大部分业务系统是怎么把现实流程搬到线上的。如果想拿这套代码作为基础二次开发，建议先花一天时间把每张表的字段过一遍，再从前端一个页面点击后追踪到后端接口和数据表的完整链路。把这条链路跑通，这个项目你就真正吃透了。