本地少儿看护系统技术架构与实战：多角色预约、订单状态机与隐私保护设计

本地少儿看护系统是面向同城或社区场景，连接家长、看护人员和运营方的预约与履约平台。它的核心不是简单“撮合”，而是围绕儿童看护的特殊性，解决资质审核、时间预约、服务过程可追溯、紧急情况可报警、隐息可保护等问题。与普通上门预约系统相比，本地少儿看护系统更强调安全边界、角色权限、消息触达和订单状态可控。本文从需求拆解、技术选型、核心模块、安全部署和常见问题五个方面，给出一套可落地的工程实践。

一、需求拆解与角色建模

本地少儿看护系统通常包含三类角色：

1. 家长端：浏览看护人员或机构、选择服务时段、提交预约、查看订单进度、接收服务报告、触发紧急报警。
2. 看护端：提交入驻资料、上传资质证明、设置可服务时间、接单、打卡、填写看护记录、上传图片或视频摘要。
3. 管理端：审核入驻、管理服务项目、派单或抢单配置、订单管理、会员管理、任务管理、消息推送、城市自营配置。

如果业务还包含机构入驻，则需要增加机构管理员角色，用于管理旗下看护人员、排班和服务范围。角色模型建议采用 RBAC，即用户—角色—权限—资源四层结构，避免把权限硬编码在业务逻辑中。

关键业务对象可以抽象为：

• 用户：家长、看护人员、机构管理员、平台运营。
• 服务：临时看护、接送陪伴、课后托管、假期看护等。
• 预约单：时间、地点、服务类型、看护人员、状态。
• 履约记录：打卡、看护日志、照片、异常上报。
• 安全事件：报警、紧急联系人、位置轨迹、处理结果。

二、技术选型与工程结构

结合同类上门预约系统的成熟实践，本地少儿看护系统可采用以下技术栈：

• 后端：Spring Boot + MyBatis-Plus + MySQL + Redis。
• 管理端：Vue + ElementUI。
• 用户端与看护端：uniapp，一套代码适配小程序、公众号 H5、iOS 和 Android。
• 消息推送：WebSocket + 小程序订阅消息 + APP 推送。
• 隐私通信：虚拟中间号或隐私号服务，订单结束后自动解绑。
• 文件存储：对象存储，用于资质、看护日志和图片。
• 地图能力：定位、地理围栏、距离计算。

后端工程可按领域拆分：

care-system
├── care-api          # 对外接口层
├── care-service      # 业务逻辑层
├── care-dao          # 数据访问层
├── care-common       # 通用工具、枚举、异常
├── care-job          # 定时任务：超时订单、自动确认、消息重试
└── care-admin        # 管理端接口

数据库设计要提前考虑多城市自营。常用做法是在核心表中增加 city_id 或 tenant_id，查询时强制带上城市条件。如果城市数量多、数据量大，可以进一步按城市分库分表，但早期建议先做逻辑隔离，降低运维复杂度。

三、核心模块实现

1. 入驻与资质审核

看护人员入驻不能只做验证，至少需要实名认证、健康证明、相关资质或培训记录。表结构可设计为：

CREATE TABLE caregiver (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  user_id BIGINT NOT NULL,
  real_name VARCHAR(32),
  id_card_no VARCHAR(64),
  city_id BIGINT NOT NULL,
  status TINYINT DEFAULT 0, -- 0待审核 1通过 2驳回 3下架
  created_at DATETIME,
  updated_at DATETIME
);

CREATE TABLE caregiver_cert (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  caregiver_id BIGINT NOT NULL,
  cert_type VARCHAR(32),
  cert_no VARCHAR(64),
  file_url VARCHAR(255),
  audit_status TINYINT DEFAULT 0,
  expire_at DATETIME
);

审核接口建议采用状态机，而不是直接更新 status：

public void audit(Long caregiverId, AuditCmd cmd) {
    Caregiver caregiver = caregiverMapper.selectById(caregiverId);
    if (caregiver.getStatus() != CaregiverStatus.WAIT_AUDIT) {
        throw new BizException("当前状态不可审核");
    }
    caregiver.setStatus(cmd.isPass() ? CaregiverStatus.PASS : CaregiverStatus.REJECT);
    caregiverMapper.updateById(caregiver);
    auditLogService.record(caregiverId, cmd);
}

2. 服务预约与排班防冲突

少儿看护对时间准确性要求高。看护人员可服务时间应拆成时间片，例如 30 分钟一个粒度。预约时使用 Redis 分布式锁或数据库索引防止同一看护人员同一时段被重复预约。

CREATE TABLE care_schedule (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  caregiver_id BIGINT NOT NULL,
  start_time DATETIME NOT NULL,
  end_time DATETIME NOT NULL,
  status TINYINT DEFAULT 0, -- 0可预约 1已锁定 2已预约
  order_id BIGINT DEFAULT NULL,
  UNIQUE KEY uk_caregiver_time (caregiver_id, start_time)
);

下单时先锁时段，再创建订单：

String lockKey = "care:schedule:" + caregiverId + ":" + startTime;
Boolean locked = redisTemplate.opsForValue()
        .setIfAbsent(lockKey, "1", Duration.ofSeconds(10));
if (!Boolean.TRUE.equals(locked)) {
    throw new BizException("该时段已被预约");
}
try {
    scheduleService.lock(caregiverId, startTime, orderId);
    orderService.create(orderCmd);
} finally {
    redisTemplate.delete(lockKey);
}

3. 订单状态机

订单状态不要散落在各个接口里，建议统一状态机：

待接单 -> 已接单 -> 服务中 -> 待确认 -> 已完成
   |         |         |
   v         v         v
已取消    已取消    异常关闭

状态流转必须校验前置状态和操作角色。例如只有家长可以确认完成，只有看护人员可以开始服务，管理端可以强制关闭异常订单。可以定义枚举：

public enum OrderStatus {
    WAIT_ACCEPT, ACCEPTED, SERVING, WAIT_CONFIRM, FINISHED, CANCELED, ABNORMAL
}

每次流转记录操作日志，便于后续追溯。涉及少儿看护时，服务中的打卡、位置上报、看护日志都应绑定订单 ID，形成完整证据链。

4. 消息推送与隐私号

消息推送要覆盖订单创建、接单、开始服务、即将超时、服务完成、报警等节点。推荐组合：

• WebSocket：管理端和 APP 在线实时消息。
• 小程序订阅消息：关键节点触达家长。
• APP 推送：离线通知。
• 短信或语音：仅用于紧急报警等强触达场景。

隐私保护方面，家长和看护人员之间的沟通可通过虚拟中间号完成。订单创建后绑定双方号码，订单完成或取消后解绑。这样双方看不到真实号码，减少骚扰和隐私泄露风险。报警功能建议支持长按触发，自动向紧急联系人和管理端发送当前位置、订单信息和时间戳。

四、安全、隐私与多城市部署

儿童相关数据属于敏感个人信息，系统设计要遵循小必要原则。家长端只展示看护人员必要信息，管理端按角色控制数据范围，日志中避免记录完整身份证号、。数据库敏感字段应加密存储，接口返回时脱敏。

多城市自营部署建议：

1. 配置中心维护城市列表、服务范围、可预约时段、报警联系人。
2. 所有业务查询强制携带 city_id，避免跨城市数据串扰。
3. 使用 Docker + Nginx 部署，后端无状态化，Session 放入 Redis。
4. 定时任务处理超时未接单、服务超时、自动确认和消息重试。
5. 接入监控与日志系统，重点监控订单状态异常、报警事件和接口错误率。
6. 灰度发布时按城市放量，先小范围验证再全量。

安全上还要注意：看护人员资质到期前提醒复审；服务过程中禁止家长端直接下载看护人员原始证件；报警事件必须闭环处理，记录处理人、处理时间和结果。

五、FAQ

Q1：本地少儿看护系统和普通家政预约系统有什么区别？
普通家政更关注撮合和履约，本地少儿看护系统还要强化资质审核、儿童隐私保护、紧急报警、服务过程留痕和订单可追溯。

Q2：如何保证看护人员资质真实？
至少做实名认证、证件上传、后台人工审核、有效期管理。关键资质可增加第三方核验，但应避免在前端暴露完整证件信息。

Q3：多端适配推荐什么技术栈？
用户端和看护端可用 uniapp，一套代码编译到小程序、公众号 H5、iOS 和 Android；管理端用 Vue + ElementUI，后端用 Spring Boot + MyBatis-Plus + MySQL。

Q4：订单状态如何防止并发冲突？
使用统一状态机校验前置状态，数据库更新时加版本号或状态条件，例如 UPDATE orders SET status = ? WHERE id = ? AND status = ?，再配合 Redis 锁处理预约时段竞争。

Q5：隐私号如何实现？
订单创建后调用隐私号服务绑定双方号码，通话走中间号；订单完成或取消后立即解绑。系统只保存绑定关系，不保存真实号码明文。