java运行// 源对象：UserDO（数据库实体）@Data // Lombok 注解// 字段名不一致示例// 目标对象：UserVO（前端展示）@Data// 对应 id// 对应 userName// 格式化后的创建时间通过@Mapper注解声明映射接口，指定让 Spring 管理 Bean：java运行/*** 映射接口* componentModel = "spring"：生成的实现类

在集群模式下，由于是单机本地调度器，每个服务实例都会独立运行并触发定时任务，从而导致任务重复执行。要解决这个问题，核心思路是引入机制，确保同一时刻只有一个节点能成功获取到执行权限。

Java 泛型擦除是为了兼容老版本而做出的妥协。它把类型安全检查的工作全部交给了编译器，从而保证了运行时的效率和兼容性，但也因此带来了一些使用上的限制。这也正是为什么在 Fastjson 等框架反序列化时，必须通过。

纯原生实现：完全基于 Spring Boot 自带的，无需引入任何沉重的第三方调度框架，代码非常轻量。动态控制：通过存储，完美实现了任务的动态添加、删除、启动和停止。状态持久化：结合iot_task表和，确保了任务配置和运行状态在系统重启后依然能够保持一致。

组件角色定位通俗比喻地基与总管像是房子的地基和水电总闸，提供了运行环境和基础能力。对外接口像是大门和邮筒，专门负责和外部特定的系统（MQTT 服务器）收发信件。内部流水线像是屋内的传送带和处理工人，负责把大门收进来的信件进行筛选、加工和流转。通过这三者的结合，可以轻松构建出一个既能与物联网设备通信，又能在内部高效处理业务逻辑的消息驱动应用。

在 Spring Boot 中，前端传递下划线命名（如 ）的参数，后端使用驼峰命名（如 ）接收是非常常见的需求。 具体的处理方式取决于请求方式和参数格式。以下是几种主流且优雅的解决方案：方式一：全局配置（一劳永逸）如果你的请求是 POST/PUT，并且以 JSON 格式（）发送，Spring Boot 默认使用 Jackson 进行反序列化。你有两种方式处理：2. GET 请求或表单提交的处理方式

性能根源SpringBoot MQTT 客户端性能瓶颈90% 来自底层 SDK 线程模型 + 业务回调阻塞，而非 Spring 框架本身。选型建议设备连接< 1000、低吞吐：Paho / Spring Integration MQTT，开发效率优先。设备连接> 1000、高吞吐采集：强制使用Netty-MQTT。万级以上设备：不要让 SpringBoot 直连设备，采用EMQX 集群 + 业务服

性能根源SpringBoot MQTT 客户端性能瓶颈90% 来自底层 SDK 线程模型 + 业务回调阻塞，而非 Spring 框架本身。选型建议设备连接< 1000、低吞吐：Paho / Spring Integration MQTT，开发效率优先。设备连接> 1000、高吞吐采集：强制使用Netty-MQTT。万级以上设备：不要让 SpringBoot 直连设备，采用EMQX 集群 + 业务服

✅推荐用 MP 做查询 + 分页 + 插入表结构按 IoTDB 设计哲学来UPDATE 全部手写 SQL核心业务数据仍用 MySQL / PostgreSQL❌不推荐用 MP 的 update / saveOrUpdate用逻辑删除、乐观锁把 IoTDB 当纯 OLTP 数据库。

可以根据团队规范定制：统一的公司内部依赖版本特定的代码规范检查规则自定义的目录结构团队内部的插件配置这些模板可以直接使用，也可以根据你的具体需求进行组合和修改。建议先从开始，这是最常用的场景。