企业官网建设流程全解析

这两年接手的项目里，月子护理中心管理系统算是比较有代表性的一类。去年我帮一家本地连锁月子中心做信息化改造，前后端选型就是Java Spring Boot加Vue。这类系统市面上有现成的SaaS产品，但真正落到一线业务时，要么收费太贵，要么流程跟门店实际运营对不上，所以很多中小型月子中心最后还是倾向定制开发。今天就把这套系统的完整设计思路、核心模块、技术细节和踩坑记录整理出来，给正在做同类项目的同学一个参考。

这套系统能解决什么问题，先交代清楚：月子中心日常要管产妇入住、宝宝护理记录、护士排班、房间床位状态、月子餐配置、收费账单，还要给管理层出经营报表。如果全靠Excel和微信群，信息不同步、记录查不到、月底对账更是噩梦。系统化之后，前台预约登记、护士扫码录入护理项、店长看实时入住率、财务一键导出账单，整条业务链路都打通了。

如果你是Java后端学习者、在做毕业设计，或者准备接手月子中心、养老院、康复中心这类照护机构的信息化项目，这篇内容可以直接拿来当参考骨架。我尽量把关键表设计、接口实现、前端联动细节都写全，你照着复刻一遍，基本就能跑通一个完整项目。

1. 项目定位与整体设计思路

1.1 业务全景与系统边界

动工之前先做业务流程梳理，这一步比写代码重要得多。我花了两天时间蹲在门店里看护士怎么工作、前台怎么登记、店长每天要哪些数据，最后把业务抽象成一条主线：咨询预约、到店参观、签约入住、护理服务、出所结算。

围绕这条主线，系统拆成八大模块：系统管理、预约管理、产妇档案、宝宝档案、护理记录、房间床位、月子餐管理、收费统计。每个模块再往下拆，比如护理记录里要区分产妇护理项和新生儿护理项，产妇护理包括伤口消毒、体温监测、恶露观察、乳房护理，宝宝护理包括喂奶记录、黄疸检测、洗澡抚触、脐带消毒。这些细节直接决定表结构怎么设计，也决定护士在平板上操作时顺不顺手。

系统边界也要提前划清楚。比如库存管理要不要做？我的建议是第一期不做，纸尿裤、奶粉这类耗材跟护理流程耦合度低，硬塞进来会让系统变重。再比如排班管理，很多同类系统会把排班做成复杂的人力资源模块，但月子中心门店一般就十几个护士，用简单的轮值表就够了。做定制开发最怕需求蔓延，第一期先把核心链路跑通，后续再迭代。

1.2 技术选型为什么是Spring Boot加Vue

后端选Spring Boot，理由很直接：生态成熟、上手快、适合中小型业务系统。Spring Boot内嵌Tomcat，打一个jar包就能部署，不像传统SSH项目要装外部容器，这对门店IT环境来说省了很多事。配合MyBatis-Plus操作数据库，单表的增删改查基本不用写SQL，开发效率翻倍。

前端选Vue，核心原因是渐进式框架灵活，组件化开发适合这种表单密集、列表页多的管理后台。配合Element Plus组件库，表格、弹窗、表单校验这些后台系统的高频需求都有现成方案，不用从零造轮子。Vue Router做页面路由，Pinia做全局状态管理，再加上Axios统一处理HTTP请求，整个前端架构清晰又轻量。

这套组合在中小团队里几乎是标准答案，不是说它性能有多极致，而是招人容易、资料多、遇到问题搜索引擎一搜就有答案。对于月子中心这种并发量不高的业务系统，单体架构加前后端分离已经完全够用，没必要上微服务那套复杂架构。

1.3 环境准备与项目初始化

环境这块踩过不少坑，先列一份基础清单：

• JDK 8或JDK 11，建议JDK 8，稳定且兼容性最好
• Maven 3.6以上，用来管理后端依赖
• Node.js 16以上，用来跑Vue开发环境，安装Vue脚手架之前记得先把Node配好
• MySQL 5.7或8.0，建议8.0，性能更好
• IDE推荐IDEA，自带数据库工具和前端支持

后端项目创建用Spring Initializr，勾选Web、MySQL驱动、MyBatis-Plus依赖。需要注意Spring Boot版本别贪新，2.7.x就很稳，有次我用了3.x版本，结果MyBatis-Plus的适配配置变了，查了半天文档才解决。前端用Vue CLI或者Vite创建项目，安装Element Plus、Axios、Vue Router、Pinia这几个核心依赖，基本就能开工了。

2. 数据库建模：核心表结构与关系设计

2.1 从业务实体推导数据模型

数据库设计是这类系统的灵魂，我习惯先画实体关系图，再落成表结构。月子护理中心的核心实体有：用户、角色、菜单、产妇、宝宝、护理记录、房间床位、护理任务、餐食方案、收费账单、预约订单。

用户和角色用来做权限控制，采用经典的RBAC模型，五张表：用户表、角色表、菜单表、用户角色关联表、角色菜单关联表。业务表里，产妇档案和宝宝档案是一对多关系，因为存在双胞胎情况；产妇和护理记录是一对多；房间和床位是一对多；预约订单和产妇是弱关联，预约成功转为入住后生成正式档案。

外键我一般不建物理外键，靠代码逻辑维护关联关系。物理外键在数据量上来后会影响写入性能，而且删除、更新限制太多，团队协作时容易产生锁问题。但逻辑上必须保证引用完整性，比如查护理记录时一定要关联出对应的产妇和宝宝，这些在Service层做校验。

2.2 关键表字段设计说明

产妇档案表是业务核心，字段设计要贴合护士的真实操作习惯：

CREATE TABLE mother_profile ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '主键ID', profile_no VARCHAR(32) NOT NULL COMMENT '档案编号', name VARCHAR(50) NOT NULL COMMENT '产妇姓名', id_card VARCHAR(18) COMMENT '身份证号', phone VARCHAR(20) COMMENT '联系电话', age INT COMMENT '年龄', admission_date DATE COMMENT '入住日期', discharge_date DATE COMMENT '预计出院日期', delivery_mode TINYINT COMMENT '分娩方式：1顺产 2剖宫产', room_id BIGINT COMMENT '房间ID', bed_id BIGINT COMMENT '床位ID', doctor_name VARCHAR(50) COMMENT '主治医生', status TINYINT DEFAULT 1 COMMENT '状态：1在住 2已出所 3已取消', special_needs VARCHAR(500) COMMENT '特殊需求', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, deleted TINYINT DEFAULT 0 COMMENT '逻辑删除标记' ) COMMENT '产妇档案表';

这里几个字段要特别说明。profile_no是档案编号，格式类似“20250101-001”，方便线下核对纸质档案。delivery_mode影响护理任务模板的选择，顺产和剖宫产的护理项目不一样。deleted字段做逻辑删除，业务数据不能物理删，不然出所结算记录就断了。所有表都带上create_time和update_time，排查问题时能快速定位数据变化时间线。

宝宝档案和护理记录表是一对多的经典场景，每个宝宝每天有多次喂奶记录和体征测量记录。护理记录表的设计思路是“一条记录对应一个护理动作”，例如喂奶时间、喂奶量、奶温、宝宝反应这些字段都放在明细表里，方便后续统计宝宝日均吃奶量、体重增长曲线。

房间床位表单独拎出来说，因为月子中心对这个特别看重。门店经理要一眼看到哪间房空着、哪间房住着谁、哪间房在保洁。所以房间表要记录房间号、房型（单间、套房）、朝向、价格、当前状态，床位表关联房间ID，还要记录床位编号和状态。入住操作要同时更新房间状态和床位状态，这个联动逻辑在事务里完成。

2.3 数据库设计的几个实用经验

第一个经验是状态字段用TINYINT数字枚举，别直接用字符串。数据库里存1、2、3，代码里定义常量或者枚举类映射，这样既节省存储空间，又避免字符串拼写不一致的问题。前端展示时再转成对应的中文标签。

第二个经验是时间字段统一用DATETIME，别用TIMESTAMP。TIMESTAMP有2038年问题的隐患，而且会受时区影响。前后端传参统一用时间戳或者标准格式字符串，避免歧义。

第三个经验是金额字段用DECIMAL(10,2)，别用FLOAT或者DOUBLE。浮点数在累加计算时会有精度偏差，分账对不上就是灾难。月子中心收费项目多，产康套餐、月嫂一对一服务、餐食加购等各种费用，金额精度必须严格把控。

第四个经验是给高频查询字段建索引。这套系统里，护理记录查询、床位状态查询、订单查询是最频繁的SQL，对应外键字段和时间字段都要加索引。我遇到过慢查询，后来EXPLAIN一看，没走索引，全表扫描了几十万条记录，加了联合索引后查询时间从几秒降到几十毫秒。

3. 后端实现：Spring Boot核心功能落地

3.1 项目分层与统一响应结构

后端项目我习惯按controller、service、mapper、entity、common五层分包。controller只做参数接收和结果返回，业务逻辑全部下沉到service层，mapper层用MyBatis-Plus的BaseMapper接口，大部分单表操作不用写XML。

统一响应结构是必做的，不然前后端联调时各写各的，接口返回格式五花八门，前端处理起来想哭。我定义的Result对象包含code、message、data三个字段，成功code为200，业务异常code自定义，比如参数错误400、未登录401、无权限403。所有接口都返回这个统一格式，前端在Axios响应拦截器里统一处理。

全局异常处理用@RestControllerAdvice注解，捕获业务异常、参数校验异常、系统异常三类。业务异常是自定义的BizException，在Service层发现业务不满足条件时主动抛出，比如房间已被占用、产妇档案不存在；参数校验异常靠@Valid注解自动触发；系统异常兜底，记日志并返回友好提示，不能把堆栈信息直接甩给前端。

3.2 JWT认证与权限控制

权限认证方案我对比过Spring Security和轻量拦截器两种。Spring Security功能强大但配置复杂，学习成本高；对一个管理后台来说，用JWT加拦截器已经完全够用。这里有个关键取舍：小系统别过度设计，简单的方案更容易维护。

JWT登录流程是这样的：用户提交账号密码，后端校验通过后生成Token返回给前端，前端存到localStorage，每次请求在请求头里带上Authorization字段。后端写一个TokenInterceptor拦截器，校验Token是否有效、是否过期，解析出用户ID和角色，放到ThreadLocal里供后续业务使用。

@Component public class TokenInterceptor implements HandlerInterceptor { @Resource private StringRedisTemplate stringRedisTemplate; @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登录接口 if (request.getRequestURI().contains("/auth/login")) { return true; } String token = request.getHeader("Authorization"); if (StringUtils.isBlank(token)) { throw new BizException(401, "未登录或登录已过期"); } // 从Redis中校验Token，支持主动失效 String userInfo = stringRedisTemplate.opsForValue().get("token:" + token); if (StringUtils.isBlank(userInfo)) { throw new BizException(401, "登录已过期，请重新登录"); } // 解析用户信息，放入ThreadLocal UserContext.set(JSON.parseObject(userInfo, LoginUser.class)); return true; } }

密码存储必须用BCrypt加密，别用MD5。MD5是摘要算法，不是加密算法，彩虹表一查就破。BCrypt每次加密会生成随机盐，同样的密码每次加密结果都不一样，安全性高很多。Spring Security的crypto包里直接有BCryptPasswordEncoder，单独引进来就能用。

3.3 核心业务接口实现：护理记录与床位联动

护理记录是护士每天操作最多的模块，接口设计要尽量简化操作步骤。护士进入护理记录页面，选择产妇和宝宝，系统自动带出今天的护理任务列表，护士逐项填写并提交。

这里有个设计细节：护理任务不是写死的，而是根据产妇档案的入院天数动态生成。比如顺产产妇第1到3天重点关注子宫恢复和伤口观察，第4到7天重点关注乳房护理和恶露情况。我在数据库里建了一张任务模板表，配置规则是“护理类型+时间范围+护理项目”，Service层拿到产妇档案后，计算出当前是第几天，匹配模板生成当天任务列表。

房间床位联动这块，我的实现方案是：预约订单确认入住时，在事务里完成三件事，生成产妇档案、锁定床位并更新床位状态、创建初始护理计划。出院时反向操作，更新产妇状态、释放床位。如果事务中任何一步失败，全部回滚，保证数据一致性。

分页查询用MyBatis-Plus的分页插件，配置一个PaginationInnerInterceptor就行。需要注意分页参数从前端传过来时要做好边界校验，页码不能小于1，每页条数不能超过100，防止有人恶意传超大参数拖垮数据库。

3.4 报表统计与Excel导出

管理层最爱看的数据就三类：入住率、营收、护理任务完成量。这些数据不用实时统计，每天凌晨跑一次定时任务汇总到统计表里，查询时直接读汇总数据，性能好很多。

营收统计要按收费类型分组，产康服务费、住宿费、餐费、护理费分开统计。SQL用GROUP BY加SUM函数，再把结果按时间维度汇总。这里要注意金额计算用BigDecimal，避免浮点误差。

导出功能用EasyExcel实现，比POI好用太多。POI的API写起来繁琐，Excel大数据量导出还容易内存溢出。EasyExcel封装了读写操作，一行代码就能导出，还支持自定义样式。导出文件名要带日期，比如“2025年1月营收明细.xlsx”，方便财务归档。

4. 前端实现：Vue页面与交互细节

4.1 前端骨架与动态路由设计

前端项目初始化时，我习惯先把目录结构搭好：views放页面组件，router放路由配置，store放Pinia状态，api放接口请求封装，utils放工具函数。页面组件按模块分文件夹，比如views/mother目录下放产妇档案列表页、详情页、编辑页，这样多人协作时互不干扰。

Vue Router的路由配置包含静态路由和动态路由两部分。静态路由只有登录页和404页面，动态路由根据用户角色动态生成。用户登录成功后，后端返回该用户可访问的菜单列表，前端把菜单映射成路由，用router.addRoute动态添加。这样做的好处是不同角色的用户看到的页面不同，比如护士看不到财务模块，店长能看到全部页面。

路由守卫是前端的权限第一道关卡。在beforeEach守卫里做三件事：判断是否已登录、判断目标路由是否存在、判断用户是否有权限访问。这里有个坑：动态路由是异步添加的，首次刷新页面时路由还没生成，会直接跳到404。解决办法是加一个标志位，如果路由未初始化，重新拉取菜单并addRoute，然后next到目标地址。

4.2 Axios封装与请求拦截

Axios封装是前端联调的基石。我封装的request模块做了四件事：请求拦截器里加Token、响应拦截器里统一处理错误码、请求超时设置、文件上传特殊处理。

// src/utils/request.js import axios from 'axios' import { ElMessage } from 'element-plus' import router from '@/router' import { useUserStore } from '@/store/user' const service = axios.create({ baseURL: '/api', timeout: 15000 }) service.interceptors.request.use(config => { const userStore = useUserStore() if (userStore.token) { config.headers['Authorization'] = userStore.token } return config }) service.interceptors.response.use( response => { const res = response.data if (res.code === 200) { return res } if (res.code === 401) { // 登录过期，清除本地信息并跳转登录页 const userStore = useUserStore() userStore.reset() router.push('/login') return Promise.reject(new Error('登录已过期')) } ElMessage.error(res.message || '请求失败') return Promise.reject(new Error(res.message)) }, error => { ElMessage.error(error.message || '网络异常') return Promise.reject(error) } )

这里把baseURL设置为/api，开发环境通过Vite的代理配置把请求转发到后端服务，生产环境由Nginx做反向代理。这样做的好处是前端代码里不写死后端地址，切换环境时不用改代码。

4.3 核心页面实现与交互细节

产妇档案列表页是最典型的表格页，用Element Plus的el-table展示数据，配合el-pagination做分页。查询条件区放姓名、手机号、状态筛选，点击查询按钮重新拉数据。这里我用的是表单和表格在同一页的布局，操作效率比跳转详情页高很多。

床位视图页面有点特殊，要模拟月子中心的楼层平面图。我的实现方案是用自定义卡片布局，每个房间渲染成一张卡片，卡片颜色根据状态变化：绿色代表空房、橙色代表保洁中、红色代表已入住。点击房间卡片弹出详情，显示房间信息、入住产妇姓名、入住天数，同时提供入住登记和退房操作入口。这个页面临摹了线下门店经理看板的感觉，上线之后店长反馈特别好用。

护理记录表单是高频操作页面，我做的优化是：选完产妇后自动带出该产妇的宝宝信息列表，选宝宝时自动带出今天待完成的护理任务模板。护士只需要填写任务明细，不需要每次从零开始录入，操作路径从5步缩短到2步，实测下来护士录入一条护理记录的时间从2分钟降到40秒。

ECharts报表页面用来展示经营数据，首页放四个核心指标卡片：当前入住产妇数、今日新增预约、本月营收、护理任务完成率，下面配两个图表，一个是近30天入住率趋势折线图，一个是收入结构饼图。数据从后端统计接口拉取，图表在mounted生命周期里初始化。

4.4 表单校验与体验优化

后台系统的表单校验不能全靠前端，后端也要校验，这是双保险。前端用Element Plus的form rules做基础校验，比如必填、手机号格式、日期不能早于今天；后端用@Valid注解加自定义校验类拦截非法请求。

日期选择是个容易忽略的细节。产妇入住日期选择器要禁用过去的日期，出院日期不能早于入院日期，这些都是业务约束，全部用rules实现。选择完日期后，系统自动计算预住天数并显示参考金额，这个小功能给前台登记人员节省了很多心算时间。

按钮防重复提交也很重要。护士在平板上双击保存按钮，如果接口没做幂等处理，会产生两条重复的护理记录。我的方案是给提交按钮加loading状态，请求发出后按钮禁用，请求完成后恢复。对于敏感操作，比如收费确认，后端还要做唯一校验，防止同一位产妇在同一时间段创建重复账单。

5. 安全权限与隐私保护：月子中心系统的特殊考量

5.1 为什么权限模型要精细到数据范围

月子中心管理的是产妇和新生儿的健康数据，属于敏感个人信息，权限控制必须做到数据行级别。我见过很多系统只做菜单权限，登录后所有数据都能看，这在月子中心根本行不通。

举个实际场景：护士A负责401房间的产妇，她登录系统后应该只能看到自己负责的产妇档案和护理记录。如果她能随意查看其他护士负责的产妇信息，一旦发生隐私泄露，门店要承担法律责任。店长可以看全量业务数据，但看不到财务模块；老板能看到财务汇总和经营报表，但不需要进入护理操作界面。

所以权限设计要分三个层级：菜单权限控制“能进哪个页面”，按钮权限控制“能点哪个按钮”，数据权限控制“能看哪些数据行”。前两层用RBAC模型就能实现，第三层需要根据业务规则动态拼接查询条件。

5.2 数据权限控制的具体实现方案

MyBatis-Plus提供的数据权限插件可以拦截SQL并自动拼接权限条件，但配置稍微复杂，不同角色的规则不一样。我这个项目用的是手动方案：在Service层根据当前登录人的角色，往查询条件里加约束。

public PageResult<MotherProfile> queryMotherPage(MotherQuery query) { // 从ThreadLocal获取当前登录用户 LoginUser loginUser = UserContext.get(); LambdaQueryWrapper<MotherProfile> wrapper = new LambdaQueryWrapper<>(); // 护士角色：只能查自己负责的产妇 if ("NURSE".equals(loginUser.getRoleCode())) { wrapper.eq(MotherProfile::getNurseId, loginUser.getUserId()); } // 店长角色：可以查本门店所有产妇 // 其他角色：按权限配置过滤 // 追加查询条件 if (StringUtils.isNotBlank(query.getName())) { wrapper.like(MotherProfile::getName, query.getName()); } return motherService.pageQuery(wrapper, query); }

这种手动方案看起来不够“高大上”，但胜在简单直观，业务规则清晰时维护成本也低。等到后续权限规则复杂了，再考虑引入数据权限插件。

5.3 敏感字段脱敏与操作日志

产妇的身份证号、手机号、详细住址属于敏感字段，列表页和详情页展示时要脱敏。身份证号只显示前6位和后4位，中间用星号代替；手机号显示前3位和后4位。只有在授权的情况下，点击“查看完整信息”按钮才能看到明文，而且这个操作要记录日志。

操作日志是合规要求，谁在什么时间查看了什么敏感数据，后台都要有记录。我用Spring AOP做了一个简单的切面，拦截带有@Log注解的Controller方法，记录操作人、操作时间、操作内容、请求IP，异步写入日志表。这样出了隐私争议时，能第一时间查到操作链路。

5.4 接口防刷与安全自查清单

网络接口直接暴露公网，必须防刷。我的方案是：登录接口加图形验证码，防止暴力破解；普通接口做简单限流，例如同一个Token在一秒内请求超过10次就临时拦截；管理后台只允许通过IP白名单访问，门店内部网络才能连。

做安全自查时，我会按这份清单逐项排查：SQL注入（MyBatis-Plus的#{}占位符默认防注入，但要避免手动拼接SQL）、XSS攻击（前端不做富文本渲染，注意过滤尖括号）、越权操作（查询接口必须校验当前用户是否有访问数据权限）、文件上传（限制类型和大小，防止上传恶意脚本）。

6. 部署上线与运维手段

6.1 前后端分离部署方案

部署架构很清晰：一台2核4G的云服务器就够跑整个系统。后端打成jar包用systemd托管，前端Vue项目执行npm run build生成dist目录，交给Nginx托管静态文件。Nginx里配置反向代理，把所有/api路径的请求转发到后端服务地址。

server { listen 80; server_name your-domain.com; # 前端静态文件 root /opt/moon-center/frontend/dist; index index.html; # 后端接口反向代理 location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } # Vue路由history模式配置 location / { try_files $uri $uri/ /index.html; } }

Vue路由如果用了history模式，Nginx必须配置try_files，否则刷新页面时会出现404，这个坑出现过好几次了。生产环境我强烈建议把HTTP改成HTTPS，一个免费的SSL证书就能解决，不然登录账号密码明文传输实在不放心。

6.2 数据库备份与日志策略

数据库备份是唯一能在出事故时救命的东西。我写了两个脚本，一个做每日全量备份，凌晨2点用mysqldump导出SQL文件，保留最近30天；一个做增量备份，每6小时同步一次binlog。备份文件自动上传到OSS存储，避免服务器磁盘故障导致备份丢失。

日志方面，Spring Boot的日志默认只输出到控制台，重启就没了。必须要配置logback写文件，按天切割，保留30天。日志文件保存了业务异常堆栈和接口调用记录，排查线上问题全靠它。我还建议接入一个简单的告警：日志文件里出现“Exception”关键字时，脚本自动发送通知到运维群。

6.3 系统初始化与员工培训

部署上线只是第一步，门店员工能真正用起来才是成功。我给客户做了一套初始化流程：先配置门店基本信息、房间房型和价格，再导入员工账号和角色，然后录入在住产妇的档案数据，最后组织三场培训，分别针对前台、护士、店长不同角色。

培训过程中发现一个普遍问题：护士团队的IT基础薄弱，对打字录入有畏难情绪。所以我把高频操作做成了操作手册，每个操作步骤配截图，还录了两个教学短视频。线下培训加手册支持双管齐下，两周之后护士们基本就适应了，护理记录的录入率从第一周的60%提升到95%以上。

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

7.1 问题速查表

下面这张表总结了我开发过程中遇到的高频问题，按“症状-原因-解法”的思路整理，遇到类似问题可以快速对照排查。

7.2 几个印象深刻的坑

第一个坑是事务失效。我在一个Service方法里写了床位分配和产妇建档两步操作，数据库里的房间状态始终没更新。排查半天发现，同类调用导致事务不生效。同一个类里的方法用this调用，不走Spring代理，@Transactional注解白写了。解决办法是把这两步操作拆到两个Service类里，或者注入自己的代理对象。

第二个坑是时间格式问题。后端返回的LocalDateTime默认序列化成“2025-01-01T10:30:00”，前端显示出来特别难看。后来在application.yml里配置了Jackson的日期格式化，统一成“yyyy-MM-dd HH:mm:ss”格式，问题解决。

第三个坑是Element Plus的表格分页。我一开始以为el-pagination会自动处理数据，结果发现分页组件只是纯粹的UI组件，需要自己绑定current-page和page-size，还要监听change事件去请求接口。理解了它是受控组件之后就好办了，前端拉当前页数据、后端返回总数和当前页列表，这个模式后面所有列表页都照此实现。

第四个坑是Vue响应式数据。给对象动态添加新属性时，直接obj.newField=value不会触发视图更新，要用Vue 3的响应式API或者把整个对象替换掉。这个坑写文档时遇到过，排查了半个多小时，最后才想起来Vue 3用Proxy做的响应式，新增属性需要用reactive的set方法。

7.3 项目后续优化方向

系统上线稳定运行之后，可以往这些方向扩展：在线预约小程序，让客户在微信上直接预约参观和选房，数据自动同步到后台；智能硬件对接，比如婴儿床的体温检测设备、房间空气监测设备，数据实时写入护理记录；会员套餐管理，把产康项目做成按次计费的会员卡，跟收费模块打通。

从我个人经验看，这类管理系统最容易出彩的地方不在技术，而在业务细节的打磨。比如护理记录模板是否贴合实际操作流程、床位状态图是否直观、报表数据是否能回答店长每天最关心的经营问题。技术选型用Spring Boot和Vue是最成熟稳妥的组合，真正拉开差距的是你对业务场景的理解深度。动手开发之前，多去一线蹲几天，看看用户是怎么干活的，这个时间花得最值。