大雄行为锻炼做了几年Java后端，踩过各种业务系统的坑，说实话，大部分管理系统的难点根本不在技术，而在业务建模是否合理。这次要分享的这套基于Spring Boot的现代化家政管理系统，跟普通的CRUD项目不太一样，它把智能家居设备数据和家政服务流程打通了。简单说，就是家里某个传感器触发异常，系统能自动生成工单、派单给保洁或维修人员，而不是等用户手动在App里下单，这是我认为它值得拿出来聊聊的核心原因。如果你正打算做类似的家政平台、上门服务系统，或者想把物联网设备接入业务系统，这篇文章的落地思路和坑点能帮你少走不少弯路。
项目技术栈以Spring Boot为核心，配合MyBatis做持久层，MySQL存业务数据，Redis扛热点和分布式锁，再通过消息队列接收设备上报的事件。后面会从需求拆解、技术选型、数据库设计、核心功能实现到问题排查一条线讲清楚，不贴大段无用代码，重点讲清楚每一步为什么这么设计，以及哪些地方容易翻车。
1. 项目整体定位与需求拆解
1.1 这个系统到底要解决什么问题
传统家政管理系统市面上不少，但绝大多数本质上是“人工派单工具”，用户下单、客服电话确认、派单员手动找阿姨、阿姨上门后再电话回访。整个链条依赖大量人工协调，而且用户和家政人员之间的信息是断裂的。这套系统想解决的，就是把这个过程线上化、自动化，再叠加智能家居设备的联动能力，让系统具备了“主动发现需求”的能力。
最有代表性的场景是这样的：用户家里装了空气质量传感器，某天厨房的油烟浓度异常升高，系统识别到厨房清洁需求，自动给用户推送提醒并生成一个厨房深度清洁工单，用户在手机上确认或改期，系统按距离、评分、忙闲状态自动派单。这种体验跟传统“用户先发现问题再找服务”的路径完全不同，需求是被系统提前捕捉到的，这就是标题里“智能家居新革命”的落点。
考虑到实际开发范围，系统不能一开始就把所有智能家居品牌都接入，我按接入成本分了三层：第一层是系统自身管理的智能设备，比如平台自己提供的智能门锁和传感器；第二层是接入主流开放平台协议的设备；第三层才是后续可扩展的第三方生态。开发时按第一层和第二层做，第三层预留接口，避免一开始就陷入设备适配的无底洞。
1.2 角色划分与核心业务流程
家政系统的角色比普通电商系统复杂一些，因为它至少牵扯四类人：用户、家政服务人员、平台运营人员、系统管理员。用户关心的是下单是否方便、服务是否准时、售后是否有保障；家政人员关心的是派单是否合理、收入是否透明；运营人员关心的是订单流转是否顺畅、投诉率是否居高；管理员则关心的是整个平台的数据和权限安全。
这四类角色的权限边界必须在设计阶段就划清楚，否则后期开发会非常痛苦。用户端小程序或App的功能包括下单、支付、查看服务进度、评价；家政端包括接单、抢单、上传服务凭证、查看排班与结算；运营端包括订单管理、人员审核、投诉处理、补贴配置、数据统计；管理端则侧重系统配置、权限分配、日志审计和设备管理。
核心业务链条是“需求触发-工单生成-派单-服务-验收-结算”这条主线。需求触发有两种方式，一个是用户主动下单，另一个是设备事件自动触发。这两种方式后续汇聚到统一的工单池，工单池再按策略派单。我特别想提醒的是，工单状态机的设计一定要在编码前画清楚，从待接单到已接单到服务中到待验收到已完成再到已取消，每个状态之间的合法迁移路径必须明确，否则后面写业务逻辑时会到处是if else，根本维护不动。
1.3 智能家居联动场景怎么落地
智能家居联动不能做成噱头，必须落到具体的业务流程和数据结构上。我梳理了三个优先级最高的场景，开发时先做这三个，其他场景后续扩展。
第一个是空气质量异常联动保洁。系统接入空气传感器数据，当PM2.5或VOC指标连续15分钟超过阈值，生成一条保洁类工单，并标记触发来源为“设备联动”。第二个是智能门锁联动上门服务。家政人员到达用户家门口时，通过系统申请临时开锁权限，用户在App端确认后，系统生成一次性有效期的临时密码，服务完成后权限自动过期。第三个是智能水电表联动维修。当水表或电表数据出现异常波动，比如漏水或电器短路特征，系统自动推送维修建议给用户，用户一键确认生成维修工单。
这三个场景对系统的要求差异很大，第一个依赖规则引擎或至少是配置化的阈值规则，第二个依赖权限控制和安全策略，第三个依赖异常检测算法。开发时我建议先把场景做薄，阈值和规则做成配置项，不要硬编码在业务代码里，后续调整阈值时就不用发版了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术栈选型逻辑：为什么是Spring Boot这套组合
2.1 框架选型的现实考量
Spring Boot能成为这套系统的首选，原因其实不复杂：生态成熟、招人容易、坑少、社区资料全。虽然现在Java领域也有Quarkus、Micronaut这些新秀，启动更快、内存占用更低，但考虑到家政管理系统这类业务系统的真实需求是稳定和可维护，而不是极致性能，Spring Boot的稳定性和周边生态优势就体现出来了。
实际开发中，Spring Boot的自动配置帮我们省了大量样板代码。一个依赖、一段配置就能把数据源、事务、缓存、消息队列全部串起来。尤其在做原型验证时，Spring Boot项目几分钟就能跑起来。不过也别把Spring Boot神话了，它只是降低了开发门槛，真正的架构设计还是得自己拿主意。
Spring Boot版本的选择也很关键。我这次用的Spring Boot 3.x，它基于Java 17，相比2.x有几个明显变化：javax包名改成了jakarta、AOT编译和GraalVM原生镜像支持更成熟、安全组件的API也有调整。如果团队对Java 17不熟，可以先选2.7.x过渡，但新项目我建议直接上3.x，毕竟2.x的维护窗口在逐渐收窄。
2.2 MyBatis还是JPA，这是个需要认真权衡的问题
持久层我选了MyBatis而不是Spring Data JPA，这个选择可能跟不少人的预期不太一样。因为家政系统的查询逻辑非常复杂，涉及多表关联、动态条件、复杂的订单统计SQL，MyBatis的XML SQL映射在这种场景下优势明显，SQL是显式可控的，调优时可以直接改SQL，执行计划也能精准分析。
JPA的强项是CRUD简单场景和领域模型驱动设计，但一旦查询复杂起来，要么写JPQL，要么走原生SQL，反而绕了一圈。而且JPA的N+1问题需要开发者对懒加载机制非常熟悉才能避免，团队里如果有人不熟的话很容易写出性能极差的查询。MyBatis没有这个问题，因为它默认就是手写SQL，查什么自己心里有数。
我用MyBatis-Plus做增强，单表CRUD可以直接用内置方法，多表复杂查询再写XML。这个组合在中小规模项目里效率很高。需要提醒的是，MyBatis-Plus的逻辑删除和MyBatis的二级缓存不要同时用，否则容易出现数据不一致。另外分页插件用官方PaginationInnerInterceptor，不要去网上随便抄一个分页实现。
2.3 基础设施与部署方案
这套系统的中间件包含MySQL 8.x存业务数据、Redis存缓存和分布式锁、RabbitMQ做设备消息和工单事件的异步解耦、MinIO做文件存储，包括服务凭证照片和执行报告文件。选型逻辑遵循一条原则：每一件中间件都必须在系统里有不可替代的场景，不为存在感引入组件。
部署方面用Docker Compose编排所有服务，单机环境下一台4核8G的服务器足够支撑中小规模家政平台。如果后续量上来了，可以按模块拆分部署，Spring Boot应用支持多实例，网关层用Nginx做负载均衡即可。开发调试时用IntelliJ IDEA社区版也完全够用，不需要破解企业版，社区版的Spring Boot插件和Maven集成已经满足大部分场景。
关于Spring Boot项目端口冲突的问题，我们开发时经常遇到，总共两个解决办法：在application.yml里改server.port，或者启动时用命令行参数指定端口。如果遇到8080被占用的情况，直接用--server.port=8081参数启动就行。Debugger启动时端口不一致问题，多半是IDE里配置了固定的JMX端口，改掉就能解决。
3. 数据库设计：一张表一张表讲清楚
3.1 用户与家政人员角色设计
用户表设计的关键不是字段多，而是把不同类型用户的关键差异抽象出来。我拆成了三张表：user表存所有账户的公共信息，user_profile表存用户的扩展资料，worker表存家政人员的专业属性。这种垂直拆分的思路在权限体系里被验证过很多次，比在user表里堆一堆稀疏字段要科学得多。
user表的核心字段包括id、phone、password_hash、nickname、avatar_url、role_type、status、create_time，其中phone用唯一索引，因为手机号是家政系统最常见的登录凭证。password_hash用BCrypt加密存储，绝对不允许明文。role_type用int类型，1-用户，2-家政人员，3-运营，4-管理员，后续接RBAC权限框架时可以直接映射到角色表。
worker表里需要冗余一些信息，因为它单独存储接单相关的必要字段，比如service_type表示服务类型，包括保洁、维修、保姆、月嫂等；id_card_verified表示实名认证状态；avg_score表示平均评分；order_count表示累计接单量。这些字段在派单算法里都会被用到，单独抽出来是为了避免派单场景每次都去聚合订单表统计评分和单量，查询压力会大很多。
3.2 预约订单与工单状态机
订单相关表是整个系统的核心，我拆成order表、order_item表和work_order表。order表管支付和金额相关的信息，比如订单号、总金额、优惠金额、实付金额、支付状态、支付时间；order_item存订单里具体购买的服务项目，比如“厨房深度清洁”和“阳台玻璃擦拭”是两个条目；work_order表则面向履约过程，存派单状态、家政人员ID、服务时间、完成情况。
工单状态机我用一个state字段标识，包含以下状态流转：PENDING（待接单）、ACCEPTED（已接单）、IN_PROGRESS（服务中）、COMPLETED（已完成）、CANCELLED（已取消）、REFUNDED（已退款）。从待接单可以直接取消，从已接单之后取消需要走运营审批。这个状态机在写业务逻辑之前就固定下来，后续所有状态变更都走统一的状态流转服务，避免散落的代码到处改状态。
说到订单号，这虽然是个小细节但坑很多。用数据库自增ID做订单号绝对要避免，因为外部订单号容易被爬虫猜到业务量。我采用“日期+业务线标识+随机数”的格式，比如OD20240315001，其中OD代表订单，20240315是日期，001是当天序号，再做一个全局发号器保证不重复。Redis的INCR命令可以生成这种序号，一天一个key自动过期，简单又高效。
3.3 智能设备事件与联动规则表
设备相关的表设计决定智能家居联动能不能跑通。device表存设备基础信息，包含device_id、user_id、device_type、protocol_type、status、last_online_time。device_event表存设备上报的原始事件，包含event_id、device_id、event_type、event_data、create_time，其中event_data用JSON格式存设备上报的原始数据，因为不同设备的字段差异实在太大，强行定结构化字段会非常痛苦。
device_rule表是联动规则配置的核心。它的字段包括rule_id、user_id、device_type、event_type、threshold_value、action_type、action_config、is_active、create_time。action_config也是JSON，比如action_type为CREATE_ORDER时，action_config里就存“工单类型=保洁、优先级=高、备注=设备联动触发”这些配置。把联动规则做成配置化，即使不懂技术的运营也能在后台配置新规则。
联动流程是这样的：设备上报事件到消息队列，规则引擎消费事件，匹配用户的活跃规则，触发对应的动作。原始事件必须保留至少30天，因为后面要排查“为什么这个传感器没触发工单”这类问题，没有原始事件数据根本查不出原因。数据表要定期归档，避免event表无限膨胀。
3.4 评价与结算体系
评价表review表字段包括review_id、order_id、worker_id、user_id、score、content、images、create_time。这里有一个点多说一句，order_id必须加唯一索引，保证一笔订单只能评价一次。如果用户修改评价，不要在原记录上update，而是用version字段做乐观锁，保留修改历史，避免恶意用户反复修改刷评分。
结算表settlement表管家政人员的收入，字段包括settlement_id、worker_id、period_start、period_end、order_count、total_amount、commission_amount、actual_amount、status。结算周期一般按周或按半月，status字段标记待确认、已确认、已打款。结算设计要清楚区分平台抽佣和家政人员实收，比例配置不要写死在代码里，做成系统参数表，运营调整抽佣时不用发版。
评价和结算之间有一个潜在联动关系，差评或者投诉会影响到结算金额，比如平台可以规定当周好评率低于某个阈值时，奖励部分扣减。这个规则在结算设计初期就要预留字段，否则后面加逻辑会非常痛苦。
4. 核心功能实现与关键代码落地
4.1 智能派单算法的简单实现
派单算法是家政系统的技术亮点，但也没必要一上来就上机器学习，对大多数场景来说，一个加权评分算法就够用。我的实现思路是：对每个候选家政人员计算一个综合得分，按得分从高到低排序，选取Top3进入候选池，再从候选池里结合接单意愿和信用分最终决策。
综合得分等于距离权重、评分权重、忙闲权重和历史完成率的加权和。距离越近得分越高，但分值不是线性递减，而是按档位计分；评分权重由avg_score决定；忙闲权重看当天的order_count，接单越多得分越低；历史完成率权重保证那些接了单却频繁取消的人员排名靠后。这个算法的参数我建议做成可配置的，比如房价调整对象和系数，运营根据实际订单转化率去调整，而不是开发人员拍脑袋定死。
算法实现上要注意一个细节，查询候选家政人员时，不要用全表扫描然后内存里计算距离，这样在人员数过千时会明显变慢。数据库层面先通过经纬度范围过滤，比如只查询服务点5公里内的家政人员，再进入评分计算，这样性能能快一个数量级。经纬度范围的计算可以用MySQL的空间函数，也可以用简单的等经纬度估算。
4.2 设备事件触发工单的消费逻辑
设备事件这部分的核心是一个消息队列消费者，它消费device_event队列，拿到事件后查询用户关联的规则，命中规则就执行动作。这里有一个容易踩的坑：消费逻辑里一定不能直接用设备ID拼SQL去查规则，因为规则是用户维度的，设备ID关联用户再匹配规则，至少要两次查询，性能脏且慢。
我的做法是在消费时把device_event里的user_id冗余一份，因为设备上报时就已经知道归属用户了，这样生产者直接把userId放进消息体，消费者直接按userId查规则，一次查询搞定。消息体设计为包含eventId、userId、deviceType、eventType、eventData、timestamp，List
消费者幂等性是必做的。RabbitMQ默认至少一次投递，如果消费者处理完业务但没来得及确认消息就挂了，重投后会把事件再处理一遍，导致重复生成工单。我用Redis的SETNX做一个事件幂等键，key是eventId，value是处理标识，过期时间设成24小时，处理前先尝试写入，写不进去就说明已经处理过，直接确认消息丢弃。
规则匹配的优先级也要处理好。同一个用户可能配置了多条规则，比如空气净化器事件既配置了“生成保洁工单”，又配置了“推送提醒”，这两条规则可能都命中。我在规则表里加了一个priority字段，优先级高的先执行，同一优先级按创建时间正序执行。这个设计后期加规则时非常舒服，不用改代码。
4.3 权限控制与安全管理
权限控制我用Spring Security加JWT的方式，没有引入Spring Cloud Gateway，因为现阶段单体应用够用，没必要拆微服务增加运维负担。JWT token存userId和roleType，过期时间一般是2小时，Redis里存一个refreshToken用来续期，到期后用户无感刷新。
做权限控制时要特别注意接口粒度的把控，按钮级权限不用做，做好接口级就足够了。我用了@PreAuthorize注解结合角色表达式，比如@PreAuthorize("hasRole('WORKER')")控制家政端接口，这样可以在方法级别做精确控制。但别滥用注解权限，否则权限规则分散在各处，排查权限问题时很头疼。
安全管理还有几个容易漏的地方。第一个是文件上传漏洞，上传接口必须校验文件类型、大小和内容，不能只信前端传来的Content-Type。我这边上传的头像和凭证图片都走MinIO的预签名URL，服务器不落盘，文件类型用服务端做二次校验。第二个是SQL注入，MyBatis的#{}已经做了预编译，但你要是图省事用${}拼SQL，就有被注入的风险，这块要在Code Review时重点盯。第三个是XSS攻击，用户评价、昵称这些富文本字段要统一做转义处理。
4.4 消息推送与通知
通知系统的设计与联动场景强相关。当设备触发工单、工单被接受、服务完成、结算到账这些关键节点，用户和家政人员都需要收到通知。我实现的方案是WebSocket推送加短信兜底，WebSocket负责App和小程序里的实时消息，短信负责重要节点的兜底通知。
WebSocket这块用Spring的WebSocket支持，但生产环境前端一般通过Nginx反向代理，这里要配置WebSocket升级路径，否则长连接建不起来。心跳机制一定要做，客户端每30秒发一次ping，服务端收到后回pong，超过90秒没心跳就断开重连。不做心跳的话，运营商NAT超时会导致连接假死，用户收不到消息，这是非常常见的生产事故。
如果项目里接了第三方消息服务，要注意异步处理。短信发送接口是慢接口，动不动几百毫秒，绝对不能同步阻塞在主业务链路里，我这边全走消息队列异步消费，发送失败重试三次，最终失败进失败表人工处理。把消息发送做成独立的notify模块，后续换供应商时只改这一个模块，对业务无感。
5. 常见问题与排查技巧实录
5.1 事务失效：一个隐藏很深的坑
事务问题是家政系统里最容易犯的经典错误，而且Spring的事务失效场景非常隐蔽。最常见的失效场景是方法内部调用，比如A方法调用了同类里的B方法，B方法上标了@Transactional，但实际上事务不生效，因为Spring事务是通过代理对象实现的，同类内部走的是this调用，绕过了代理，事务自然失效。
解决办法是把B方法移到另一个Service，或者通过AopContext.currentProxy()获取代理对象再调用。我后续在做代码规范时统一约定，事务方法不允许同类内直接调用，必须通过注入的自身代理接口调用。还有一个注意事项是@Transactional只对RuntimeException回滚，checked exception默认是不回滚的，如果要checked exception也回滚，得显式指定rollbackFor = Exception.class。
另外，事务粒度控制也很重要。订单创建链路涉及创建订单、创建工单、扣减优惠券、发送消息，这四步要么全成功要么全失败。但你如果把消息发送也放进同一个事务，会出现消息堆积和事务时间过长的问题。我的做法是主事务只处理订单、工单、优惠券三个写库操作，消息发送放在事务提交后的监听事件里（用@TransactionalEventListener配合AfterCommit），这样既保证数据一致，又不会阻塞主事务。
5.2 批量插入性能优化：从几十秒到几百毫秒
系统上线后遇到一个实际问题：运营后台要批量导入家政人员的服务项目，一次导入几千条，用MyBatis-Plus的saveBatch方法居然要几十秒。这个问题的根源在于MySQL默认的JDBC驱动不开批处理，需要手动在jdbc url里加上rewriteBatchedStatements=true，这个参数加上后批量插入性能能提升一个量级。
还有一个隐藏更深的坑是：即使开了批处理，MyBatis-Plus的saveBatch里还是有反射和拼接的损耗。后来我自己写了一个统一的BaseBatchMapper，用底层的SqlSession批量提交，每500条提交一次，性能进一步改善。实测导入5000条数据，从28秒降到400毫秒，效果非常明显。
如果插入的数据里包含大字段，比如Json字符串，要注意单条SQL的大小限制。MySQL的max_allowed_packet默认值是4M，批量插入过多大字段时可能直接报错，这时候可以把批大小调小，或者调大数据库的这个参数。实际调优时我先用EXPLAIN分析SQL执行计划，再决定从批大小还是索引方向去优化。
5.3 第三方接口超时：设备接入时的血泪教训
接入第三方设备平台API时，最让我头疼的是它们的接口超时机制各不相同。有些设备商的服务质量很差，接口响应经常5秒、10秒甚至更久。如果我这边同步调用，一个接口卡住，整个请求线程就跟着卡住了，继而线程池被占满，线上故障就是这么来的。
我的解决方案是双保险。第一层是HTTP客户端设置连接超时和读取超时，连接超时3秒，读取超时5秒，超过就快速失败。第二层是把外部接口调用全部异步化，走消息队列隔离，不让第三方接口的延迟影响到核心业务链路的稳定性。查询类接口做本地缓存加Redis缓存，比如设备商的令牌获取，缓存的过期时间比真实过期时间提前几分钟，防止缓存过期瞬间大量请求打到第三方。
调用第三方接口时的链路追踪也必须有。我在日志里统一打印traceId，整个调用链从设备消息进入到工单生成，用同一个traceId贯穿。排查问题时直接grep traceId就能看到完整的调用链路，否则在微服务和消息队列组成的复杂调用链里，出了问题根本无从下手。
5.4 定时任务重复执行与数据一致性问题
系统里有几个定时任务，比如订单超时自动取消、结算周期自动计算、设备离线状态巡检。最开始我用Spring自带的@Scheduled注解，单机跑没问题，但后来应用做了多实例部署后，出现了所有实例同时执行定时任务的问题，重复取消订单、重复生成结算单，数据一致性直接崩了。
解决定时任务重复执行，网上方案不少，但我最推荐的是用Redis分布式锁。具体做法是给每个定时任务指定一个唯一锁key，执行前通过SETNX加锁并设置过期时间，只有加锁成功的实例才执行任务。为了防止任务执行时间超过锁过期时间导致锁被提前释放，还要在finally里释放锁之前校验一下值是否是自己的，或者用Redisson的看门狗机制自动续期。
还有定时任务执行超时的问题。比如离线设备巡检任务要扫描几万台设备，单线程跑可能要十几分钟。我把任务拆成按用户ID分片执行，每个分片处理几千个用户，分片间用不同线程去跑。如果执行过程中有分片失败了，下次执行时通过状态标记只处理未完成的分片，不做全量重扫。这样既避免了重复处理，也不会因为单点失败导致整个任务白跑。
写在最后：几点真实的体会
这套系统开发下来，我最深的感受是：Spring Boot确实降低了开发门槛，但家政管理系统的复杂度一点都不比电商系统低，反而因为牵扯线下服务、人员调度、设备接入，逻辑链条更长。如果只是把它当成一个CRUD项目来做，后期一定会在业务逻辑里痛苦挣扎。务必在编码前把工单状态机、角色权限、结算规则这些核心模型想清楚，这些才是系统的骨架，技术只是骨架上的骨肉。
另外，日志埋点和监控一定要从第一天就做好，不要等项目上线后才补。我这边接入了Spring Boot Actuator暴露健康检查和指标，再配合Spring Boot Admin做应用监控面板，你可以实时看到各个接口的响应时间、线程池状态、JVM内存使用情况。很多线上诡异问题，没有监控数据根本定位不了。第三方的接口调用也都打上了traceId，配合日志平台可以全链路排查，这套基础设施花不了多少时间，但带来的收益远远大于成本。
如果你准备做类似的家政系统，或者想给自己的业务系统加一些自动化联动能力，建议先把核心场景做透，再扩展周边功能。比如先把订单、工单、派单这条主链路跑通，再接设备联动，不要一开始就追求大而全。我在实际开发中的体会是，把一个小闭环打磨到极致，比铺开十个小功能却个个试水的效果好得多。这套系统的后续扩展方向还很多，比如增设会员体系、构建更复杂的计费规则、兼容更多智能家居协议，每次扩展都意味着新的挑战和经验积累。希望这篇实操记录能给你一些可复用的思路，一起少踩几个坑。