企业官网建设流程全解析

1. 项目背景与课题价值

1.1 为什么选择居家养老服务系统作为毕业设计

临近毕业季，很多计算机专业的同学都在纠结选题。我见过太多人一上来就选"XX管理系统"，做完发现功能太单薄，答辩时被老师追问业务逻辑，几句话就卡壳了。居家养老服务系统这个题目，从一开始就在两个维度上占优势：业务场景真实存在，功能边界足够清晰。

先说业务场景。国内老龄化问题已经不是新闻了，居家养老、社区托养、上门护理这些概念在政策文件和新闻报道里出现的频率越来越高。换句话说，你答辩时对老师解释"我为什么要做这个系统"，三句话就能说清楚社会背景，不需要像"健身房管理系统"那样硬编一堆需求出来。老师一听就知道这个方向有意义，这是选题的第一层优势。

再说功能边界。居家养老的核心流程是"老人建档-服务预约-工单派发-服务执行-回访评价"，这是一条完整的业务链。围绕这条链，系统天然需要三类角色：管理员、服务人员（护理员/志愿者）、老人或家属。三种角色的权限不同、界面不同、操作流程不同，这正好是毕业设计要求里常说到的"多角色权限管理系统"。

1.2 这个项目适合什么样的学生

如果你满足以下任何一条，这个课题都值得重点考虑：

• 已经学过Java基础和Spring Boot基本用法，想找一个能完整覆盖"增删改查+权限+状态流转"的实战项目来充实简历；
• 平时成绩中等，但希望毕业设计能有个说得过去的亮点，不想做那种只用一张表CRUD的"管理系统"；
• 打算找工作走Java后端方向，需要一个能写进简历、面试时能聊清楚业务和技术的项目。

我带的几个学生做完这个课题之后，面试时普遍能聊到的东西包括：Spring Boot的自动配置原理、MyBatis-Plus的条件构造器用法、JWT登录鉴权的完整流程、还有"服务预约到工单派发"这种状态机思想的实现。这些东西在面试官眼里比"我做了一个博客系统"有价值得多。

2. 技术选型与架构设计思路

2.1 Spring Boot为什么是毕业设计的最优解

Spring Boot在毕业设计里几乎成了默认选项，不是没有原因的。对比传统的SSH（Spring + Struts + Hibernate）和SSM（Spring + Spring MVC + MyBatis）组合，Spring Boot最大的贡献是把配置做成了约定。

以前搭一个SSM项目，要写web.xml、spring-mvc.xml、mybatis-config.xml、applicationContext.xml，一个不小心配错一个标签，项目启动直接报错，排查半天发现是namespace写错了。Spring Boot通过自动配置把这些全干了。你只需要在pom.xml里引入spring-boot-starter-web，启动类一写，内嵌Tomcat直接跑起来。对毕业设计来说，这意味着你有更多精力放在业务代码上，而不是耗在环境配置里。

还有一点很实际：Spring Boot项目的代码结构模板化程度高，网上资料极多。你随便搜一个bug，几乎都能找到解决方案。社区活跃度高，对毕业设计这种"时间紧、任务重"的场景来说，遇到问题能快速找到答案，就是最大的效率保障。

2.2 前后端分离还是服务端渲染

我明确推荐前后端分离。理由不是跟风，而是毕业设计的实际需求决定的。

前后端分离意味着前端（Vue/React）和后端（Spring Boot）可以并行开发，你不需要等接口写完了再写页面。更重要的是，答辩演示时，前端一套代码、后端一套代码，老师问起"RESTful API设计""跨域问题怎么解决""JWT存哪里"，你都有实实在在的代码可以展示，这比说"我用了模板引擎渲染页面"要丰富得多。

当然，前后端分离也有代价：你需要额外处理跨域（CORS）、接口联调、前端打包部署这些事。但这些都是面试高频问题，做了不亏。

如果你确实不想写前端，非要用Thymeleaf这种服务端渲染模板，也能做，功能上没问题。但从毕业设计的"展示面"来看，前后端分离的项目在答辩PPT里更好讲，也更好截图展示。

2.3 项目整体技术栈参考

在我实际带的项目中，推荐的这套组合被验证过多次，稳定性很高：

我在实操时会让同学做一次技术选型对比表放进论文里，就写"为什么选Spring Boot而不是SSH/Servlet"，再说明"为什么用MyBatis-Plus而不是JPA"。这个对比表在论文"技术选型"章节里非常占篇幅，老师看了会认为你做过调研而不是胡乱选的。

3. 系统功能拆解与数据库设计

3.1 核心模块划分

居家养老服务系统的功能设计，核心是围绕"服务全流程"展开的。如果把流程画一条线，应该是这样：服务发布→老人/家属预约→管理员审核派单→服务人员接单→上门服务→回访评价。

根据这条线，我梳理出以下功能模块：

• 老人信息管理：基础档案（姓名、年龄、住址、家属联系方式）、健康档案（既往病史、常用药、过敏史）、居住信息（独居/与子女同住/社区托养点）
• 服务项目管理：服务类型（生活照料、医疗护理、康复训练、精神慰藉）、服务价格、服务时长、服务描述
• 预约与工单管理：老人提交预约单→管理员审核→生成工单→派发给服务人员→服务人员更新状态（待服务/服务中/已完成）
• 回访评价模块：服务完成后家属/老人评价，评价结果反哺到服务人员的考核数据
• 系统管理：角色管理（管理员、服务人员、老人）、菜单权限、数据字典（健康状况字典、服务类型字典）

每一个模块都对应着业务上的真实诉求，不存在"为了做功能而做功能"的情况。比如"健康档案"看着简单，但它支撑的是"服务人员上门前可以看到老人有哪些禁忌症"这个核心场景。你在论文里如果能把这个业务逻辑写清楚，就已经比很多模板化的毕业设计高出一个档次了。

3.2 数据库设计的关键表结构

数据库设计是毕业设计答辩的高频提问区。老师常见的问法是："你这个工单表为什么不直接关联老人表？""预约单和工单是一对一还是一对多？"如果没想清楚就乱建表，当场就会被问住。

下面是我用过的一套表设计核心思路，供参考：

用户表（sys_user）

老人档案表（elder_info）

注意，不要把老人档案的所有字段都堆在用户表里。用户表只负责登录和基础身份，老人扩展信息单独建表。这么设计的好处是：以后要加"医保卡号""养老补贴等级"这类字段，直接改elder_info表，不会动到用户表，降低耦合度。这个思想在答辩时很值得拿出来说。

预约工单表（service_order）

这张表是整个系统的"流程核心"，status字段的每一次流转都必须有对应的操作记录。实操时可以在表里加一个operate_log字段存JSON数组，比如[{"time":"2024-05-01 10:00","action":"提交预约"},{"time":"2024-05-01 11:30","action":"管理员审核通过"}]。这样做的好处是答辩演示时可以直接看到完整的流转历史，不用临时去翻日志。

3.3 表关系与ER图思路

表关系可以这样设计：

• sys_user 与 elder_info：一对一（一个登录账号对应一份老人档案）
• elder_info 与 service_order：一对多（一位老人可以有多个工单）
• service_item 与 service_order：一对多（一个服务项目可以被预约多次）
• sys_user（staff角色）与 service_order：一对多（一个服务人员处理多个工单）

关系设计要能说清楚"为什么"。我最常被问的就是"elder和staff都是sys_user，为什么不用一张表？"回答思路是：sys_user是身份认证的基础表，elder_info是老人业务扩展表，staff的扩展信息（如服务技能、星级评分）如果以后要加，可以为staff建独立扩展表。这是典型的"基础表+扩展表"模式，在权限系统中非常常见。

4. 核心功能实操与代码实现

4.1 项目初始化与基础配置

第一步是初始化Spring Boot项目。我建议直接用Spring Initializr（https://start.spring.io）在线生成，选Java 8、Spring Boot 2.7.x，依赖勾选Spring Web、MyBatis Framework、MySQL Driver。注意不要勾选Spring Security，毕业设计阶段用JWT+拦截器比Security更轻量，自己也能完全掌控逻辑，答辩更好讲。

pom.xml里除了基础的starter，还需要引入这几个关键依赖：

<!-- MyBatis-Plus 增强CRUD --> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3.1</version> </dependency> <!-- JWT令牌 --> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt-api</artifactId> <version>0.11.5</version> </dependency> <!-- BCrypt密码加密 --> <dependency> <groupId>org.springframework.security</groupId> <artifactId>spring-security-crypto</artifactId> </dependency> <!-- Lombok 省略getter/setter --> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency>

application.yml里几个最容易被忽略的配置：

spring: datasource: url: jdbc:mysql://localhost:3306/elder_care?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0

logic-delete-field是MyBatis-Plus的逻辑删除配置。加了这一行之后，删除操作自动变成update，数据不会真的删掉。毕业设计里强烈建议加这个，因为老人档案这种数据就算被删除也要能在后台恢复。用逻辑删除还有一个好处：操作日志里能看到完整的删除记录，答辩时万一被问"删了还能不能查回来"，直接演示恢复过程。

4.2 登录鉴权：JWT+拦截器的完整实现

登录鉴权是每一个毕业设计项目都躲不开的环节。用JWT做无状态鉴权，配合拦截器实现接口保护，是我推荐的方案。完整链路如下：

第一步：登录接口

用户提交username和password，后端调用UserService查询用户，用BCrypt校验密码。密码校验通过后生成JWT令牌，返回给前端。

public String login(LoginDTO dto) { LambdaQueryWrapper<User> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(User::getUsername, dto.getUsername()); User user = userMapper.selectOne(wrapper); if (user == null || !BCrypt.checkpw(dto.getPassword(), user.getPassword())) { throw new BusinessException("用户名或密码错误"); } return JwtUtil.generateToken(user.getId(), user.getRoleType()); }

JWT令牌生成，我用的是JJWT库，核心代码：

public static String generateToken(Long userId, String role) { return Jwts.builder() .setSubject(String.valueOf(userId)) .claim("role", role) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() + 1000 * 60 * 60 * 24)) .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact(); }

这里有个细节：setExpiration时间设置成1天。太短会导致用户频繁重新登录，太长则有安全风险。1天的过期时间在演示场景下完全够用，答辩时也可以说"这是一个可调的配置参数"。

第二步：拦截器校验

写一个JwtInterceptor，实现HandlerInterceptor接口，在preHandle方法里解析请求头中的Authorization字段。

public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String token = request.getHeader("Authorization"); if (token != null && token.startsWith("Bearer ")) { token = token.substring(7); try { Claims claims = JwtUtil.parseToken(token); request.setAttribute("userId", claims.getSubject()); request.setAttribute("role", claims.get("role")); return true; } catch (Exception e) { response.setStatus(401); return false; } } response.setStatus(401); return false; }

注册拦截器，同时放行登录接口和静态资源：

@Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new JwtInterceptor()) .addPathPatterns("/api/**") .excludePathPatterns("/api/auth/login", "/api/auth/register"); }

第三步：角色权限控制

仅仅有登录态还不够，不同角色能访问的接口必须区分。我用的是自定义注解+拦截器的方式：

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

然后在Controller方法上加注解：

@RequireRole({"ADMIN"}) @PostMapping("/elder") public Result addElder(@RequestBody ElderInfo elder) { elderService.save(elder); return Result.success(); }

拦截器里根据注解要求比对当前用户的角色，不匹配就返回403。这个方案比Spring Security的@PreAuthorize简单直观，代码量少，而且答辩时你能把整个"校验角色"的逻辑一条条讲清楚，不会因为框架封装太深而答不上来。

4.3 预约工单状态流转的实现

预约工单是整个居家养老系统的核心业务流程。我在代码里用的不是简单的if-else，而是状态枚举+流转校验的方式，这个设计在答辩时非常加分。

先定义状态枚举：

public enum OrderStatus { PENDING(0, "待审核"), APPROVED(1, "已审核待派单"), ASSIGNED(2, "已派单"), IN_PROGRESS(3, "服务中"), COMPLETED(4, "已完成"), CANCELED(5, "已取消"); private final int code; private final String desc; }

流转校验用Map预定义合法状态迁移路径：

private static final Map<OrderStatus, List<OrderStatus>> TRANSITIONS = new HashMap<>(); static { TRANSITIONS.put(PENDING, Arrays.asList(APPROVED, CANCELED)); TRANSITIONS.put(APPROVED, Arrays.asList(ASSIGNED, CANCELED)); TRANSITIONS.put(ASSIGNED, Arrays.asList(IN_PROGRESS, CANCELED)); TRANSITIONS.put(IN_PROGRESS, Arrays.asList(COMPLETED)); }

工单状态更新时做校验：

public void updateStatus(Long orderId, OrderStatus targetStatus) { ServiceOrder order = orderMapper.selectById(orderId); OrderStatus current = OrderStatus.fromCode(order.getStatus()); if (!TRANSITIONS.get(current).contains(targetStatus)) { throw new BusinessException("非法状态流转：" + current.getDesc() + " → " + targetStatus.getDesc()); } order.setStatus(targetStatus.getCode()); orderMapper.updateById(order); }

这种设计能防止很多低级错误，比如"服务中"直接跳到"已完成"没问题，但从"待审核"直接跳到"已完成"就说明数据有问题。你把Transfer Map打印出来贴在论文里，老师一眼就能看出你理解了业务流程。

4.4 服务人员与老人双向绑定逻辑

有些同学做这个系统时容易忽略一个业务细节：不是任何服务人员都能接任何订单。如果老人需要的是医疗护理服务，而你随便派了一个只做过生活照料的护工，业务上是不合理的。

我的实现方案：在staff_info表里加一个skill_type字段，存储能提供的服务类型ID列表（用逗号分隔，如"1,2,3"）。管理员派单时，系统自动筛选出符合条件的服务人员，只从这些人里选：

public List<StaffInfo> getAvailableStaff(Long serviceItemId) { LambdaQueryWrapper<StaffInfo> wrapper = new LambdaQueryWrapper<>(); List<StaffInfo> all = staffInfoMapper.selectList(wrapper); return all.stream() .filter(staff -> Arrays.asList(staff.getSkillType().split(",")) .contains(String.valueOf(serviceItemId))) .collect(Collectors.toList()); }

这个小功能实现起来不过二十行代码，但体现了你对业务的理解。答辩时讲"系统为什么要筛选可用服务人员"，比讲"我的CRUD写得多么流畅"要有说服力得多。

5. 常见问题与排查技巧实录

5.1 启动报错：端口被占用

这是毕业设计阶段最常遇到的第一个拦路虎。运行Spring Boot项目时，控制台报Port 8080 was already in use。

排查思路分三步：

1. 命令行查看谁占了8080端口：

netstat -ano | findstr :8080

2. 找到PID后，在任务管理器里结束对应进程，或者再执行taskkill /PID 进程号 /F。
3. 如果8080是你的常用端口不想动，也可以直接在application.yml里改：

server: port: 8081

实操心得：如果同一个端口反复被占，多半是你之前启动的后端项目没被正确停止。在IDEA里点红色停止按钮有时候会失效，最好是在终端里Ctrl+C，或者用taskkill把java进程清干净再重启。

5.2 数据库连接失败：Access denied for user

这个报错大概率是用户名密码不对。最常见的原因是：MySQL安装时设置了密码，但application.yml里没改；或者密码改了新的，application.yml里还是旧的。

排查路径：

• 先确认MySQL服务有没有启动（Windows下可以在"服务"里查MySQL服务状态）；
• 再到MySQL命令行里用配置文件里的账号密码试登录；
• 如果密码真忘了，用mysqld --skip-grant-tables跳过权限表登录后重置密码。

这里有个技巧：配置文件里的密码建议写本地的root密码，不要为了"统一"在代码里写一个demo密码。因为毕业设计演示现场，如果老师的设备连不上你的数据库，场面会很难看。提前在自己机器上把环境跑通，是最笨也最有效的方法。

5.3 MyBatis-Plus自动填充失效问题

在做老人档案和时间字段时，我习惯用自动填充来写创建时间和更新时间。万一自动填充不生效，常见原因就两个：

• 实体类的@TableField(fill = FieldFill.INSERT)没写对；
• 自定义的MetaObjectHandler没有被Spring扫描到。

检查MetaObjectHandler是否被扫描，方法是在启动类上确认扫描包路径，或者在MetaObjectHandler类上加@Component注解。这是最常被忽略的一步。

@Component public class MyMetaObjectHandler implements MetaObjectHandler { @Override public void insertFill(MetaObject metaObject) { this.strictInsertFill(metaObject, "createTime", LocalDateTime.class, LocalDateTime.now()); this.strictInsertFill(metaObject, "updateTime", LocalDateTime.class, LocalDateTime.now()); } @Override public void updateFill(MetaObject metaObject) { this.strictUpdateFill(metaObject, "updateTime", LocalDateTime.class, LocalDateTime.now()); } }

5.4 跨域请求被拦截：CORS 403

前后端分离的经典问题。前端Vue项目跑在8080，后端Spring Boot跑在9090，浏览器直接拦截跨域请求。

我的处理方式是用一个配置类统一解决：

@Configuration public class CorsConfig { @Bean public CorsFilter corsFilter() { CorsConfiguration config = new CorsConfiguration(); config.addAllowedOrigin("http://localhost:8080"); config.addAllowedMethod("*"); config.addAllowedHeader("*"); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration("/**", config); return new CorsFilter(source); } }

注意：setAllowCredentials(true)和addAllowedOrigin("http://localhost:8080")必须配合使用。如果Origin写的是*，且Credentials为true，前端带Cookie请求会被浏览器拦住。我自己踩过这个坑，排查了半小时才发现是这里的问题。

5.5 部署到服务器出现的静态资源404

很多同学做完项目后喜欢打包成jar发到云服务器上。Spring Boot的jar包默认会从classpath下读取static目录里的静态资源。如果你用的是Vue打包后的dist文件，需要把dist目录内容拷贝到src/main/resources/static下再打包。

常见404原因是：Vue的history模式路由需要后端做fallback配置。否则你直接访问http://ip:8080/login会404，只有访问根路径才能看到页面。

配置方法：

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addViewControllers(ViewControllerRegistry registry) { registry.addViewController("/{spring:\\w+}").setViewName("forward:/index.html"); } }

这行配置的作用是：所有非静态资源路径的请求都转发到index.html，由前端路由接管。没有这行配置，前后端分离项目打包部署后刷新页面就白屏，这是实践中最容易翻车的点。

6. 论文与答辩准备的增强建议

6.1 论文结构怎么组织更容易过

论文章节和系统功能能不能对应上，决定了评审老师翻论文时的第一印象。我推荐的章节结构非常直白：

• 第一章 绪论：写老龄化背景、国内外研究现状，控制在8-10页
• 第二章 需求分析：画用例图，每个角色写功能需求和非功能需求
• 第三章 系统设计：架构图 + 功能模块图 + 数据库ER图 + 核心表结构说明
• 第四章 系统实现：按功能模块写，每个模块配核心代码片段和截图
• 第五章 系统测试：功能测试用例表 + 性能测试简要说明

这里有个讨巧的小操作：把JWT鉴权流程和工单状态流转设计单独列成小节。这两个点属于"有技术深度、可展开讲解、能体现个人工作量"的内容。评审老师最喜欢看到有挑战性的内容，而不是全程在写增删改查。

6.2 答辩时如何讲清楚项目亮点

答辩时间通常在5-10分钟，撑起这个时间的核心不是PPT，而是"你做了什么别人没做的事"。我在指导学生答辩时，一般会让他们准备三个必讲亮点：

亮点一：多角色权限控制。三个人（老人/服务人员/管理员）看到的是完全不同的菜单和接口。要用"登录后返回的token里包含角色信息，前端根据角色渲染不同菜单，后端拦截器根据角色限制接口访问"这条链路来讲。

亮点二：预约工单的完整状态流转。从老人下单到管理员审核、派单、服务、完成、评价，每一步都有据可查。配合我前面提到的状态枚举和流转校验，这条业务流程线就是你的"护城河"。老师问"你是怎么防止非法操作的"，直接甩状态机设计。

亮点三：数据库表的解耦设计。用户表和老人档案表拆开，工单表统一关联多张业务表。就这三个点，足以撑起五分钟的问答。

6.3 给初学者的实操时间计划

如果从现在开始做，每周投入10-15小时，整体节奏可以控制在6-7周：

• 第1周：选题确认 + 需求分析 + 数据库SQL写出来
• 第2周：Spring Boot项目搭建 + 登录注册 + JWT鉴权
• 第3周：老人档案模块 + 服务项目管理
• 第4周：预约工单模块 + 派单逻辑
• 第5周：回访评价模块 + 数据统计
• 第6周：前端页面联调 + 完善细节
• 第7周：写论文 + 做PPT + 模拟答辩

前端页面如果自己写Vue比较吃力，不用硬撑。找到一个靠谱的前端模板（Element UI + Vue管理后台模板非常多），能极大节省时间。毕业设计的核心是后端业务逻辑，前端能用、能演示就行，不用追求视觉惊艳。

7. 项目的后续扩展方向

做完了基础功能，如果有余力，还有几个方向可以让项目再上一个台阶。这些扩展不用全部做完，挑一个做进去，就能让项目从"作业级"提升到"作品级"。

方向一：健康数据的可视化看板

老人健康档案不只是存储，可以增加健康指标的录入和趋势图展示。比如近期血压、血糖的变化曲线。技术实现上用ECharts画折线图，后端提供一个查询接口，按时间范围返回数据。这个功能实现成本不高，但演示效果非常好，屏幕上一放，老人健康变化一目了然。

方向二：服务评价的星级统计与人员考核

把回访评价数据做聚合分析。服务人员模块展示每个人的平均评分、服务单数、好评率。注意service_order表里加一个rating字段（1-5星），评价表里加评价内容和评价时间。答辩时老师问"你怎么管理服务质量"，你就有数据支撑了。

方向三：定时任务实现服务前提醒

Spring Boot的@Scheduled注解可以轻松实现定时任务。比如每天早上8点，扫描当天有预约工单的服务人员，发送短信或站内信提醒。这涉及"定时任务"这个独立的技术点，放在论文里是一个很好的补充章节。

扩展功能不用贪多，做一个嵌入现有系统，做透做完整，价值远大于做三个半吊子的功能。

最后说句实在话：居家养老服务系统这个题目，市面上公开的源码不少，网上甚至能找到完整的答辩PPT和论文模板。但如果你只是把源码down下来改个名字交上去，答辩时候老师随口问一个"你这个状态为什么从待审核直接跳到已完成"，你就卡壳了。花时间把每一个流程、每一张表、每一个接口的来龙去脉搞清楚，让源码真正变成你的东西，这个毕业设计做得才算值。