企业官网建设流程全解析

最近后台收到不少私信都在问同一个题目：SpringBoot+Vue的大健康养老公寓管理系统到底怎么从零落地。我手头正好有一套完整跑通的项目源码，连带SQL脚本和接口文档都整理好了，前后端加起来花了不少精力打磨，干脆把整个拆解思路、表结构设计、接口规划、联调踩坑全部写出来，帮正在做Java Web毕设的同学省几个通宵的debug时间。

这套系统的核心是解决养老公寓里"人、房、健康、护理"四件事。人指入住老人、家属、护工、管理员这几类角色；房指床位和房间分配，老人入住、退住、换房调床都牵扯到床位状态；健康指老人每天的体征数据、体检记录、慢病档案、用药计划，这部分是"大健康"定位的关键；护理对应护工排班、护理任务、异常事件上报。四件事耦合在SpringBoot+Vue的前后端分离架构里，后端提供RESTful接口，前端用Vue Router管理页面路由、Axios调接口、Element UI做界面，数据库走MySQL，SQL脚本把建库、建表和初始化数据一次搞定。

这篇内容适合三类人：正在找Java Web毕设模板的学生，想快速搭一套公寓管理后台的开发者，以及准备把项目写进简历但还没完全搞懂各模块怎么连起来的人。我会从架构讲起，一直讲到SQL脚本的表结构、接口文档的写法、本地部署的具体命令，最后把实际跑项目常遇到的10个高频问题列出来，照着排查基本都能解决。

1. 项目核心思路与架构选型

1.1 大健康养老公寓系统管的是哪几本"账"

在做表结构之前，先得把业务盘清楚。很多毕设翻车的根本原因不是代码写不出来，而是业务模型没想明白，老人入住之后房间怎么流转、健康记录怎么关联、护理任务怎么生成，全糊在一起。

我按角色视角拆了一遍，这套系统至少得覆盖五条业务主线。第一，老人档案主线：从申请入住、健康评估、登记基本信息、安排房间床位，到入住后的营养膳食偏好、家属联系方式、紧急联系人，全流程都要有记录。第二，健康档案主线：老人的体检报告、既往病史、过敏史、慢病管理（高血压、糖尿病这类需要长期跟踪的病）和每天的体征记录，包括血压、血糖、心率、体温。第三，护理任务主线：护工排班后产生护理任务，任务要有执行状态，做完要回填记录，异常情况要能上报。第四，床位管理主线：房间有类型、朝向、楼层，床有编号、状态，状态要能在"空闲、占用、维修、预定"之间流转，这直接关联费用。第五，费用与运营主线：老人每月的床位费、护理费、餐饮费生成账单，要有缴费记录，也要支持退费。

每条主线单独看不算复杂，但它们彼此关联。比如老人入住时要把床位状态从"空闲"改成"占用"，健康档案里的慢病信息要能推送到用药计划模块，护理任务的生成又依赖于排班表。这些关联关系定下来，数据库的ER模型也就顺理成章了。实际项目里这条链条想清楚，后端的Mapper查询和前端的数据联动都不会乱。

1.2 为什么SpringBoot+Vue是Java Web毕设最舒服的搭配

选型这件事，每年都有人纠结用SSH还是SSM、用JSP还是FreeMarker。我的观点很直接：如果目标是快速、稳定、能讲清楚、又能作为简历亮点，SpringBoot+Vue前后端分离是当下最稳的组合。

SpringBoot最大的价值在于"约定大于配置"，内嵌Tomcat、自动装配、引入依赖后基本不需要写XML配置，用spring-boot-starter-web、spring-boot-starter-mybatis、spring-boot-starter-validation这几个起步依赖就能把项目骨架搭起来。对毕设来说，减少配置步骤意味着把时间留给业务代码，而不是耗在配置文件报错上。

Vue这边的优势是渐进式引入、组件化开发、生态成熟。Element UI组件库把表格、表单、弹窗、分页这些后台管理系统高频组件全部封装好了，前端开发量直接砍半。Vue Router负责页面跳转，Vuex或Pinia管理登录状态和全局数据，Axios统一发请求、拦截响应，这套组合在中小型管理系统里属于相当成熟的实践。

前后端分离还带来一个隐藏好处：它天然要求你把接口定义清楚，因为前端调接口必须有明确的URL、请求参数和返回结构。这个约束反过来会逼着你设计合理的RESTful接口，而清晰接口设计正是毕设答辩和简历面试里最容易加分的点。很多老项目用JSP把前端页面写在后端里，接口和页面混杂，讲起来自己都绕，更别提面试官追问了。

2. SQL脚本设计：从业务需求到核心表结构

2.1 核心表清单与关系梳理

SQL脚本是整套系统最先写的东西，它决定业务模型，后续后端实体类、Mapper映射、前端列表页全都是围绕表结构展开的。我这次整理的脚本包含11张核心业务表，全部是InnoDB引擎、utf8mb4字符集。

• sys_user：系统用户表，存放管理员、护工账号，角色字段区分权限。
• elder_info：老人信息表，姓名、性别、身份证号、出生日期、入住状态、家属关联。
• family_contact：家属联系表，支持一个老人绑定多个家属。
• room_info：房间信息表，楼层、房型、朝向、可住人数。
• bed_info：床位信息表，房间外键、床位号、状态字段。
• health_file：健康档案表，既往病史、过敏史、慢病标签、体检摘要。
• sign_record：体征记录表，每日血压、血糖、心率、体温，记录时间。
• medication_plan：用药计划表，药品名、剂量、频次、开始结束时间、执行结果。
• nursing_task：护理任务表，任务类型、关联老人、负责人、执行时间、状态。
• fee_record：费用账单表，费用类型、金额、结算状态、支付时间。
• operate_log：操作日志表，记录登录和关键操作审计。

关系上最核心的一条链是：room_info一对多bed_info，bed_info与elder_info是变动的占用关系；elder_info一对多family_contact、health_file、sign_record、medication_plan、fee_record。实际管理里同一个老人的床位可能变化，所以床和老人之间不建议直接做外键绑定写死，而是用elder_info里的current_bed_id字段记录当前床位，历史流转可以再扩展一张入住记录表。这样设计退住、换房时只需改一个字段，不用动历史数据。

2.2 字段设计与索引优化的细节

字段类型选错了后面全是坑，我踩过最典型的就是日期类型。生日、入住时间、体征记录时间这类必须用date或datetime，不要为了省事全部用varchar，否则后续做时间范围筛选、统计年龄分布时SQL会写到怀疑人生。金额字段一律用decimal(10,2)，不要用float，二进制浮点做金额累加会产生精度误差，账单对不上账很尴尬。

状态字段推荐用tinyint而不是varchar，比如床位状态用0空闲、1占用、2维修、3预定，在枚举里定义好常量。用数字做状态的好处是查询效率略高、避免中英文不一致，但也要求前后端约定好字典含义，前端展示时翻译显示。我这份脚本里所有表都带了create_time和update_time两个字段，创建时自动填入当前时间，更新时由MyBatis的update SQL显式刷新，别小看这两个字段，写操作日志和按时间排序全靠它们。

索引上，外键字段必须建索引，否则联表查询一旦数据量上来就现原形。elder_info的family_id、bed_info的room_id、health_file的elder_id、sign_record的elder_id和record_date这五个组合是查询最热的路径，我建了联合索引(sign_record表：elder_id, record_date)，既支持按老人查记录，也能做按日期范围的全院体征统计。另外所有表的逻辑删除字段deleted建议默认0，查业务数据时统一加deleted=0条件，物理删除只留给运维层操作，这是后台系统的安全习惯。

3. 后端SpringBoot接口设计与核心实现

3.1 统一返回结构与全局异常处理的套路

接口联调最容易出现的问题就是各接口返回格式五花八门，前端没法写统一的响应拦截器。我在项目里第一件事就是定义Result类，包含code、msg、data、timestamp四个字段。code为200表示成功，401未登录、403无权限、500业务异常，前端Axios响应拦截器根据code统一处理提示，不用每个页面都写错误弹窗逻辑。用户没登录、Session过期这些情况，后端直接返回401，前端拦截器统一跳到登录页，这个体验是一致的。

全局异常处理用@RestControllerAdvice配合@ExceptionHandler实现。业务异常由Service层主动抛出BizException，全局捕获后转成Result返回；参数校验异常会抛MethodArgumentNotValidException，捕获后把第一条错误提示返回给前端。这套写法避免Controller里到处try-catch，代码可读性高，面试被问到"异常怎么处理"时也是加分回答。

3.2 核心模块接口梳理与鉴权设计

后端按模块拆分接口，遵循RESTful风格。老人口碑好的原因是资源命名和HTTP方法能对上，下面这张表是核心接口清单，跑项目的时候可以直接对照调试：

鉴权用JWT方案，登录成功后后端生成Token，前端存入localStorage，每次请求在Header里带Authorization。后端写一个拦截器实现HandlerInterceptor，在preHandle里校验Token有效性并解析用户信息放到请求上下文，配置放行路径为/auth/login和静态资源。为什么要写这套而不是直接用Session？因为前后端分离项目前端可能部署在另一个端口，Cookie跨域麻烦，JWT状态在客户端，天然适合这种架构，同时也能在简历里写上"基于JWT的无状态鉴权"。

3.3 Service层设计：为什么业务逻辑不塞进Controller

初学阶段最常见的写法是Controller里直接调Mapper，看起来省事，但实际上维护成本高。比如"老人入住"这个操作，不只是插入一条elder_info，还涉及床位状态变更、生成初始健康档案、创建第一期费用账单，这属于典型的事务操作。我把这类聚合操作封装在Service层的@Transactional方法里，保证多表操作要么全成功要么全回滚，避免老人登记成功但床位状态没改、或者费用账单没生成这种脏数据。

Service层还承担了业务校验。比如分配床位前检查目标床位是否空闲、老人入住状态是否为待入住，参数校验用javax.validation的注解写在DTO上，Controller只负责接收和返回，Service管理完整业务逻辑，Mapper只做SQL数据访问。三层职责边界清晰，答辩时评委问"为什么用户操作某个功能后其它状态也跟着变了"，就可以理直气壮地解释是在Service层的事务方法里完成了状态联动。

4. Vue前端关键功能实现

4.1 前端项目结构与路由权限控制

前端用Vue CLI或Vite创建项目，目录上我习惯把请求层、路由、状态、组件分得清清楚楚。src/api目录下按模块拆分接口文件，比如elder.js、bed.js、health.js，每个文件导出对应的请求方法；src/router定义路由表并配置嵌套路由和动态路由元信息；src/views按页面组织组件；src/components放公共组件；src/store管理登录用户信息和全局状态。

路由守卫是这个前端项目的关键点，用beforeEach判断用户是否登录。具体思路：白名单列表包括登录页、重置密码页，这些页面不校验Token；非白名单页面如果本地没有Token，直接redirect到登录页。菜单权限按用户角色动态过滤，系统里分管理员和护工两个主要角色，管理员能看到费用管理和系统管理，护工默认只开放老人列表、体征记录、护理任务这三个菜单。这个设计让不同角色登录后看到不同的导航菜单，实现成本低且答辩效果好。

4.2 核心页面的交互实现细节

我已经用思源黑体完成了筛选，以下是核心内容：老人列表页是后端管理系统里最典型也最容易被评委追问的页面，搜索区加姓名、入住状态、房间号三个条件，表格展示基础信息，操作列放"详情""编辑""分配床位""删除"。数据加载统一走分页接口，el-table加上v-loading，分页组件绑定pageNum和pageSize，搜索条件变化时重置页码回1。这里有个细节很多人会漏：删除操作要二次确认弹窗，前端只调用逻辑删除接口，不是真的删记录，这对数据审计很重要。

表单页用el-form配合rules做校验，身份证号用18位正则，手机号用11位正则，金额字段限定数字格式。提交按钮在请求期间加loading状态，防止用户重复点击导致重复提交。关联数据用级联选择器，比如选择房间后，床位下拉自动根据房间过滤可用床位，这个联动请求要在房间变更时触发，真正上线时还得考虑防抖。

统计首页我建议用ECharts做两块图表：年龄分布饼图和各月入住率趋势折线图，数据来自后端聚合接口。这一步对毕设的加分效果非常明显，它让系统从"增删改查页面"升级到"数据可视化看板"，面试时可以多讲一句"后端提供聚合统计SQL，前端用ECharts渲染"。

5. 接口文档：Java Web项目的隐形门面

5.1 为什么毕设也要正经写接口文档

很多同学觉得毕设嘛，代码跑起来就行，接口文档随便应付。这个想法我劝你趁早改掉。接口文档不是写给老师看的，是写给"未来的你"看的。代码写完三天之后，你再看那些Controller，绝对想不起来某个接口到底接收什么参数、返回什么结构，改一个字段要全局搜半天。有了一份完整的接口文档，无论是自己维护、还是别人接手、还是答辩时演示给评委看，效率都是质的差别。

接口文档的另一个价值是暴露设计问题。写文档的过程也是检查接口设计的过程，如果一个接口的路径、参数、返回结构你没法用一两句话讲清楚，说明这个接口的设计大概率有问题。我在整理这套系统的文档时，就调整过三个接口的返回结构，原本把床位信息嵌套在老人对象里的设计被拆成了独立字段，联调瞬间顺畅了。

5.2 接口文档的内容组织与示例

我用的接口文档模板遵循四个固定模块。第一块是基本信息，接口名称、URL、请求方法、接口描述；第二块是请求参数，区分Path参数、Query参数、Body参数，Body参数用表格列出字段名、类型、是否必填、说明；第三块是响应结果，给出正常返回的JSON示例，字段含义逐条注明；第四块是错误码和异常说明，列出可能出现的错误状态。

以登录接口为例，POST /api/auth/login，Body参数username和password均为string必填。正常返回data里包含token和userInfo，token有效期24小时。错误情况401表示账号或密码错误，这个信息前端是直接弹窗提示的。文档用Markdown维护，也可以引入Swagger自动生成，但Swagger只能生成接口列表，业务描述还是得手写补充，两边结合效果最好。文档放一份在项目根目录，答辩时直接打开给评委看，专业感马上就不一样。

6. 本地部署与前后端联调全流程

6.1 环境准备与项目导入

这套系统本地跑通需要的基础环境：JDK 1.8，Maven 3.6及以上，MySQL 5.7或8.0，Node.js 14及以上，推荐用npm 6以后版本。后端IDE强烈建议用IntelliJ IDEA，打开项目后等Maven自动下载依赖，首次构建可能要几分钟。前端用VSCode或WebStorm都行，在front-end目录下执行npm install安装依赖，如果下载慢可以换镜像源，这个后面讲。

项目目录我建议按如下结构：backend存放SpringBoot工程，里面controller、service、mapper、entity、config分包清晰；sql存放init.sql初始化脚本；doc存放接口文档和部署说明；frontend存放Vue工程。整个仓库先在Gitee建一个远程库，每完成一个模块就提交一次，这个习惯对毕业设计和找工作都极其加分，面试官看到持续提交记录比简历上写一百个技术关键词都管用。

6.2 SQL脚本导入与后端配置启动

数据库这步最容易出问题，我建议按顺序操作。第一步，本地MySQL执行CREATE DATABASE elderly_center DEFAULT CHARACTER SET utf8mb4，字符集必须指定utf8mb4，否则中文会乱码。第二步，选中数据库后执行init.sql，脚本里包含建表语句和初始数据，比如admin账号、管理员角色、几个演示用的老人和床位数据。第三步，打开application-dev.yml，把数据源的url、username、password改成自己的本地配置。

启动后端有两种方式。在IDEA里直接运行主启动类，控制台看到Tomcat started表示成功。也可以用命令行在backend目录执行mvn spring-boot:run，效果一样。启动后如果发现端口冲突，把server.port改掉。我习惯接口统一加/api前缀，前端代理配置就按这个路径转发。验证后端是否正常，浏览器访问http://localhost:8080/swagger-ui/，能看到接口列表就是成功。

6.3 前端代理配置与联调验证

前端联调时最大的拦路虎是跨域。开发环境下最简单的方案是在vue.config.js里配devServer代理，把/api开头的请求转发到http://localhost:8080，这样浏览器看到的请求是同源的，自动绕过跨域限制。线上部署时前端打包出的静态文件放到Nginx下，Nginx再配置location /api反向代理到后端服务，前后端不再混用端口。

联调验证从登录开始，前端输入admin账号密码，能拿到Token并跳转到首页，说明鉴权链路通了。接下来逐个页面点一遍：老人列表加载数据、新增老人后表格刷新、分配床位后床位状态变化、体征录入后列表时间排序正确，这些核心流程走通，项目功能基本就稳定了。我在本地联调时习惯把浏览器开发者工具放在Network面板，任何一个接口报4xx或5xx，第一时间看到请求参数和响应内容，排查效率极高。

7. 高频问题排查实录

7.1 项目启动阶段的翻车现场

遇到过最多的启动报错第一个是Maven依赖下载失败或版本冲突，SpringBoot版本和MyBatis整合包版本不一致时会在编译期抛错。我这个项目里用的是SpringBoot 2.7.x搭配mybatis-spring-boot-starter 2.2.x，这个组合稳定，不要盲目升级到SpringBoot 3.x，3.x要求JDK 17，很多学校机房还是JDK 8，版本不匹配会越修越乱。

第二个典型的启动报错是找不到Mapper接口。检查启动类有没有加@MapperScan注解扫描mapper包，以及Mapper XML文件的namespace是不是和接口全限定名一致，这两个地方错了必报Invalid bound statement。第三个是数据库连接不上，大多数是本地MySQL没启动服务或密码不对，确认yml配置和命令行能正常连接数据库就行。

7.2 联调阶段的前后端问题

前端请求报跨域错误，第一个排查点就是看Network面板里请求有没有发出去。如果请求到达了后端但被浏览器拦截，检查后端是否配置了CORS，我在项目里用WebMvcConfigurer配置了allowedOriginPatterns并允许Authorization头。如果请求根本没发出去，那就是代理配置没生效，检查vue.config.js的proxy路径是否和接口路径一致。

Token失效导致的401跳转逻辑要处理好，否则会出现页面循环跳转。实际开发中发现，Token过期后所有接口都返回401，这时前端应该清掉本地Token并跳转登录页，同时要在响应拦截器里避免重复提示多个401弹窗，加一个标志位做节流。

7.3 数据和显示层面的坑

数据库中文乱码，检查三处：数据库连接URL带上characterEncoding=utf8，MySQL服务端字符集是utf8mb4，建表语句的DEFAULT CHARSET为utf8mb4。三处只要有一处漏掉，前端传回的中文就可能变成问号。我还在过滤器里增加了一个字符编码过滤器，确保POST请求体也走UTF-8。

时间字段显示差8个小时，这是时区问题，数据库连接URL加上serverTimezone=Asia/Shanghai就能解决。列表分页总数不同步，常见原因是前端传了pageNum但从1开始还是从0开始没和后端PageHelper对齐，我统一约成pageNum从1开始、pageSize默认10，前端和SQL脚本里保持一致性。

8. 给做毕设的同学几句实在话

8.1 答辩现场最容易被追问的技术点

评委问技术问题基本围绕三个维度。第一个维度是架构，为什么选前后端分离、为什么Redis做缓存知道但不一定用上，这里建议提前想清楚为什么在部分接口加缓存。第二个维度是数据库，让说说ER模型和设计思路，建议把老人、床位、健康档案的关联关系画清楚。第三个维度是安全性，Token怎么生成、密码怎么存储、为什么使用逻辑删除，回答方向是BCrypt加密存储密码，登录接口生成JWT，关键操作写日志。

针对"这个系统哪里体现了大健康"这个问题，建议引到健康档案管理、慢病跟踪、体征趋势、用药提醒这些模块上，说明系统不只是信息登记，还有主动健康管理的思路。这是这个毕设题目的核心价值点，讲好了比实现细节更有说服力。

8.2 做完这套系统后的个人体会

代码写完不是终点，我把这套项目跑通之后又做了一次大重构，把原来Controller里散落的业务操作收拢到Service层，把前端重复的请求逻辑抽到了封装好的请求函数里，把SQL脚本里的冗余字段清理干净。这一轮重构比第一轮写代码学到的多得多，也让我真正理解了"可维护性"这个词的分量。

如果你时间充裕，可以在这个基础上再做三件小事：一是给系统加一个数据导出功能，把老人列表和费用记录导出Excel；二是引入简单的Redis缓存，把体征记录的最近查询缓存起来；三是写一个README文件，把项目背景、技术栈、启动步骤、功能说明写得完整一点。这三件事做下来，这个毕设的质量会明显超出普通项目，答辩和找工作简历上都能体面地展示。

说到最后，还是那句老话：需求梳理比写代码重要，表结构设计比功能堆砌重要，接口文档比口若悬河重要。你把这三件事做扎实，这个项目的收获会远超毕业设计本身的分数。