企业官网建设流程全解析

简介：基于JAVA+Vue+SpringBoot+MySQL的康复中心管理系统毕业设计项目，面向计算机相关专业毕业生、Java初学者及需要快速搭建前后端分离管理系统的开发者。系统覆盖访客管理、房间管理、入住退房、缴费、药品档案、康复训练、网上咨询等核心业务，并内置基于角色的访问控制，支持用户、部门、角色、菜单、日志及数据字典等基础模块，权限可精确到按钮级别。压缩包共364个文件，主要包含186个Java后端源码、87个Vue前端页面、42个JavaScript脚本、1个SQL数据库脚本及配置文件，整体约1.2MB，目录结构清晰，便于按模块查阅。目前已有185人浏览学习。通过本项目可掌握SpringBoot与Vue前后端分离开发流程、MyBatis-Plus数据操作、权限控制设计与康复业务建模方法，并能直接借鉴其中的RBAC权限设计与管理页面布局，适合作为毕业设计选题参考或项目二次开发基础。

1. 康复中心管理系统：为什么毕设最难的环节是权限而不是业务

康复中心管理系统的表面业务并不复杂：前台登记访客、安排房间、记录康复训练、退房缴费、网上咨询。但真要用 Vue + SpringBoot + MySQL 把它做成能交付的毕业设计，你会发现工作量几乎都耗在权限控制和状态流转上。管理员、护理人员、康复师看到的菜单不同，能按的按钮不一样，甚至要求精确到“只能管理自己楼层的房间”。我的做法是放弃写死的 if 判断，用 Spring Security + 自定义注解做后端鉴权，用 Vue 指令做前端按钮遮挡，用 MySQL 的角色菜单关联表把权限变成可配置数据。这套方案适合正在做康复中心管理系统、医院或养老院后台类 java 毕业设计的同学，也适合需要一个成熟 RBAC 权限脚手架的开发者参考。

2. 总体架构设计：SpringBoot 后端、Vue 前端与 MySQL 的职责切分

2.1 三层架构与资源文件对应关系

拿到这类资源，我建议先别急着写业务代码，而是按一条固定顺序吃透它：先看目录树，再看表设计，最后才碰 Controller 和页面。tree.btl描述的是后端包结构和前端目录树，table.btl是数据库表设计，tableIndex.btl是索引和查询条件的约定，api.btl对应前端 axios 接口封装。把这些文件当成生成器的输入，先还原出项目骨架，再往业务模块里填逻辑，后面就不会出现控制器方法越写越长、Service 里堆了几百行 SQL 的失控局面。

整个系统的架构按三层切分：

• 表现层：Vue + Element Plus，负责菜单、表单、列表展示，统一从api.btl里的接口封装取数据。
• 业务层：SpringBoot Controller + Service + MyBatis-Plus，负责权限校验和处理入住、退房、缴费这类跨表逻辑。
• 数据层：MySQL 8，业务表用 InnoDB，权限关联表也用 InnoDB，外键不放数据库，靠 Service 层保证一致性。

后端包结构按职责分成五块。mpController.btl里的 Controller 只做参数接收和结果返回，mpServiceImpl.btl的 ServiceImpl 承载真正的业务逻辑，entity.btl对应数据库实体，mplus.btl是 MyBatis-Plus 的配置规范，包含分页插件和字段自动填充。

com.rehab.admin ├── common // 统一返回结果、全局异常处理、工具类 ├── config // Security 配置、MyBatis-Plus 配置、CORS 配置 ├── controller // 对外接口层，只做参数接收和结果返回 ├── service // 业务逻辑接口与实现，跨表操作集中在这里 ├── mapper // MyBatis-Plus 的 Mapper 接口 ├── entity // 数据库实体，字段和表字段一一对应 └── vo/dto // 前端展示对象和接收对象，避免把实体直接暴露出去

为什么这套项目选 MyBatis-Plus 而不是 JPA？因为一个人完成毕设时，百分之八十的查询场景是单表 CRUD 加条件拼接，MyBatis-Plus 的 LambdaQueryWrapper 一行代码就能写出来，剩下百分之二十的复杂统计用@Select注解直接写在 Mapper 接口里，不需要额外维护 XML 映射文件。这个选择直接保证了开发效率，也让代码量维持在可控范围。

前端目录也按业务模块组织，不把页面乱摊在路由里：

src ├── api // 每个业务模块一个 api 文件 ├── views │ ├── visitor // 访客管理页面 │ ├── room // 房间管理页面 │ ├── payment // 缴费管理页面 │ └── training // 康复训练页面 ├── components // 公共组件，比如上传弹窗、图表卡片 ├── store // Pinia 状态管理，保存用户信息和权限集合 └── directive // 按钮级权限指令 hasPermi

这样切分的理由很简单：访客管理、房间管理看起来都是增删改查，但它们的状态变更互相牵扯。如果每个模块各自维护一套状态判断，后面处理入住退房逻辑时会出现大量重复代码。所以我坚持把一个完整业务链路放在同一个 Service 里，页面之间只通过路径参数传递 id，不在前端缓存对象状态。

2.2 数据库设计：业务表与系统管理表分开设计

数据库设计是整个方案的地基。康复中心管理系统里，业务表包括访客信息表、房间表、入住记录表、缴费记录表、药品档案表、康复训练表、网上咨询表；系统管理表包括用户、部门、角色、菜单、用户角色关联、角色菜单关联、操作日志、数据字典、文件管理。两类表维护节奏不一样：业务表跟随功能迭代，系统表一旦定下来基本不动。

先看房间表，这是状态流转的核心：

CREATE TABLE `rehab_room` ( `id` bigint NOT NULL AUTO_INCREMENT, `room_no` varchar(20) NOT NULL COMMENT '房间号', `room_type` tinyint NOT NULL COMMENT '1单人间 2双人间 3多人间', `bed_num` int NOT NULL DEFAULT 1 COMMENT '床位数', `status` tinyint NOT NULL DEFAULT 0 COMMENT '0空闲 1占用 2保洁中 3维修中', `floor_no` int DEFAULT NULL COMMENT '所属楼层', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_room_no` (`room_no`), KEY `idx_status` (`status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='房间表';

状态字段用 tinyint 而不是直接存字符串，是为了后续枚举映射方便，也避免出现“空置”和“空闲”这种同义但不同值的脏数据。凡是涉及状态的字段，我都给一个明确的数字含义，并在文档里固定注释。这里最容易翻车的点在第 4 章会专门讲：房间状态、入住记录状态、缴费状态这三张表的状态，必须能在一次事务里同时更新，否则就会出现“房间空着但访客没办法入住”的怪现象。

系统管理表遵循经典 RBAC 设计。用户和角色多对多，角色和菜单多对多，菜单表里不仅有目录和菜单，还有按钮权限记录，按钮权限码就是权限标识：

CREATE TABLE `sys_menu` ( `id` bigint NOT NULL AUTO_INCREMENT, `parent_id` bigint NOT NULL DEFAULT 0, `menu_name` varchar(50) NOT NULL, `perms` varchar(100) DEFAULT NULL COMMENT '权限标识，如 rehab:visitor:add', `menu_type` tinyint DEFAULT NULL COMMENT '0目录 1菜单 2按钮', `visible` tinyint NOT NULL DEFAULT 1, `sort` int NOT NULL DEFAULT 0, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='菜单权限表';

按钮也作为菜单记录存在，只不过menu_type=2。这样权限分配界面可以直接用同一棵树完成勾选，不需要单独维护权限码表。前端根据perms字段判断按钮是否显示，后端接口用同一个perms判断是否允许操作，这是前后端权限体系容易对齐的关键。

2.3 按钮级权限落地：前端指令 + 后端注解双重校验

后端校验我不用 Spring Security 自带的@PreAuthorize，因为表达式写在注解里不好维护，权限码在菜单表和代码里容易漂移。更直接的做法是自定义一个@RequiresPermission注解，再用 AOP 环绕通知统一拦截：

@Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface RequiresPermission { String value(); }

拦截逻辑的核心是：从 SecurityContext 取出当前登录用户，用户对象里携带登录时加载进来的权限码集合，集合不包含注解要求的权限码就直接抛异常：

@Aspect @Component public class PermissionAspect { @Around("@annotation(requiresPermission)") public Object check(ProceedingJoinPoint joinPoint, RequiresPermission requiresPermission) throws Throwable { LoginUser loginUser = (LoginUser) SecurityContextHolder.getContext() .getAuthentication().getPrincipal(); if (!loginUser.getPermissions().contains(requiresPermission.value())) { throw new BusinessException(403, "无权限访问该操作"); } return joinPoint.proceed(); } }

登录时如何一次性查清用户权限集合？这一步是把用户、角色、菜单三张关联表串起来的核心 SQL：

SELECT DISTINCT m.perms FROM sys_user u JOIN sys_user_role ur ON u.id = ur.user_id JOIN sys_role_menu rm ON rm.role_id = ur.role_id JOIN sys_menu m ON m.id = rm.menu_id WHERE u.id = #{userId} AND m.perms IS NOT NULL AND m.perms != ''

登录流程通常拆成三步。第一步查用户基本信息，第二步查角色编码集合，第三步查权限码集合，组装成 LoginUser 对象存进 SecurityContext：

public LoginUser loadUserByUsername(String username) { SysUser user = userMapper.selectByUsername(username); if (user == null) { throw new UsernameNotFoundException("用户不存在"); } List<String> roles = userMapper.selectRolesByUserId(user.getId()); List<String> perms = userMapper.selectPermsByUserId(user.getId()); return new LoginUser(user, roles, perms); }

这里用DISTINCT防止重复授权导致权限码重复。用户改角色后需要清缓存，否则旧权限会一直留在内存里，这个坑后面专门讲。

前端部分用 Vue 自定义指令处理按钮显隐。指令的核心逻辑是拿当前登录用户的权限集合和按钮上标记的权限码做比对，不匹配就从 DOM 里移除按钮：

// 在 main.js 里注册 hasPermi 指令 app.directive('hasPermi', { mounted(el, binding) { const required = binding.value const userPermissions = useUserStore().permissions if (!required.some((p) => userPermissions.includes(p))) { el.parentNode && el.parentNode.removeChild(el) } } })

页面上的用法如下：

<el-button v-hasPermi="['rehab:visitor:add']" @click="openAddDialog"> 新增访客 </el-button>

需要反复强调一点：前端指令只负责把按钮藏起来，真正拦住请求必须靠后端注解。这样即使有人绕过页面直接调接口，后端也会拒绝，防止越权操作。这套组合是权限控制里最值得复用的实现思路，省掉了复杂的 Spring Security 配置，但是保留了防越权能力。

3. 核心模块实现：访客、房间、缴费与康复训练四个业务模块落地

3.1 业务模块划分：从页面菜单反推功能依赖

先说模块间的依赖关系。访客管理是最核心的主数据，房间管理是状态源，入住退房把前两者串起来，缴费和康复训练是在入住期间产生的业务记录。网上咨询和药品档案是相对独立的部分，前者类似留言回复，后者是字典表加文件上传。

梳理关系后把功能拆成几组：

• 访客管理：新增、编辑、查询访客，实现黑名单和离院状态变更。
• 房间管理：房间类型维护、房间状态变更、房间条件查询。
• 入住退房：办理入住、办理退房，退房时联动房间状态和缴费单。
• 缴费管理：缴费单生成、费用记录查看、缴费确认。
• 康复训练：训练计划下发、训练记录回填、按日期统计完成情况。
• 网上咨询：咨询问题提交、后台回复、咨询状态跟踪。

tree.btl和table.btl的落地顺序基本就是这个思路：先建树形菜单，再建页面和接口，最后建表和字段。如果反过来先建表再想页面，很容易设计出无人使用的冗余字段，比如给房间表加一个“当前访客姓名”字段，但实际上这个信息应该去入住记录表里查。我习惯把表结构字段控制在最小范围，让页面通过关联查询拿到展示信息。

3.2 访客管理：登记、查询、状态变更的实现

访客管理是第一个完整 CRUD 模块，但里面有两个细节必须处理：访客编号可以自动生成，重复登记的访客要自动提示。编号生成逻辑放在 Service 层，不放在 Controller 层：

@Service public class VisitorServiceImpl extends ServiceImpl<VisitorMapper, Visitor> implements VisitorService { @Override public boolean register(VisitorDTO dto) { // 身份证号相同且状态为“在住”则认为是重复登记 long count = this.lambdaQuery() .eq(Visitor::getIdCard, dto.getIdCard()) .eq(Visitor::getStatus, 0) .count(); if (count > 0) { throw new BusinessException("该访客已在住，不能重复登记"); } Visitor visitor = new Visitor(); BeanUtils.copyProperties(dto, visitor); visitor.setVisitorNo(generateNo()); visitor.setStatus(0); this.save(visitor); return true; } private String generateNo() { return "V" + LocalDate.now().format(DateTimeFormatter.ofPattern("yyyyMMdd")) + String.format("%04d", (int) (Math.random() * 10000)); } }

lambdaQuery是 MyBatis-Plus 提供的查询构造器，eq(Visitor::getIdCard, dto.getIdCard())对应 SQL 的where id_card = ?。重复登记的判断一定要限定status=0，也就是说历史访客离院后不拦截再次登记。很多同学在这里漏状态条件，结果同一个身份证号永远无法再次入住。

Controller 只做参数接收和结果封装。增删改查接口通常分成add、edit、delete、list四类，刚好对应add.btl、edit.btl模板方法的设计。查询接口建议加访客姓名、身份证号、手机号、入住状态四个条件，后端用 Wrapper 动态拼接：

@PostMapping("/list") public Result pageList(@RequestBody PageQuery query) { LambdaQueryWrapper<Visitor> wrapper = new LambdaQueryWrapper<>(); wrapper.like(StringUtils.hasText(query.getKeyword()), Visitor::getName, query.getKeyword()) .eq(query.getStatus() != null, Visitor::getStatus, query.getStatus()) .orderByDesc(Visitor::getCreateTime); return Result.ok(visitorService.page(new Page<>(query.getPageNum(), query.getPageSize()), wrapper)); }

这里每个eq前都带一个布尔条件，当参数为空时不加入 SQL，避免查出无关记录。前端表格只需要把返回分页对象渲染出来，总数统计由分页插件自动完成。

3.3 房间管理和入住退房：用状态机约束操作顺序

房间管理看起来只是房间 CRUD，但它和入住、退房、保洁流程深度耦合。我不希望每个操作方法都能随意改房间状态，因此把状态流转集中到一个枚举类里：

public enum RoomStatus { IDLE(0), // 空闲 OCCUPIED(1), // 占用 CLEANING(2), // 保洁中 REPAIR(3); // 维修中 }

定义四个核心流转方法：

• checkIn(roomId)：当前状态必须为空闲，改为占用。
• checkOut(roomId)：当前状态必须为占用，改为保洁中。
• finishClean(roomId)：当前状态必须为保洁中，改为空闲。
• repair(roomId)：当前状态必须为空闲，改为维修中。

这里的关键经验是，状态机绝不只是简单的setStatus，而是转入新状态前要校验前置状态。如果退房操作直接把房间从占用置为空闲，保洁工单就无法生成，后续流程断掉。我把状态机链路放在入住退房 Service 里，配合事务一起执行。

办理退房的完整逻辑如下：

@Transactional(rollbackFor = Exception.class) public void checkOut(Integer stayId) { // 1. 校验入住记录是未离院状态 RehabStay stay = stayMapper.selectById(stayId); if (stay == null || stay.getStatus() != 0) { throw new BusinessException("入住记录不存在或已退房"); } // 2. 关闭入住记录 stay.setStatus(1); stay.setLeaveTime(LocalDateTime.now()); stayMapper.updateById(stay); // 3. 通过 stay 找房间，把房间置为保洁中 Room room = roomMapper.selectById(stay.getRoomId()); if (room == null || room.getStatus() != 1) { throw new BusinessException("房间状态异常，无法退房"); } room.setStatus(2); roomMapper.updateById(room); // 4. 生成未缴费单据 Payment bill = new Payment(); bill.setStayId(stayId); bill.setAmount(calcAmount(stay)); bill.setStatus(0); // 待缴费 paymentMapper.insert(bill); }

@Transactional(rollbackFor = Exception.class)意味着四步任何一步抛出异常，整个方法回滚。为什么退房时房间不改回空闲而是保洁中？因为房间必须经过保洁确认才能给下一位访客使用，这也方便前台看到保洁任务。实际开发最容易翻车的就是第 3 步，房间状态判断错误导致退房成功但房间卡在占用，后面所有查询都会错乱。

3.4 缴费管理与康复训练：业务状态与表单校验

缴费单把入住记录关联起来，状态只有待缴费、已结清、已作废三种。生成时机放在退房时，金额由 Service 层计算，按床位费加护理费加药品费的规则叠加。缴费页面做结清操作时只更新状态，不动房间和入住记录：

@Transactional(rollbackFor = Exception.class) public void pay(Long paymentId) { Payment payment = paymentMapper.selectById(paymentId); if (payment == null || payment.getStatus() != 0) { throw new BusinessException("单据不存在或已结清"); } payment.setStatus(1); payment.setPayTime(LocalDateTime.now()); paymentMapper.updateById(payment); }

康复训练模块和缴费不同，它更偏向任务计划。由康复师创建训练计划，计划里包含访客、训练类型、计划日期、时长、注意事项。护理人员查看当天计划，执行后回填完成情况和备注。这个模块如果按普通增删改查写，会漏掉“当天计划完成率”这个统计需求，所以在训练计划表里设计了status字段，回填时更新状态，首页图表统计直接读这个字段：

CREATE TABLE `rehab_training` ( `id` bigint NOT NULL AUTO_INCREMENT, `visitor_id` bigint NOT NULL, `training_type` varchar(30) NOT NULL COMMENT '运动训练/作业训练/言语训练', `plan_date` date NOT NULL, `duration` int DEFAULT NULL COMMENT '时长分钟', `status` tinyint NOT NULL DEFAULT 0 COMMENT '0待执行 1已完成 2未完成', `remark` varchar(255) DEFAULT NULL, `trainer_id` bigint DEFAULT NULL COMMENT '执行护理人员', PRIMARY KEY (`id`), KEY `idx_visitor_plan` (`visitor_id`, `plan_date`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='康复训练计划表';

网上咨询模块做成低配版工单系统：访客提交咨询问题，管理员或康复师回复，回复后状态变已回复。数据量不大，不用额外引入消息队列，表单里留一个is_reply状态字段就够。药品档案模块则更像字典管理，药品名称、规格、库存数量，再挂一个文件上传组件存说明书附件，公共文件管理模块正好复用。

首页图表展示不要单独查每个模块，而是做一个统计接口，一次返回当月入住人次、当前空房数、待缴费单数、训练完成率四个指标：

SELECT (SELECT COUNT(*) FROM rehab_visitor WHERE status = 0) AS currentVisitorCount, (SELECT COUNT(*) FROM rehab_room WHERE status = 0) AS idleRoomCount, (SELECT COUNT(*) FROM rehab_payment WHERE status = 0) AS unpaidCount, (SELECT ROUND(SUM(CASE WHEN status = 1 THEN 1 ELSE 0 END) * 100.0 / COUNT(*), 2) FROM rehab_training) AS trainFinishRate;

一个接口返回全部统计结果，前端图表组件直接渲染，省去多次请求的麻烦。

4. 常见问题排查指南：权限、状态与数据初始化最容易翻车的地方

4.1 新按钮权限不生效：前端指令和后端注解的权限码对不上

现象是管理员账号新增了一个按钮，页面看不到，但接口可以直接调，整个权限校验像黑匣子一样看不见摸不着。出现这种问题，多半是sys_menu表里按钮的perms字段和@RequiresPermission注解里的权限码不一致。比如前端用了rehab:visitor:edit，后端接口是rehab:visitor:update，两个码都存在，但不是同一个。权限码是前后端共同约定的一条链路，必须当作全局常量维护。排查办法是先按用户查权限码，确认按钮的perms是否在查询结果里，找不到就回sys_menu表数据，和前端的v-hasPermi、后端注解逐一比对，一次就能定位：

SELECT DISTINCT m.perms FROM sys_menu m JOIN sys_role_menu rm ON rm.menu_id = m.id JOIN sys_user_role ur ON ur.role_id = rm.role_id JOIN sys_user u ON u.id = ur.user_id WHERE u.username = 'admin' AND m.perms IS NOT NULL AND m.perms != '';

4.2 房间状态卡在“占用”：退房时没有同步房间状态

现象是rehab_room.status一直是 1，保洁工单没有生成，前台查询时以为房间未空出。出现这种情况基本可以断定退房流程只更新了入住记录，没有调房间状态流转。解决办法是：把入住记录关闭、房间状态更新、缴费单生成放在同一个事务方法里，任何一步失败整体回滚。修复数据时能手动用 SQL 修正，但必须保证三张表状态一致：

UPDATE rehab_stay SET status = 1 WHERE id = 1001; UPDATE rehab_room SET status = 2 WHERE id = 3; UPDATE rehab_payment SET status = 0, stay_id = 1001 WHERE id = 2001;

从此以后，只要涉及多表状态变更，先看 Service 方法有没有@Transactional，再检查代码块内的调用顺序，顺序不对也会导致状态错乱。

4.3 用户修改角色后权限没有变化：登录缓存没有刷新

现象是管理员给某个角色取消了菜单，该用户重新登录后还是能看到菜单。最直接的原因是登录时把权限集合放到了 session 或内存缓存，用户角色变更后，旧权限仍被保留。解决方式是角色授权接口里调用权限缓存清理方法，把该用户对应的缓存 key 删除，下次请求时重新加载。如果不想引入 Redis，最简单的办法是把权限放 session，角色变更后提醒用户重新登录。更优雅的做法是登录后只存 userId 到 session，权限集合每次请求时由拦截器从内存缓存查，授权变更时清空整个权限缓存，代码量很少但对毕设场景完全够用。

4.4 列表查询数据有误：MyBatis-Plus 驼峰映射没配置

现象是实体类属性叫createTime，数据库字段是create_time，查询结果全部为空但不报错。原因是 MyBatis-Plus 的map-underscore-to-camel-case配置被关闭，或者实体字段与数据库字段风格不统一。检查时先确认全局配置：

mybatis-plus: configuration: map-underscore-to-camel-case: true global-config: db-config: id-type: auto

遇到特殊字段时用@TableField注解显式声明，比如@TableField("leave_time")，避免靠命名转换猜字段。这个坑不报错，全凭数据为空来体现，排查时一定要先想到。

4.5 部署后前端 404：Vue 路由 history 模式路径无法识别

现象是本地开发一切正常，打包后放到 SpringBoot 里访问页面，刷新直接变 404。原因很典型：前端用了createWebHistory()，刷新时路径交给后端去找对应 Controller，后端找不到直接返回 404。解决方法是把路由改成 hash 模式createWebHashHistory()，或者在后端配置一个早期路由回退。毕设演示场景我推荐直接使用 hash 模式，省一层 Nginx 配置，演示时不容易出错。这些问题是每个项目几乎都会遇到的，提前准备这几段配置和 SQL，现场演示能省下很多补救时间。

5. 验收与答辩：从功能清单到现场演示的最小闭环

5.1 验收前自测的关键功能表

这张表既是自测清单，也是答辩演示的脚本框架。演示时按“新增访客 → 分配房间 → 录入训练计划 → 办理退房 → 缴费结清”一条主链走到底，比东点一个模块西点一个模块有说服力得多。

5.2 答辩高频问题与一页应对思路

导师通常会问三种问法：为什么选 Spring Boot 和 Vue；表之间关系为什么这么设计；权限控制怎么做到按钮级。应对思路用三句话：Spring Boot 和 Vue 的前后端分离更适合单人独立完成，后端只出 REST API，前端只管页面渲染；访客和房间通过入住记录表解耦，退房事务同时更新入住表、房间表、缴费表；权限控制用菜单权限码配合后端注解，后端不放行，绕过前端也拿不到数据。回答时少讲概念，多讲自己在退房事务里做了哪几步、权限码如何对齐，落地细节比背概念更能打动听者。

演示习惯比代码更重要。从第一次完整带项目起，我就要求自己无论多急都先把验收清单走一遍，再动角色账号。答辩本质上是功能可被当场验证，状态逻辑不打架。把这条链路当成不可跳过的流程固化下来，翻车概率会小很多。希望帮到你。

本文还有配套的精品资源，点击获取