尧图网站建设 
简介这是一套面向计算机专业毕业设计、课程设计及期末大作业的 Spring Boot 在线装修管理系统完整项目包。系统基于 Spring Boot 轻量级框架整合数据库技术覆盖用户管理、装修项目管理、预算管理、材料管理、进度跟踪等核心模块适用于需要完整前后台业务闭环的装修管理场景。资源共 3 个文件整体 36.2MB包含 SQL 数据库脚本用于初始化项目表结构与示例数据、RAR 源码压缩包含可导入 IDE 的工程代码与配置以及 DOC 论文文档系统阐述需求分析、系统设计、功能实现与测试结果。论文部分既提供理论框架又给出实际开发中的应用案例便于学习者对照源码理解实现思路。目前已有 123 人学习浏览适合希望系统掌握 Spring Boot 开发流程、并直接参考或扩展完成毕业设计的读者。1. 在线装修管理系统毕业设计里最典型的SpringBoot业务流题目“SpringBoot在线装修管理系统”是毕业设计和课程设计里出现频率最高的一类题目。它表面上是一个普通的管理系统但拆开看它同时包含多角色权限、业务状态流转、文件上传、数据库设计、报表统计等多个模块恰好覆盖了SpringBoot开发的大部分核心技能点。很多人在做这类项目时最大的障碍不是代码写不出来而是不知道“装修”这件事本身该拆成哪些对象、哪些状态、谁在什么角色下能操作什么。这篇内容把从领域建模、工程实现到数据库表设计、论文写作的完整路径讲清楚。适合正在做类似题目的同学也适合负责带毕设的工程师做参考。2. 需求分析与领域模型先把装修业务拆成可落地的对象2.1 在线装修系统的六种实体角色与权限矩阵在线装修管理系统不是简单的“业主查案例、管理员发文章”。把实际业务捋一遍系统至少要覆盖四种角色业主、设计师、工长、系统管理员。有的题目还会加“前台访客”和“客服”但在核心设计里前两种就已经把权限复杂度撑起来了。角色核心操作能看的页面业主浏览案例、提交量房申请、确认报价、跟踪施工节点、验收案例列表、我的项目、验收单设计师接单、上传设计方案、生成预算清单、提交报价待接单项目、方案管理、预算明细工长维护施工节点进度、上传现场照片进行中的项目、节点管理管理员用户管理、案例审核、全部项目查询、数据统计后台管理端在设计权限时不要用一张 user 表的 role 字段做硬编码判断。常见做法是拆出user、role两张表用 user_role 关联。这样以后加“监理”或“材料商”角色时只需要加一条角色记录和对应的菜单权限不用改代码里的 if-else 逻辑。权限判断建议写在 SpringMVC 拦截器里用注解标记接口需要的角色码。2.1.1 领域模型的实体关系雏形核心实体至少包括用户、角色、装修案例、量房申请、项目、施工节点、预算明细、验收单。装修项目的业务逻辑基本围绕“业主提交意愿 — 设计师跟进 — 工长施工 — 双方验收”这条主链展开而前端展示围绕案例和节点进度展开。如果把“报价”和“预算”拆成两个实体报价是面向业主的确认单预算明细是报价单的明细行这样设计数据库时会非常顺手。实体关系上要控制外键的方向project 持有 owner_id、designer_id、foreman_id 三个用户ID但不要建三条外键约束关联到 user 表后续做逻辑删除时会很麻烦。推荐的做法是只保留逻辑外键在查询时用 JOIN 取用户昵称而不是在数据库层强制约束。2.2 装修项目的状态机设计从量房到售后的核心状态流转这个题目里最容易被低估的是状态机。装修项目的生命周期是一条完整的状态链待量房 → 设计中 → 待报价 → 已签约 → 施工中 → 待验收 → 已完成 → 售后中。每一步都在上一动作完成后触发并且大部分状态不允许回退。用整数直接存状态然后写 if 判断在单机小项目里能跑但状态一多就乱。常见实践是用枚举类做状态常量再把“允许流转到哪些状态”的映射集中放在一个配置里这样新增状态或调整流程时不需要搜代码。2.2.1 用枚举常量管理状态流转public enum ProjectStatus { PENDING_MEASURE(0, 待量房), DESIGNING(1, 设计中), QUOTATION_PENDING(2, 待报价), CONTRACTED(3, 已签约), CONSTRUCTING(4, 施工中), ACCEPTANCE_PENDING(5, 待验收), COMPLETED(6, 已完成), AFTER_SALE(7, 售后中); private final int code; private final String desc; private static final MapInteger, ListInteger TRANSITIONS new HashMap(); static { TRANSITIONS.put(0, Collections.singletonList(1)); TRANSITIONS.put(1, Arrays.asList(2, 0)); TRANSITIONS.put(2, Collections.singletonList(3)); TRANSITIONS.put(3, Collections.singletonList(4)); TRANSITIONS.put(4, Collections.singletonList(5)); TRANSITIONS.put(5, Arrays.asList(6, 4)); TRANSITIONS.put(6, Collections.singletonList(7)); } public static boolean canTransit(int from, int to) { return TRANSITIONS.getOrDefault(from, Collections.emptyList()).contains(to); } }这段代码把状态码和文字描述绑在一起前端直接展示 desc后端在做状态更新时调用canTransit做前置校验。TRANSITIONS用的是邻接表结构每个状态对应一串“可以流转到的状态码”。需要特别注意Arrays.asList(2, 0)这一行的含义设计方案打回时状态从“设计中”退回“待量房”是被允许的但“待量房”不能跳转“已签约”必须一步一步走。这样限制是刻意的装修流程每一步都有线下依据跳状态就意味着业务造假。2.3 细粒度业务对象预算清单、施工节点与验收单预算清单建议设计成“主表 明细”的结构。主表存总价、状态、确认时间明细表存每一项的材料名称、规格、单位、数量、单价、合价。这种结构对应到代码里就是Quotation和QuotationItem两个实体前端展示时按明细行渲染表格报价单生成 PDF 时直接遍历明细就行。施工节点用一个ProjectNode表维护每条记录是一个节点。节点本身要有排序字段、计划完成日期、实际完成日期、状态、备注、现场照片URL。验收单则是一张独立表记录验收人、验收时间、验收结论、问题描述。这里要提醒的是尽量不要把节点状态直接写在 project 表里否则改一个节点要 UPDATE 两次数据冗余多了之后非常容易不一致。3. SpringBoot工程实现项目结构、登录鉴权与分页查询3.1 项目初始化的技术选型与包结构如果是自己从零搭建建议直接去 start.spring.io 生成基础工程JDK 选 8 或 11Spring Boot 选 2.7.x。这个版本处于稳定维护期网上资料最多遇到问题最容易搜到答案。Spring Boot 3.x 现在虽然热度高但部分依赖在毕业设计环境里容易踩版本坑比如 javax 到 jakarta 的迁移没有必须新特性的前提下2.7.x 更保险。依赖方面必带的有这几个spring-boot-starter-web mybatis-plus-boot-starter 3.5.x mysql-connector-j jjwt-api / jjwt-impl / jjwt-jackson lombok spring-boot-starter-validation包结构参考以下分层方式Controller 只在 controller 层业务逻辑下沉到 service数据库操作放进 mapper。com.example.decoration ├── controller # 接口层 ├── service # 业务逻辑 ├── mapper # MyBatis-Plus Mapper ├── entity # 数据库实体 ├── dto # 入参出参对象 ├── config # 拦截器、WebMvc配置 ├── common # 统一返回结果、异常处理 └── util # JwtUtil、DateUtil等3.2 JWT登录鉴权的落地写法3.2.1 登录接口的Controller与服务层实现RestController RequestMapping(/api/auth) public class AuthController { Resource private AuthService authService; PostMapping(/login) public ResultLoginVO login(RequestBody Valid LoginDTO dto) { return Result.success(authService.login(dto.getUsername(), dto.getPassword())); } }Service 内部逻辑做三件事根据用户名查用户用 BCrypt 校验密码生成 JWT 返回给前端。密码校验代码可以写成一个独立方法方便后面做“修改密码”“找回密码”时复用。生成 JWT 时把用户ID、角色码放进去过期时间设置为 24 小时。记住不要放密码或手机号这类敏感信息JWT 的 payload 是 Base64 编码并不加密。3.2.2 自定义拦截器校验TokenComponent public class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (OPTIONS.equalsIgnoreCase(request.getMethod())) { return true; } String token request.getHeader(Authorization); if (token null || !token.startsWith(Bearer )) { throw new ApiException(401, 未登录); } Claims claims JwtUtil.parseToken(token.replace(Bearer , )); request.setAttribute(userId, claims.get(userId)); request.setAttribute(userRole, claims.get(role)); return true; } }拦截器里做的核心动作是解析 Token 并把用户信息塞进 request attribute后续 Controller 用RequestAttribute Integer userId取值。注意代码里专门判断了OPTIONS请求因为前端联调时跨域预检请求是不带 Token 的不放开就会让整个登录接口在浏览器里无法调用。注册拦截器时排除/api/auth/login、/api/case/list这类匿名接口。3.3 SpringBoot配置yaml里的分页和逻辑删除参数spring: datasource: url: jdbc:mysql://localhost:3306/decoration?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver mybatis-plus: global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0 configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl mapper-locations: classpath*:mapper/**/*.xml这里的logic-delete-field指定所有实体里的deleted字段会被 MyBatis-Plus 自动处理代码里执行deleteById时实际生成的是UPDATE ... SET deleted 1。注意deleted必须在所有实体类里都加上或者让所有实体继承一个BaseEntity否则只有部分表支持逻辑删除查询时会出现漏过滤的情况。map-underscore-to-camel-case这个配置默认就是 true但显式写上能避免将来某些环境下配置被覆盖后查询结果全是 null。3.4 用MyBatis-Plus做条件分页查询public PageResultCaseVO pageCases(CaseQueryDTO query) { LambdaQueryWrapperCaseInfo wrapper new LambdaQueryWrapper(); wrapper.eq(CaseInfo::getStatus, 1) .like(StringUtils.hasText(query.getStyle()), CaseInfo::getStyle, query.getStyle()) .ge(query.getMinArea() ! null, CaseInfo::getArea, query.getMinArea()) .le(query.getMaxArea() ! null, CaseInfo::getArea, query.getMaxArea()) .orderByDesc(CaseInfo::getViewCount); PageCaseInfo page new Page(query.getPageNum(), query.getPageSize()); PageCaseInfo result caseMapper.selectPage(page, wrapper); return PageResult.of(result.getRecords(), result.getTotal()); }分页查询需要配合配置类里注册 MyBatis-Plus 的PaginationInnerInterceptor不注册的话selectPage返回的 total 会是 0 或查全量。like方法里的条件用StringUtils.hasText判断避免前端传了空字符串时拼接出LIKE %%导致全表扫描。ge和le是边界查询注意区分大小写ge是大于等于le是小于等于。4. MySQL核心表设计与增删改查落地SQL4.1 在线装修系统的E-R关系梳理在线装修管理系统的表结构建议控制在 10 张左右太多则工作量膨胀太少则撑不起论文里的“数据库设计”章节。核心表关系用文字可以这样描述用户表通过角色表区分身份装修案例表属于设计师用户业主提交量房申请后生成项目表项目表围绕自身派生出施工节点表、预算表和验收表。画 E-R 图的时候注意区分“从属关系”和“引用关系”。项目节点从属于项目是强从属节点的删除应该跟随项目预算明细从属于报价单同理。而项目表中的 owner_id 是引用关系删除用户不应删除项目否则历史数据就废了。论文里的 E-R 图建议用 draw.io 画实体矩形、菱形关系、连线注解不要画得太拥挤重点表达清楚“项目”在正中心辐射所有子表即可。4.2 核心建表DDL与注释规范CREATE TABLE user ( id bigint(20) NOT NULL AUTO_INCREMENT, username varchar(50) NOT NULL COMMENT 登录名, password varchar(100) NOT NULL COMMENT BCrypt加密后的密码, real_name varchar(50) DEFAULT NULL COMMENT 真实姓名, phone varchar(20) DEFAULT NULL COMMENT 手机号, role_id bigint(20) NOT NULL COMMENT 角色ID, status tinyint(4) DEFAULT 1 COMMENT 1正常 0禁用, deleted tinyint(4) DEFAULT 0 COMMENT 逻辑删除, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_role_id (role_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表; CREATE TABLE project ( id bigint(20) NOT NULL AUTO_INCREMENT, case_id bigint(20) DEFAULT NULL COMMENT 来源案例ID, owner_id bigint(20) NOT NULL COMMENT 业主用户ID, designer_id bigint(20) DEFAULT NULL COMMENT 设计师用户ID, foreman_id bigint(20) DEFAULT NULL COMMENT 工长用户ID, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 状态码对应枚举, address varchar(200) DEFAULT NULL COMMENT 装修地址, plan_start date DEFAULT NULL COMMENT 计划开工日期, plan_end date DEFAULT NULL COMMENT 计划完工日期, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_owner_id (owner_id), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT装修项目表;建表有三处值得注意。第一所有表都带deleted和create_time且deleted与 MyBatis-Plus 的配置对应领域表也不例外。第二状态字段用tinyint存储枚举的 code 值而不是直接存“施工中”这类中文。第三索引不要乱加只需要在查询条件里的外键字段和状态字段上加普通索引idx_status在按状态筛选项目列表时非常关键。4.2.1 project_node 和 budget_item 的表结构说明施工节点表的关键字段是sort_no和status。sort_no控制节点展示顺序工长按顺序施工不允许跳序。status建议与项目状态码保持一致比如待开工是 0施工中是 1已完成是 2这样联表统计时用同一个值域。预算明细表的核心字段是quotation_id、item_name、specification、quantity、unit_price、total_price其中total_price可以由quantity * unit_price计算得出但保存冗余值能减轻查询时的计算压力也方便导出报表后人工核对。4.3 联表查询的SQL与索引设计SELECT p.id AS project_id, u.real_name AS owner_name, d.real_name AS designer_name, p.status, p.plan_start, p.plan_end FROM project p JOIN user u ON p.owner_id u.id LEFT JOIN user d ON p.designer_id d.id WHERE p.status IN (4, 5) AND p.create_time 2024-01-01 ORDER BY p.create_time DESC LIMIT 20;这条 SQL 覆盖了最常用的“查询进行中项目”场景。注意设计师用了LEFT JOIN因为项目可能还没有分配设计师此时d.real_name为 NULL 而不是导致整行丢失。p.create_time 2024-01-01的写法比DATE(p.create_time) 2024-01-01更高效后者会让索引失效。分页SQL里LIMIT 20的页码参数应该由后端分页插件替代避免直接把用户传进来的 pageNum 做乘法。实际查询时高频的组合条件是status create_time可以在idx_status之外再建一个联合索引idx_status_create_time (status, create_time)这样上面这条 SQL 能走索引覆盖。不要给user表的real_name建索引等值查询不是它联表查询走的是主键索引。5. 论文写作与答辩把源码和数据库设计变成得分点5.1 论文目录与每章的素材来源很多人在写论文时卡在“不知道怎么把代码转成文字”。其实论文的每一章都能对应到工程里的具体产物按以下结构组织比较省力。第一章绪论写背景和意义素材来自开题报告加上网上查到的装修行业数字化数据描述第二章技术介绍里放 SpringBoot 的架构图、MyBatis-Plus 的介绍、JWT 鉴权流程第三章需求分析直接复用第二章的角色表和状态枚举把用例图画出来第四章系统设计放 E-R 图、核心表结构 DDL、关键接口设计第五章系统实现是工作量最大的部分把登录、案例列表、施工节点更新、验收这几个核心功能每个写 3 到 4 个截图加代码片段第六章测试写功能测试用例表。第六章的测试用例表值得提前整理日常开发顺手记一下每个接口的入参、预期返回值、实测结果写论文时直接复制不用重做测试。5.2 三个能拉开差距的差异化设计答辩时被问得最多的问题通常不是“你这个怎么做”而是“你这个和别人有什么不一样”。三个短期内能落地的差异化设计第一个是在施工节点模块加“现场拍照”功能。用阿里云 OSS 或者本地文件存储每个节点至少上传一张照片在项目详情页以时间轴形式展示。这是实际业务里最有用的功能也是答辩时最容易出彩的点。第二个是预算报价自动计算。前端维护一个报价模板选择材料项后自动累加quantity * unit_price。这个功能放在文档里就是“系统实现了预算的自动核算避免人工计算误差”嘴上说一句“预算公式是total sum(quantity * unit_price)如果总价超过业主预算区间就弹窗提示”就足够应付大多数提问。第三个是状态流转的前端拦截。后端已经做了状态机校验前端再在按钮层做一次判断比如“已签约”之后不再显示“编辑方案”按钮。答辩时把这段逻辑讲清楚能证明你理解业务规则和前后端联动的边界。答辩前后建议把 JWT 的原理和 MySQL 索引的设计原因多读两遍。这两个点几乎被所有答辩老师问回答时落到“Token 无状态、服务端不存储会话”和“联合索引最左前缀原则”。这两个问题答顺了整场答辩的节奏就不会乱。本文还有配套的精品资源点击获取 SpringBoot在线装修管理系统毕业设计：需求分析、权限设计与论文指南
简介这是一套面向计算机专业毕业设计、课程设计及期末大作业的 Spring Boot 在线装修管理系统完整项目包。系统基于 Spring Boot 轻量级框架整合数据库技术覆盖用户管理、装修项目管理、预算管理、材料管理、进度跟踪等核心模块适用于需要完整前后台业务闭环的装修管理场景。资源共 3 个文件整体 36.2MB包含 SQL 数据库脚本用于初始化项目表结构与示例数据、RAR 源码压缩包含可导入 IDE 的工程代码与配置以及 DOC 论文文档系统阐述需求分析、系统设计、功能实现与测试结果。论文部分既提供理论框架又给出实际开发中的应用案例便于学习者对照源码理解实现思路。目前已有 123 人学习浏览适合希望系统掌握 Spring Boot 开发流程、并直接参考或扩展完成毕业设计的读者。1. 在线装修管理系统毕业设计里最典型的SpringBoot业务流题目“SpringBoot在线装修管理系统”是毕业设计和课程设计里出现频率最高的一类题目。它表面上是一个普通的管理系统但拆开看它同时包含多角色权限、业务状态流转、文件上传、数据库设计、报表统计等多个模块恰好覆盖了SpringBoot开发的大部分核心技能点。很多人在做这类项目时最大的障碍不是代码写不出来而是不知道“装修”这件事本身该拆成哪些对象、哪些状态、谁在什么角色下能操作什么。这篇内容把从领域建模、工程实现到数据库表设计、论文写作的完整路径讲清楚。适合正在做类似题目的同学也适合负责带毕设的工程师做参考。2. 需求分析与领域模型先把装修业务拆成可落地的对象2.1 在线装修系统的六种实体角色与权限矩阵在线装修管理系统不是简单的“业主查案例、管理员发文章”。把实际业务捋一遍系统至少要覆盖四种角色业主、设计师、工长、系统管理员。有的题目还会加“前台访客”和“客服”但在核心设计里前两种就已经把权限复杂度撑起来了。角色核心操作能看的页面业主浏览案例、提交量房申请、确认报价、跟踪施工节点、验收案例列表、我的项目、验收单设计师接单、上传设计方案、生成预算清单、提交报价待接单项目、方案管理、预算明细工长维护施工节点进度、上传现场照片进行中的项目、节点管理管理员用户管理、案例审核、全部项目查询、数据统计后台管理端在设计权限时不要用一张 user 表的 role 字段做硬编码判断。常见做法是拆出user、role两张表用 user_role 关联。这样以后加“监理”或“材料商”角色时只需要加一条角色记录和对应的菜单权限不用改代码里的 if-else 逻辑。权限判断建议写在 SpringMVC 拦截器里用注解标记接口需要的角色码。2.1.1 领域模型的实体关系雏形核心实体至少包括用户、角色、装修案例、量房申请、项目、施工节点、预算明细、验收单。装修项目的业务逻辑基本围绕“业主提交意愿 — 设计师跟进 — 工长施工 — 双方验收”这条主链展开而前端展示围绕案例和节点进度展开。如果把“报价”和“预算”拆成两个实体报价是面向业主的确认单预算明细是报价单的明细行这样设计数据库时会非常顺手。实体关系上要控制外键的方向project 持有 owner_id、designer_id、foreman_id 三个用户ID但不要建三条外键约束关联到 user 表后续做逻辑删除时会很麻烦。推荐的做法是只保留逻辑外键在查询时用 JOIN 取用户昵称而不是在数据库层强制约束。2.2 装修项目的状态机设计从量房到售后的核心状态流转这个题目里最容易被低估的是状态机。装修项目的生命周期是一条完整的状态链待量房 → 设计中 → 待报价 → 已签约 → 施工中 → 待验收 → 已完成 → 售后中。每一步都在上一动作完成后触发并且大部分状态不允许回退。用整数直接存状态然后写 if 判断在单机小项目里能跑但状态一多就乱。常见实践是用枚举类做状态常量再把“允许流转到哪些状态”的映射集中放在一个配置里这样新增状态或调整流程时不需要搜代码。2.2.1 用枚举常量管理状态流转public enum ProjectStatus { PENDING_MEASURE(0, 待量房), DESIGNING(1, 设计中), QUOTATION_PENDING(2, 待报价), CONTRACTED(3, 已签约), CONSTRUCTING(4, 施工中), ACCEPTANCE_PENDING(5, 待验收), COMPLETED(6, 已完成), AFTER_SALE(7, 售后中); private final int code; private final String desc; private static final MapInteger, ListInteger TRANSITIONS new HashMap(); static { TRANSITIONS.put(0, Collections.singletonList(1)); TRANSITIONS.put(1, Arrays.asList(2, 0)); TRANSITIONS.put(2, Collections.singletonList(3)); TRANSITIONS.put(3, Collections.singletonList(4)); TRANSITIONS.put(4, Collections.singletonList(5)); TRANSITIONS.put(5, Arrays.asList(6, 4)); TRANSITIONS.put(6, Collections.singletonList(7)); } public static boolean canTransit(int from, int to) { return TRANSITIONS.getOrDefault(from, Collections.emptyList()).contains(to); } }这段代码把状态码和文字描述绑在一起前端直接展示 desc后端在做状态更新时调用canTransit做前置校验。TRANSITIONS用的是邻接表结构每个状态对应一串“可以流转到的状态码”。需要特别注意Arrays.asList(2, 0)这一行的含义设计方案打回时状态从“设计中”退回“待量房”是被允许的但“待量房”不能跳转“已签约”必须一步一步走。这样限制是刻意的装修流程每一步都有线下依据跳状态就意味着业务造假。2.3 细粒度业务对象预算清单、施工节点与验收单预算清单建议设计成“主表 明细”的结构。主表存总价、状态、确认时间明细表存每一项的材料名称、规格、单位、数量、单价、合价。这种结构对应到代码里就是Quotation和QuotationItem两个实体前端展示时按明细行渲染表格报价单生成 PDF 时直接遍历明细就行。施工节点用一个ProjectNode表维护每条记录是一个节点。节点本身要有排序字段、计划完成日期、实际完成日期、状态、备注、现场照片URL。验收单则是一张独立表记录验收人、验收时间、验收结论、问题描述。这里要提醒的是尽量不要把节点状态直接写在 project 表里否则改一个节点要 UPDATE 两次数据冗余多了之后非常容易不一致。3. SpringBoot工程实现项目结构、登录鉴权与分页查询3.1 项目初始化的技术选型与包结构如果是自己从零搭建建议直接去 start.spring.io 生成基础工程JDK 选 8 或 11Spring Boot 选 2.7.x。这个版本处于稳定维护期网上资料最多遇到问题最容易搜到答案。Spring Boot 3.x 现在虽然热度高但部分依赖在毕业设计环境里容易踩版本坑比如 javax 到 jakarta 的迁移没有必须新特性的前提下2.7.x 更保险。依赖方面必带的有这几个spring-boot-starter-web mybatis-plus-boot-starter 3.5.x mysql-connector-j jjwt-api / jjwt-impl / jjwt-jackson lombok spring-boot-starter-validation包结构参考以下分层方式Controller 只在 controller 层业务逻辑下沉到 service数据库操作放进 mapper。com.example.decoration ├── controller # 接口层 ├── service # 业务逻辑 ├── mapper # MyBatis-Plus Mapper ├── entity # 数据库实体 ├── dto # 入参出参对象 ├── config # 拦截器、WebMvc配置 ├── common # 统一返回结果、异常处理 └── util # JwtUtil、DateUtil等3.2 JWT登录鉴权的落地写法3.2.1 登录接口的Controller与服务层实现RestController RequestMapping(/api/auth) public class AuthController { Resource private AuthService authService; PostMapping(/login) public ResultLoginVO login(RequestBody Valid LoginDTO dto) { return Result.success(authService.login(dto.getUsername(), dto.getPassword())); } }Service 内部逻辑做三件事根据用户名查用户用 BCrypt 校验密码生成 JWT 返回给前端。密码校验代码可以写成一个独立方法方便后面做“修改密码”“找回密码”时复用。生成 JWT 时把用户ID、角色码放进去过期时间设置为 24 小时。记住不要放密码或手机号这类敏感信息JWT 的 payload 是 Base64 编码并不加密。3.2.2 自定义拦截器校验TokenComponent public class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (OPTIONS.equalsIgnoreCase(request.getMethod())) { return true; } String token request.getHeader(Authorization); if (token null || !token.startsWith(Bearer )) { throw new ApiException(401, 未登录); } Claims claims JwtUtil.parseToken(token.replace(Bearer , )); request.setAttribute(userId, claims.get(userId)); request.setAttribute(userRole, claims.get(role)); return true; } }拦截器里做的核心动作是解析 Token 并把用户信息塞进 request attribute后续 Controller 用RequestAttribute Integer userId取值。注意代码里专门判断了OPTIONS请求因为前端联调时跨域预检请求是不带 Token 的不放开就会让整个登录接口在浏览器里无法调用。注册拦截器时排除/api/auth/login、/api/case/list这类匿名接口。3.3 SpringBoot配置yaml里的分页和逻辑删除参数spring: datasource: url: jdbc:mysql://localhost:3306/decoration?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver mybatis-plus: global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0 configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl mapper-locations: classpath*:mapper/**/*.xml这里的logic-delete-field指定所有实体里的deleted字段会被 MyBatis-Plus 自动处理代码里执行deleteById时实际生成的是UPDATE ... SET deleted 1。注意deleted必须在所有实体类里都加上或者让所有实体继承一个BaseEntity否则只有部分表支持逻辑删除查询时会出现漏过滤的情况。map-underscore-to-camel-case这个配置默认就是 true但显式写上能避免将来某些环境下配置被覆盖后查询结果全是 null。3.4 用MyBatis-Plus做条件分页查询public PageResultCaseVO pageCases(CaseQueryDTO query) { LambdaQueryWrapperCaseInfo wrapper new LambdaQueryWrapper(); wrapper.eq(CaseInfo::getStatus, 1) .like(StringUtils.hasText(query.getStyle()), CaseInfo::getStyle, query.getStyle()) .ge(query.getMinArea() ! null, CaseInfo::getArea, query.getMinArea()) .le(query.getMaxArea() ! null, CaseInfo::getArea, query.getMaxArea()) .orderByDesc(CaseInfo::getViewCount); PageCaseInfo page new Page(query.getPageNum(), query.getPageSize()); PageCaseInfo result caseMapper.selectPage(page, wrapper); return PageResult.of(result.getRecords(), result.getTotal()); }分页查询需要配合配置类里注册 MyBatis-Plus 的PaginationInnerInterceptor不注册的话selectPage返回的 total 会是 0 或查全量。like方法里的条件用StringUtils.hasText判断避免前端传了空字符串时拼接出LIKE %%导致全表扫描。ge和le是边界查询注意区分大小写ge是大于等于le是小于等于。4. MySQL核心表设计与增删改查落地SQL4.1 在线装修系统的E-R关系梳理在线装修管理系统的表结构建议控制在 10 张左右太多则工作量膨胀太少则撑不起论文里的“数据库设计”章节。核心表关系用文字可以这样描述用户表通过角色表区分身份装修案例表属于设计师用户业主提交量房申请后生成项目表项目表围绕自身派生出施工节点表、预算表和验收表。画 E-R 图的时候注意区分“从属关系”和“引用关系”。项目节点从属于项目是强从属节点的删除应该跟随项目预算明细从属于报价单同理。而项目表中的 owner_id 是引用关系删除用户不应删除项目否则历史数据就废了。论文里的 E-R 图建议用 draw.io 画实体矩形、菱形关系、连线注解不要画得太拥挤重点表达清楚“项目”在正中心辐射所有子表即可。4.2 核心建表DDL与注释规范CREATE TABLE user ( id bigint(20) NOT NULL AUTO_INCREMENT, username varchar(50) NOT NULL COMMENT 登录名, password varchar(100) NOT NULL COMMENT BCrypt加密后的密码, real_name varchar(50) DEFAULT NULL COMMENT 真实姓名, phone varchar(20) DEFAULT NULL COMMENT 手机号, role_id bigint(20) NOT NULL COMMENT 角色ID, status tinyint(4) DEFAULT 1 COMMENT 1正常 0禁用, deleted tinyint(4) DEFAULT 0 COMMENT 逻辑删除, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_role_id (role_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表; CREATE TABLE project ( id bigint(20) NOT NULL AUTO_INCREMENT, case_id bigint(20) DEFAULT NULL COMMENT 来源案例ID, owner_id bigint(20) NOT NULL COMMENT 业主用户ID, designer_id bigint(20) DEFAULT NULL COMMENT 设计师用户ID, foreman_id bigint(20) DEFAULT NULL COMMENT 工长用户ID, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 状态码对应枚举, address varchar(200) DEFAULT NULL COMMENT 装修地址, plan_start date DEFAULT NULL COMMENT 计划开工日期, plan_end date DEFAULT NULL COMMENT 计划完工日期, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_owner_id (owner_id), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT装修项目表;建表有三处值得注意。第一所有表都带deleted和create_time且deleted与 MyBatis-Plus 的配置对应领域表也不例外。第二状态字段用tinyint存储枚举的 code 值而不是直接存“施工中”这类中文。第三索引不要乱加只需要在查询条件里的外键字段和状态字段上加普通索引idx_status在按状态筛选项目列表时非常关键。4.2.1 project_node 和 budget_item 的表结构说明施工节点表的关键字段是sort_no和status。sort_no控制节点展示顺序工长按顺序施工不允许跳序。status建议与项目状态码保持一致比如待开工是 0施工中是 1已完成是 2这样联表统计时用同一个值域。预算明细表的核心字段是quotation_id、item_name、specification、quantity、unit_price、total_price其中total_price可以由quantity * unit_price计算得出但保存冗余值能减轻查询时的计算压力也方便导出报表后人工核对。4.3 联表查询的SQL与索引设计SELECT p.id AS project_id, u.real_name AS owner_name, d.real_name AS designer_name, p.status, p.plan_start, p.plan_end FROM project p JOIN user u ON p.owner_id u.id LEFT JOIN user d ON p.designer_id d.id WHERE p.status IN (4, 5) AND p.create_time 2024-01-01 ORDER BY p.create_time DESC LIMIT 20;这条 SQL 覆盖了最常用的“查询进行中项目”场景。注意设计师用了LEFT JOIN因为项目可能还没有分配设计师此时d.real_name为 NULL 而不是导致整行丢失。p.create_time 2024-01-01的写法比DATE(p.create_time) 2024-01-01更高效后者会让索引失效。分页SQL里LIMIT 20的页码参数应该由后端分页插件替代避免直接把用户传进来的 pageNum 做乘法。实际查询时高频的组合条件是status create_time可以在idx_status之外再建一个联合索引idx_status_create_time (status, create_time)这样上面这条 SQL 能走索引覆盖。不要给user表的real_name建索引等值查询不是它联表查询走的是主键索引。5. 论文写作与答辩把源码和数据库设计变成得分点5.1 论文目录与每章的素材来源很多人在写论文时卡在“不知道怎么把代码转成文字”。其实论文的每一章都能对应到工程里的具体产物按以下结构组织比较省力。第一章绪论写背景和意义素材来自开题报告加上网上查到的装修行业数字化数据描述第二章技术介绍里放 SpringBoot 的架构图、MyBatis-Plus 的介绍、JWT 鉴权流程第三章需求分析直接复用第二章的角色表和状态枚举把用例图画出来第四章系统设计放 E-R 图、核心表结构 DDL、关键接口设计第五章系统实现是工作量最大的部分把登录、案例列表、施工节点更新、验收这几个核心功能每个写 3 到 4 个截图加代码片段第六章测试写功能测试用例表。第六章的测试用例表值得提前整理日常开发顺手记一下每个接口的入参、预期返回值、实测结果写论文时直接复制不用重做测试。5.2 三个能拉开差距的差异化设计答辩时被问得最多的问题通常不是“你这个怎么做”而是“你这个和别人有什么不一样”。三个短期内能落地的差异化设计第一个是在施工节点模块加“现场拍照”功能。用阿里云 OSS 或者本地文件存储每个节点至少上传一张照片在项目详情页以时间轴形式展示。这是实际业务里最有用的功能也是答辩时最容易出彩的点。第二个是预算报价自动计算。前端维护一个报价模板选择材料项后自动累加quantity * unit_price。这个功能放在文档里就是“系统实现了预算的自动核算避免人工计算误差”嘴上说一句“预算公式是total sum(quantity * unit_price)如果总价超过业主预算区间就弹窗提示”就足够应付大多数提问。第三个是状态流转的前端拦截。后端已经做了状态机校验前端再在按钮层做一次判断比如“已签约”之后不再显示“编辑方案”按钮。答辩时把这段逻辑讲清楚能证明你理解业务规则和前后端联动的边界。答辩前后建议把 JWT 的原理和 MySQL 索引的设计原因多读两遍。这两个点几乎被所有答辩老师问回答时落到“Token 无状态、服务端不存储会话”和“联合索引最左前缀原则”。这两个问题答顺了整场答辩的节奏就不会乱。本文还有配套的精品资源点击获取