企业官网建设流程全解析

又到了毕业设计的季节，很多计算机专业的同学都在纠结选题。如果你正在找一个“难度适中、业务清晰、好答辩”的Web项目，Java + SpringBoot 实现的敬老院管理系统确实是个很划算的选择。这个题目听起来不大不小，但里面装的东西一点都不少：老人档案管理、护理记录、房间分配、费用收缴、亲属来访、员工排班，甚至还能接一个简单的统计看板。业务场景足够真实，技术栈又能把 Java、SpringBoot、MyBatis-Plus、MySQL 这些面试常问的东西全部串起来。这篇文章我按自己当年做这类管理系统的思路，把整个项目的设计、核心代码、踩坑记录全部拆开讲一遍，希望能给正在做毕设或者想练手 Web 开发的你一些能直接用的东西。

要说清楚这个项目到底值不值得做，得先弄明白一个问题：敬老院管理系统本质上是什么？往大了说，它是一套典型的企业级信息管理系统（MIS）；往小了说，它就是“增删改查 + 权限 + 报表”的组合。但正因为业务本身不复杂，你才有精力把代码质量、表结构设计、功能完整性做到位，而不是被业务逻辑绕晕。这套系统的核心用户其实只有三类：管理员（院长/系统管理员）、护工/护士、前台财务。每个角色关心的事情完全不一样，这直接决定了你的功能模块和数据库表应该怎么设计。

1. 项目定位与整体思路拆解

1.1 这个系统真正在解决什么问题

很多人一上来就闷头写代码，写了一半才发现不对。做毕设也好，做项目也罢，第一步永远是搞清楚“给谁用、用在哪、解决什么痛点”。敬老院管理系统的关键矛盾点有三个。

第一个矛盾是信息孤岛。老人的基本信息、家属联系方式、健康档案、用药记录、缴费记录，如果都散落在纸质档案和 Excel 表里，查找一份资料可能要在文件柜里翻半天。系统要解决的就是把这些分散的信息集中到一个平台里，检索、更新、导出一气呵成。

第二个矛盾是护理过程不可追溯。养老行业最敏感的就是“老人出事了说不清楚”。几点查房、几点喂药、当天精神状态怎么样、有没有异常情况，这些必须留痕。所以护理记录模块不是简单记一笔，而是要形成一条完整的时间线，谁在什么时间做了什么操作，系统里全部能查出来。这也是答辩时最容易被问到的亮点。

第三个矛盾是费用管理混乱。入住费、护理费、伙食费、医疗费，各种费用项目繁杂，手工算账容易出错。系统里需要一张清晰的费用流水表，每一笔钱都有来源、有去向、有经手人，月底统计对账直接导出明细，财务和领导都省心。

1.2 为什么技术栈锁定 Java + SpringBoot

选技术栈这件事，务实比炫技重要。市面上做管理系统的方案很多，Python 的 Django/Flask、Node.js 的 Express、PHP 的 Laravel 都能做，但作为计算机专业的毕设，Java + SpringBoot 依然是性价比最高的选择，原因非常实际。

第一，Java 依然是国内企业级应用的主力语言，你用这个技术栈做毕设，面试的时候聊起来最自然。面试官看到 SpringBoot 项目不会觉得陌生，问的问题也都有标准答案，你准备起来有方向。

第二，SpringBoot 把繁琐的配置几乎清零了。早些年用 SSM（Spring + SpringMVC + MyBatis）搭环境，光是 XML 配置文件就能写几十行；现在 SpringBoot 通过自动配置和起步依赖，一个注解加上几行配置就能跑起来。这意味着你能把精力放在业务实现上，而不是跟配置死磕。

第三，生态太成熟了。MyBatis-Plus 操作数据库一条 SQL 都不用写，Spring Data JPA 也能快速 CRUD，前端随便配个 Thymeleaf 或者 Vue 都行，部署打包一个 jar 文件就搞定。这些成熟的组件组合起来，让一个人在一两个月内完成一个功能完整的系统完全可行。

提示：如果你 Java 基础不太好，强烈建议选 MyBatis-Plus 而不是 JPA。MyBatis-Plus 的语法更接近你学过的 SQL 思维，写起来直观，排查问题也容易。JPA 的关联映射虽然省事，但封装太狠，报错的时候你根本看不懂它在干什么。

2. 核心技术选型与模块规划

2.1 技术栈逐项说明与版本选择

我做这套系统时用的技术栈清单如下，每一项都是经过实际检验的稳妥组合。

关于版本这件事，多说一句：千万不要一上来就追最新的 SpringBoot 3.x。SpringBoot 3.x 强制要求 JDK17，而且把javax.*改成了jakarta.*，很多网上教程里的代码直接复制过来是编译不过的。毕设求稳，用 SpringBoot 2.7.x + JDK8 或者 JDK11，遇到问题搜资料一搜一大把，省下的时间多睡几觉不好吗。

2.2 核心业务模块划分与数据表设计思路

模块划分是系统的骨架，我的习惯是先画思维导图，把角色和功能理清楚再动手建表。敬老院管理系统我把它拆成了六个核心模块。

系统管理模块：员工账号管理、角色权限分配、登录日志。这个模块管的是“谁能进系统、进去能干什么”。

老人档案模块：老人基本信息、家属联系人、入住登记、退住办理、档案增减改查。这是整个系统的数据核心，几乎所有模块都要跟它关联。

住宿管理模块：房间信息、床位分配、调房记录。房间有不同类型（单人间、双人间、套间），状态有“空闲、已入住、维修中”，分配床位时要自动校验容量。

护理管理模块：护理等级设定、每日护理记录、用药提醒、健康体检数据。老人入住时会评估一个护理等级（自理、半自理、全护理），不同等级对应不同的护理内容和收费标准。

费用管理模块：费用项目配置、月度账单生成、缴费登记、欠费提醒。费用逻辑是：系统根据入住时长和所选服务自动算钱，财务只负责确认和登记收款。

统计看板模块：入住率统计、护理任务分布、月度营收趋势、老人年龄段分布。这些图表数据用 ECharts 展示非常出效果，答辩演示时加分明显。

数据库表我建议这样设计（这是多张核心表的简化结构）。

• admin_user（管理员/员工表）：id、username、password（BCrypt加密）、real_name、role、phone、status
• elder_info（老人信息表）：id、name、gender、birthdate、id_card、health_status、care_level、room_id、check_in_date、status
• family_contact（家属联系表）：id、elder_id、name、relation、phone、address
• room_info（房间信息表）：id、room_no、room_type、bed_count、used_count、status、floor
• nursing_record（护理记录表）：id、elder_id、staff_id、record_date、content、temperature、blood_pressure、remark
• payment_record（缴费记录表）：id、elder_id、item_name、amount、pay_date、pay_type、operator
• medication_plan（用药计划表）：id、elder_id、drug_name、dosage、frequency、start_date、end_date

这里特别注意一点：表与表之间的关联字段只用id，不要用业务字段比如身份证号来做外键，这样既能保证灵活性，也能避免误操作把关联数据改坏。

3. 核心功能模块的实现细节

3.1 登录鉴权与员工权限设计

登录是一个系统的门面，也是**答辩时老师几乎必问“你是怎么控制权限的”**的地方。我用的是 JWT（JSON Web Token）方案，流程很清晰。

用户提交用户名密码，后端校验通过后签发一个 token，前端把 token 存在本地，之后每次请求都在请求头里带上。后端通过拦截器统一解析 token，拿到当前用户的 id 和角色，然后判断这个请求路径当前角色能不能访问。

JWT 生成的核心代码其实不复杂，我用的是io.jsonwebtoken这个库。

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

拦截器解析 token 我就直接贴关键逻辑了。

@Component public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); if (token != null && token.startsWith("Bearer ")) { token = token.substring(7); try { Claims claims = Jwts.parser() .setSigningKey(secretKey) .parseClaimsJws(token) .getBody(); request.setAttribute("userId", Integer.parseInt(claims.getSubject())); request.setAttribute("role", claims.get("role")); return true; } catch (Exception e) { response.setStatus(401); return false; } } response.setStatus(401); return false; } }

角色的权限控制我用一个简单的思路：在配置类里把路径和管理员、普通员工的映射关系定义好，比如/admin/**必须是管理员权限，/nursing/**护工可以访问，/finance/**财务才能访问。

这里有个隐藏加分项：密码不要明文存储。用BCryptPasswordEncoder加密后再存入数据库，即使数据库泄露，密码也不是裸的。答辩时老师说“你这个密码加密了没有”，你直接说用了 BCrypt，分分钟变成加分点。

3.2 老人档案与入住管理实现

老人信息是整个系统的核心实体，设计的时候要考虑它和房间、家属、护理计划的关联关系。我用 MyBatis-Plus 建实体的时候，会加上@TableName、@TableId，字段就按数据库表一一对应。

老人信息的录入和编辑不建议做成“一个表单搞定所有”，因为老人的字段太多、太杂。我当时的做法是分步骤表单：基本信息一步、健康信息一步、家属信息一步，最后确认提交。这样用户体验好，代码逻辑也清楚。前端用 Vue 的话就是<el-steps>组件，然后用变量控制当前显示哪一步。

入住管理有一个细节很容易漏：老人入住时，不仅要插入老人记录，还要更新房间的已住人数，同时生成一条入住状态变更历史。这三个操作涉及三张表，必须放在同一个事务里。我当时就踩过这个坑，老人入住成功了，房间状态没更新，前台看到空房间又安排了一个人进来，直接搞出“一房两住”的乌龙。后来用@Transactional把三个操作包到一起才解决。

@Transactional(rollbackFor = Exception.class) public Long checkInElder(ElderInfo elder, Integer roomId) { // 1. 查询房间，校验是否已满 RoomInfo room = roomMapper.selectById(roomId); if (room.getUsedCount() >= room.getBedCount()) { throw new BusinessException("该房间已住满"); } // 2. 插入老人信息 elderMapper.insert(elder); // 3. 更新房间已住人数 room.setUsedCount(room.getUsedCount() + 1); roomMapper.updateById(room); // 4. 记录入住历史 checkinHistoryMapper.insert(new CheckinHistory(elder.getId(), roomId)); return elder.getId(); }

3.3 护理记录和健康数据的处理

护理记录这个模块，业务上最敏感，代码上却最直接——说白了就一个带多条件查询的 CRUD。但我想聊聊数据设计层面的一个优化：老人每月可能有 30 条护理记录，加上量血压、测体温，一年下来数据量不小。如果每次列表页都全表扫描，性能会有点难看。当时我用了 MyBatis-Plus 的分页插件，再加上(elder_id, record_date)联合索引，查询速度完全没问题。

分页插件的配置很简单，在配置类里加一个 bean 就行。

@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }

查询语句也不需要手写，直接调 MyBatis-Plus 的Page方法。

public Page<NursingRecord> getNursingRecords(int page, int size, String elderName, String date) { Page<NursingRecord> p = new Page<>(page, size); LambdaQueryWrapper<NursingRecord> wrapper = new LambdaQueryWrapper<>(); if (StringUtils.hasText(elderName)) { wrapper.like(NursingRecord::getElderName, elderName); } if (StringUtils.hasText(date)) { wrapper.eq(NursingRecord::getRecordDate, date); } wrapper.orderByDesc(NursingRecord::getRecordDate); return nursingRecordMapper.selectPage(p, wrapper); }

需要注意的一点是时间字段的格式问题。MySQL 的datetime类型传到前端会变成2025-01-05T10:30:00这种格式，跟页面上的2025-01-05 10:30:00对不上。这是前后端联调时最常遇到的问题。解决办法也很简单：在实体类字段上加上注解，或者配置一个全局的 Jackson 格式化。

@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT+8") private LocalDateTime createTime;

3.4 费用自动计算与统计看板

费用模块是“看起来简单、做起来麻烦”的典型。麻烦在哪儿呢？入住时间不一定是整月、护理等级中途会变、调房会导致费用标准变化，这些都会让“一键生成月度账单”变得没那么简单。

我当时的实现逻辑是：每月 1 号跑一个定时任务，遍历所有在住老人，根据其当前护理等级和房间类型，查对应的价目表，然后计算当月应收金额并按天折算。如果月中调房或者升级护理，就按比例切分。计算结果生成一条payment_record记录，状态为“待缴费”。

用 SpringBoot 的@Scheduled注解就能轻松实现定时任务。

@Component public class BillGenerateTask { @Scheduled(cron = "0 0 2 1 * ?") // 每月1号凌晨2点执行 public void generateMonthlyBills() { List<ElderInfo> elders = elderMapper.selectList( new LambdaQueryWrapper<ElderInfo>().eq(ElderInfo::getStatus, "入住")); for (ElderInfo elder : elders) { // 根据护理等级和房间类型计算费用 BigDecimal amount = calculateAmount(elder); paymentMapper.insert(new PaymentRecord(elder.getId(), amount, "月度费用", "待缴费")); } } }

统计看板这块，我推荐用 ECharts 来做图表。它支持按天、按月统计营收、入住率等数据，前端配置一个折线图加一个饼图，逼格瞬间上来。后端只需要提供一个聚合查询接口，用 SQL 按时间分组统计即可，也可以用 MyBatis-Plus 的 QueryWrapper 实现简单的分组查询。答辩演示的时候，打开统计页面，看到图表动起来，老师第一印象就好。

4. 从零搭建到运行：完整实操过程

4.1 环境版本选型与踩坑前置

很多同学的第一个坑不在写代码，而在环境搭建。我强烈建议你在动手之前先确定好版本矩阵，然后一次性装齐，不要边写边装。

我这次用的版本组合是：JDK 8、Maven 3.8.6、SpringBoot 2.7.18、MyBatis-Plus 3.5.3、MySQL 8.0.32。为什么选这些老版本我心里有数——这组合已经被无数人验证过了，你踩的坑早有人替你踩平了，搜解决方案一搜一大把。

IDEA 创建项目时选择 Spring Initializr，然后勾选 Web、MySQL Driver、MyBatis 这几个依赖，再手动加上 MyBatis-Plus 的 starter 就行。注意 MyBatis-Plus 和 SpringBoot 版本要兼容，我用的坐标是：

<dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3.2</version> </dependency>

application.yml的基本配置如下，数据库连接串注意加上useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai，否则中文乱码和时区错乱会折腾到你怀疑人生。

server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/elder_care?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: id-type: auto

4.2 数据库初始化与测试数据准备

数据库脚本不要手动一条条敲，直接用 Navicat 建好库之后，把建表语句和图解生成出来。这里我推荐一个效率技巧：用 MyBatis-Plus 的代码生成器反向生成实体类、Mapper、Service、Controller。它可以根据数据库表直接生成全套代码，省去机械劳动，你集中精力改业务逻辑就行。

要注意的是，生成之后必须检查两件事：第一，连表查询的 DTO 不要用自动生成的实体类顶替，最好单独建 VO 对象，避免把不需要的字段暴露到前端；第二，逻辑删除字段（比如deleted）在实体上要加@TableLogic，这样 MyBatis-Plus 执行删除时自动转成UPDATE ... SET deleted = 1，而不是真的 DELETE，数据安全性高一个档次。

测试数据这块，我当时写了一个简单的数据初始化类，配置了一些常用的老人档案、房间信息、护理记录。答辩演示时你总不能现场往数据库里手工录数据吧。生成 20-30 条模拟数据，后面写统计看板也有内容可展示。

4.3 后端分层写法与统一返回格式

后端代码我按经典的四层结构来写：Controller（接收请求）、Service（业务逻辑）、Mapper（数据访问）、Entity/VO（数据载体）。这个结构是 Java 面试的基本盘，也是答辩老师默认的期望结构。

不管是查询还是新增，统一返回格式会让前后端联调省不少事。我定义了一个 Result 类：

@Data public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> r = new Result<>(); r.setCode(200); r.setMessage("操作成功"); r.setData(data); return r; } public static <T> Result<T> error(String msg) { Result<T> r = new Result<>(); r.setCode(500); r.setMessage(msg); return r; } }

Controller 层所有接口都返回Result<?>，前端统一判断code === 200再取数据。这样做的好处是错误处理集中化，不用每个接口单独写一堆 if-else。

4.4 前端方案的两种选择与打包部署

前端我有两个方案给你参考。

方案一：服务端渲染，用 Thymeleaf 模板。适合前端基础不太好的同学，直接在 HTML 里写${}取后端数据，表单提交用th:action，不用解决跨域，整个项目就是一个 jar 包，部署非常省心。

方案二：前后端分离，用 Vue 3 + Vite + Element Plus，后端只提供 JSON API。这个方案的视觉效果和专业度明显更高，页面美观、交互流畅，答辩时很加分，但你需要额外解决跨域问题（后端配置CorsFilter即可），部署时要把 Vue 构建出来的dist目录扔进 SpringBoot 的static目录下，变成一个 jar 包运行。

我的建议是：如果时间有限、前端水平一般，选方案一；如果离答辩还有 3 周以上、想冲刺一个更好的呈现效果，选方案二。两个方案我都在自己的机器上跑通了，方案二的跨域配置其实也就几行代码。

@Configuration public class CorsConfig { @Bean public CorsFilter corsFilter() { CorsConfiguration config = new CorsConfiguration(); config.addAllowedOriginPattern("*"); config.addAllowedHeader("*"); config.addAllowedMethod("*"); UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration("/**", config); return new CorsFilter(source); } }

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

5.1 高频故障速查表

我把自己做项目时真实遇到过的、以及身边同学反复问过的问题整理成了一张速查表，建议先收藏。

5.2 最容易让人崩溃的 SpringBoot 版本陷阱

这个必须单独讲一下，因为方向错了努力白费。SpringBoot 3.x 发布之后，搜索引擎里排前面的博客、文章好多都是新版本的内容，你一搜“SpringBoot 整合 MyBatis-Plus”，搜出来的教程大概率是 3.x 版本的，里面用的jakarta.*包名和 JDK17，你拿 JDK8 一编译，直接报package javax.servlet does not exist。这时候千万不要慌，也不要顺手把 JDK 升级到 17，而是回到官网或者查依赖版本对应关系，把 SpringBoot 稳定在 2.7.x，然后找一个明确标注支持 2.x 的教程。

另外一个容易踩的坑是SpringCloud 和 SpringBoot 版本强绑定。如果你后续想加一点微服务的概念进项目里（比如服务注册发现），一定要先查清楚 SpringCloud 的版本对应的 SpringBoot 版本，否则启动直接报IllegalArgumentException或者找不到配置类。毕设阶段我建议不加微服务，除非老师明确要求，否则 SpringBoot 单体应用完全够用。

5.3 业务上的隐蔽逻辑 Bug

这类 Bug 不会让程序报错，但会让数据变得不合理，属于“运行时逻辑错误”，更难发现。我列三个典型的。

第一个是并发入住同一房间。两个人同时在前台操作，都看到 3 人间只剩 1 个空位，同时录入，结果入住人数变成 4。解决办法是给room_info表加一个带条件的更新操作：

UPDATE room_info SET used_count = used_count + 1 WHERE id = ? AND used_count < bed_count

然后检查受影响行数，如果为 0 就提示“房间已满”。

第二个是退住时没有检查费用结清。老人退住之前必须把所有欠费交完，否则账目就乱了。退住接口里要写一个校验逻辑，存在未缴账单就禁止退住操作。

第三个是删除家属联系人的级联问题。老人档案删除了，家属表里的记录还残留着，下次查老人的时候数据已经没了，但家属变成了“孤儿数据”。在删除老人的方法上加上事务，同时删除关联家属、护理计划，或者设置@TableLogic让它们随主记录一同“假删除”。

6. 写在最后的经验体会

花了几千字把这个项目从头到尾拆了一遍，最后说几句掏心窝的经验。

毕设项目不是越大越好，而是越完整越好。一个能正常运行、功能闭环、代码清晰、答辩能讲出设计思路的敬老院管理系统，在一众还没跑通的项目里已经是很能打的存在了。封装要适度，不要为了“显得高级”硬上微服务、分布式、消息队列，这些东西如果没有真实场景支撑，答辩反而容易被问穿。

做项目的时间分配也很重要。我见过太多人把 80% 的时间花在搭环境和调样式上，最后没时间写核心业务逻辑。正确的节奏是：花一周把环境和数据库搭好，两周把后端核心接口写完，一周做前端页面对接，最后留一周专门处理各种边界情况和打磨演示流程。答辩时最重要的不是代码写得有多花哨，而是你能打开系统，把“登录-录入老人-分配房间-添加护理记录-生成账单-查看统计”这条主流程一气呵成地走下来，把每一步的设计思路讲清楚。

最后一个小技巧：提前准备一份演示数据脚本，把答辩用的账号、密码、典型业务场景都预设好。我当年就是靠着一份精心准备的演示脚本，在系统被临时清库的情况下，三分钟就把完整流程演完，评委老师全程没有打断。

如果你正在做类似的系统，希望这篇文章能帮你少走几步弯路。遇到具体问题，欢迎分享你的报错信息，我们一起讨论。