企业官网建设流程全解析

QQ机器人定时任务在实际项目中非常常见：每天早上给群成员推送天气、每周一发送周报提醒、整点播报新闻、定时清理群成员、定时执行签到抽奖等。表面上看，这只是“定时器 + 发消息”两个功能叠加，但真正落地时会遇到任务配置、执行时间、失败重试、重复执行、多节点并发等一系列问题。这篇文章围绕 QQ 机器人场景，从最基础的 Spring Schedule 开始，一步步讲到 Quartz 动态任务，再扩展到 XXL-Job 分布式调度，每个阶段都给出可运行的代码和排查思路。

文章面向已经会用 Spring Boot 写接口、但还没在项目里完整做过定时任务的开发者。如果你只是想在个人机器人上挂一个定时推送，可以直接看第 3 章；如果任务数量会增长、需要可视化管理和失败重试，重点看第 4 章和第 5 章。整个过程会区分“单机够用”和“生产必须考虑”的边界，避免一开始就把架构做复杂。

1. 先理清 QQ 机器人定时任务的技术链路

1.1 定时任务要解决什么问题

定时任务不是一个独立技术，而是“时间触发”和“业务动作”的组合。时间触发部分解决的是“什么时候执行”，业务动作部分解决的是“到了时间做什么”。在 QQ 机器人场景里，业务动作通常就是调用机器人接口发送消息、查询数据、生成报表、更新状态。

很多第一次做定时任务的开发者，会把注意力全放在“写一个循环 + sleep”上：

while (true) { sendMessage("早上好"); Thread.sleep(24 * 60 * 60 * 1000); }

这种写法在测试时能跑，但进入真实项目很快会遇到问题：应用重启后计时丢失、执行时间无法灵活配置、多线程并发时 sleep 会阻塞资源、没有失败记录、排查困难。定时任务框架要解决的不是“能不能定时”，而是“定时是否可靠、是否灵活、是否可观测”。

一个合格的定时任务设计至少要考虑五件事：

• 触发时间：什么时候执行，是否支持 cron 表达式。
• 并发控制：任务执行期间，新的触发是否要等待或跳过。
• 持久化：应用重启后任务配置是否还在。
• 失败处理：发送消息失败是否需要重试或告警。
• 审计日志：哪次任务成功、哪次失败、执行耗时多少。

QQ 机器人的定时推送尤其需要关注失败处理。因为消息发送依赖网络和平台接口，任何一次超时、限流或 token 过期都会导致任务“执行了但用户没收到消息”。

1.2 定时任务和机器人消息推送如何配合

QQ 开放平台机器人接入后，常见的工作模式有两种。

第一种是被动回复模式。用户在群里 @ 机器人或私聊机器人，平台通过 Webhook 或 WebSocket 把消息推送到你的服务，服务处理完调用接口回复。这种模式不需要定时任务参与。

第二种是主动推送模式。服务端在某个时间点主动调用机器人接口发送消息，比如每天早上八点推送早报。这里就必须有一个定时任务在背后触发。

第二种模式在项目上可以拆成三层：

调度层：负责在指定时间触发任务。 业务层：负责组装消息内容，比如查询天气、汇总数据。 发送层：负责调用 QQ 机器人接口，把消息发送到指定群或用户。

三层分开写的好处是：调度层可以替换，从 Spring Schedule 换成 Quartz，再换成 XXL-Job，业务层和发送层不用大改。这也是本文所有示例遵守的结构。

下面是一个最小分层示意：

// 发送层：统一封装机器人消息发送 public interface RobotMessageSender { void sendText(String targetId, String content); }

// 业务层：组装通知内容 public interface DailyReportService { String buildDailyReport(); }

// 调度层：定时触发业务层和发送层 @Component public class DailyReportJob { private final DailyReportService reportService; private final RobotMessageSender messageSender; public DailyReportJob(DailyReportService reportService, RobotMessageSender messageSender) { this.reportService = reportService; this.messageSender = messageSender; } public void execute() { String content = reportService.buildDailyReport(); messageSender.sendText("群ID", content); } }

实际项目里，RobotMessageSender的实现就是调用 QQ 开放平台接口的客户端。不同版本的 SDK 方法名可能不同，但职责边界是一致的。

1.3 本地单机与分布式任务的区别

服务只有一个实例时，定时任务逻辑很简单：Spring 容器启动一个调度器，到点执行。但生产环境为了保证可用性，应用通常会部署两个节点以上，这时同一个定时任务会因为负载均衡或各自调度而出现“重复执行”。

举例说明。早报任务配置为 08:00 执行，服务部署了两个节点，每个节点都启动了定时任务，那么 08:00 时两个节点都会发送早报，群里出现两条内容。

解决重复执行有三种思路：

• 单机任务，人为保证只部署一个节点。
• 使用分布式锁，只有拿到锁的节点执行任务。
• 使用分布式调度框架，由调度中心统一分配任务，只让一个执行器执行。

前两种适合任务量少的场景，第三种是 XXL-Job 这类框架提供的方案。对于 QQ 机器人场景，绝大多数任务频率低、计算量小，优先保证不重复执行比追求高并发更重要。因为用户收到重复消息的体验非常差，而且平台对主动消息频次往往有限制，重复推送容易触发限流。

2. 环境准备与项目初始化

2.1 版本和依赖准备

本文示例基于 Spring Boot 3.x + JDK 17，这个组合在 2024 年之后的 QQ 开放平台机器人相关项目里已经是主流。如果你的团队还在使用 Spring Boot 2.x 或 JDK 8，代码主体不需要大改，但要注意javax和jakarta包名差异。

推荐环境如下：

如果原始资料没有指定机器人 SDK 版本，落地前要先到 QQ 开放平台文档确认最新的接入方式。不同时期的 SDK 在包名、注解、回调方式上会有差异。

2.2 创建 Spring Boot 项目

建议通过 Spring Initializr 创建项目，依赖选择：

Spring Web Lombok Validation MySQL Driver Spring Data JPA 或 MyBatis

项目基础结构如下：

qq-robot-scheduler ├── pom.xml ├── src/main/java/com/example/robot │ ├── RobotApplication.java │ ├── common │ ├── scheduler │ ├── service │ ├── sender │ └── job └── src/main/resources └── application.yml

pom.xml中先添加基础依赖，后续按章节再补充 Quartz 或 XXL-Job 相关依赖。

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>3.2.4</version> </parent> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-validation</artifactId> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> </dependencies>

2.3 接入 QQ 机器人消息发送通道

在官方机器人方案中，服务端主动发消息需要先获取访问凭证，再调用消息发送接口。不同接口的请求路径和参数以 QQ 开放平台文档为准，下面只给出一个可替换的发送层实现框架。

@Service public class QQRobotMessageSender implements RobotMessageSender { private final String appId; private final String appSecret; public QQRobotMessageSender( @Value("${qq.robot.app-id}") String appId, @Value("${qq.robot.app-secret}") String appSecret) { this.appId = appId; this.appSecret = appSecret; } @Override public void sendText(String targetId, String content) { String token = getAccessToken(); // 调用机器人发送消息接口 // 这里需要根据官方 SDK 或 HTTP API 文档填充具体请求 } private String getAccessToken() { // 获取 access_token，带缓存，避免每次发送都请求 return ""; } }

这里要注意：getAccessToken()不能每次发送都重新请求，一是耗时，二是容易触发平台限流。正确做法是把凭证缓存起来，在过期前的时间提前刷新。

注意：主动消息发送通常有频率限制和场景限制。开发联调阶段先使用测试群，不要在生产大群直接验证，否则可能因为频次过高导致机器人被限制。

3. 用 Spring Schedule 搭建最小定时任务

3.1 开启定时能力

Spring Boot 使用 Spring Schedule 非常简单，只需在启动类上添加@EnableScheduling。

@SpringBootApplication @EnableScheduling public class RobotApplication { public static void main(String[] args) { SpringApplication.run(RobotApplication.class, args); } }

这个注解的作用是开启 Spring 对@Scheduled注解的扫描和调度支持。没有这个注解，即使方法上写了@Scheduled也不会执行。

3.2 写一个每分钟推送的定时任务

创建DailyReminderJob：

@Component public class DailyReminderJob { private final RobotMessageSender messageSender; public DailyReminderJob(RobotMessageSender messageSender) { this.messageSender = messageSender; } @Scheduled(cron = "0 0 8 * * ?") public void morningReport() { messageSender.sendText("target_group_id", "早上好，今日早报已生成，请注意查收。"); } }

这段代码的含义是：每天 08:00:00 触发任务，向指定群发送一条固定内容。

@Scheduled还支持fixedRate和fixedDelay两种参数：

注意：fixedRate不是从上一次执行结束开始计时，而是从开始时间计时。如果任务执行耗时超过周期，那么下一次触发会等待当前执行结束，但不会重设计时，可能导致周期偏移。

3.3 验证任务是否执行

第一步，在方法入口添加日志：

@Scheduled(cron = "0 0 8 * * ?") public void morningReport() { log.info("daily morning report task started, time={}", LocalDateTime.now()); messageSender.sendText("target_group_id", "早上好"); log.info("daily morning report task finished"); }

第二步，启动应用，把 cron 临时改为每秒执行一次，观察日志输出：

spring: task: scheduling: pool: size: 5

@Scheduled(cron = "*/1 * * * * ?") public void testTask() { log.info("task execute at {}", LocalDateTime.now()); }

如果控制台能持续输出task execute at ...，说明调度链路已经通。验证完记得把 cron 改回正式时间。

3.4 Spring Schedule 的局限

Spring Schedule 在小规模场景下非常方便，几乎没有额外代码。但它有几个明显短板：

• 任务配置写死在代码注解里，修改执行时间必须重新发布。
• 不支持持久化，应用重启后所有运行时改动都丢失。
• 默认单线程池，多个任务相互阻塞。
• 集群部署时会重复执行。
• 没有内置失败重试、告警、任务状态监控。

当机器人任务从三五个增加到几十个，并且产品会临时调整推送时间、运营需要自助配置任务时，Spring Schedule 就不够用了。这时换到 Quartz 是更稳妥的选择。

4. 用 Quartz 实现可动态调整的定时任务

4.1 为什么需要 Quartz

Quartz 在 Spring Schedule 基础上增加了三个关键能力：任务元数据持久化、动态创建和修改任务、暂停和恢复任务。这意味着你可以在运行过程中通过接口临时新增一个机器人推送任务，而不用改代码重启。

Quartz 的核心概念：

4.2 引入依赖和表结构

Spring Boot 对 Quartz 有自动配置支持，引入依赖后设置spring.quartz.job-store-type=jdbc，框架会自动使用数据库持久化。

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-quartz</artifactId> </dependency>

如果使用 JDBC 存储，需要初始化 Quartz 表结构。官方 GitHub 仓库的docs/db/tables_mysql_innodb.sql中有建表脚本，直接执行即可。常见表包括：

QRTZ_JOB_DETAILS QRTZ_TRIGGERS QRTZ_CRON_TRIGGERS QRTZ_SIMPLE_TRIGGERS QRTZ_BLOB_TRIGGERS QRTZ_CALENDARS QRTZ_PAUSED_TRIGGER_GRPS QRTZ_FIRED_TRIGGERS QRTZ_SCHEDULER_STATE QRTZ_LOCKS

配置示例：

spring: quartz: job-store-type: jdbc scheduler-name: RobotScheduler properties: org.quartz.jobStore.isClustered: true org.quartz.jobStore.clusterCheckinInterval: 15000 jdbc: initialize-schema: never

生产环境建议把initialize-schema设置为never，手动执行建表脚本，避免应用启动时自动建表产生权限问题。

4.3 构建 Job、Trigger 和 Scheduler

创建一个机器人推送 Job：

public class RobotPushJob extends QuartzJobBean { private static final Logger log = LoggerFactory.getLogger(RobotPushJob.class); private RobotMessageSender messageSender; @Override protected void executeInternal(JobExecutionContext context) throws JobExecutionException { JobDataMap dataMap = context.getMergedJobDataMap(); String targetId = dataMap.getString("targetId"); String content = dataMap.getString("content"); try { messageSender.sendText(targetId, content); log.info("quartz push success, target={}", targetId); } catch (Exception e) { log.error("quartz push failed, target={}", targetId, e); } } public void setMessageSender(RobotMessageSender messageSender) { this.messageSender = messageSender; } }

这里有一个 Spring 整合 Quartz 的常见坑：QuartzJobBean由 Quartz 自己实例化，不在 Spring 容器管理范围内，所以不能直接使用@Autowired。Spring Boot 的AutowireCapableBeanFactory可以解决注入问题，也可以在executeInternal里通过ApplicationContext获取 Bean。上面的示例用了 setter 注入方式，需要在调度任务创建时手动传递。

更简单的方案是让 Job 内部通过静态 ApplicationContext 获取 Bean，这个写法适合中小项目：

public class RobotPushJob extends QuartzJobBean { @Override protected void executeInternal(JobExecutionContext context) { RobotMessageSender sender = SpringContextHolder.getBean(RobotMessageSender.class); JobDataMap dataMap = context.getMergedJobDataMap(); sender.sendText(dataMap.getString("targetId"), dataMap.getString("content")); } }

4.4 动态调度机器人定时推送

创建任务的服务类：

@Service public class RobotScheduleService { private final Scheduler scheduler; public RobotScheduleService(Scheduler scheduler) { this.scheduler = scheduler; } public void addPushJob(String jobName, String group, String cron, String targetId, String content) throws SchedulerException { JobDetail jobDetail = JobBuilder.newJob(RobotPushJob.class) .withIdentity(jobName, group) .usingJobData("targetId", targetId) .usingJobData("content", content) .storeDurably(true) .build(); CronTrigger trigger = TriggerBuilder.newTrigger() .withIdentity(jobName + "_trigger", group) .withSchedule(CronScheduleBuilder.cronSchedule(cron)) .forJob(jobName, group) .build(); scheduler.scheduleJob(jobDetail, trigger); } }

业务侧通过一个 REST 接口来创建任务：

@RestController @RequestMapping("/schedule") public class ScheduleController { private final RobotScheduleService scheduleService; public ScheduleController(RobotScheduleService scheduleService) { this.scheduleService = scheduleService; } @PostMapping("/push") public ApiResponse createPushTask(@RequestBody CreatePushRequest request) throws SchedulerException { scheduleService.addPushJob( request.getJobName(), request.getGroup(), request.getCron(), request.getTargetId(), request.getContent() ); return ApiResponse.success(); } }

请求体：

{ "jobName": "morning_report", "group": "report", "cron": "0 0 8 * * ?", "targetId": "group_id_123", "content": "早上好，今日早报已发布。" }

这样修改执行时间不需要改代码，只需要调用接口更新 Trigger。

Quartz 的优点是动态能力，缺点是配置复杂，而且集群模式下多节点虽然不会重复调度，但需要依赖数据库锁，调度中心本身没有 UI，任务执行状态和失败告警仍然需要自己开发。对于已经上了微服务或任务数量增长较快的团队，下一步建议引入 XXL-Job。

5. 引入 XXL-Job 解决分布式定时问题

5.1 单机任务在分布式场景下的问题

前面的 Spring Schedule 和 Quartz 方案都有一个共同问题：任务调度逻辑写在自己的应用里。如果你的 QQ 机器人服务部署了两个节点，调度行为会变得不统一，要么重复执行，要么需要额外的选主和协调机制。

XXL-Job 把“调度”和“执行”拆开：调度中心负责按 cron 触发，执行器负责实际执行业务逻辑。调度中心只会选择一个执行器节点下发任务，业务方不需要关心选主问题。

5.2 XXL-Job 的基本组件

XXL-Job 包含两个部分：

• 调度中心：独立部署的 Web 服务，提供任务管理、日志查看、报表等界面。
• 执行器：集成在你的 Spring Boot 应用里，接收调度中心的下发指令并执行任务。

5.3 执行器集成与机器人推送任务

在 Spring Boot 项目中引入执行器依赖：

<dependency> <groupId>com.xuxueli</groupId> <artifactId>xxl-job-core</artifactId> <version>2.4.1</version> </dependency>

配置执行器：

xxl: job: admin: addresses: http://127.0.0.1:8080/xxl-job-admin accessToken: your_token executor: appname: qq-robot-executor address: ip: port: 9999 logpath: ./logs/xxl-job logretentiondays: 30

创建执行器配置类：

@Configuration public class XxlJobConfig { @Value("${xxl.job.admin.addresses}") private String adminAddresses; @Value("${xxl.job.accessToken}") private String accessToken; @Value("${xxl.job.executor.appname}") private String appname; @Value("${xxl.job.executor.port}") private int port; @Bean public XxlJobSpringExecutor xxlJobExecutor() { XxlJobSpringExecutor executor = new XxlJobSpringExecutor(); executor.setAdminAddresses(adminAddresses); executor.setAppname(appname); executor.setPort(port); executor.setAccessToken(accessToken); return executor; } }

写一个机器人推送任务：

@Component public class RobotXxlJob { private final RobotMessageSender messageSender; public RobotXxlJob(RobotMessageSender messageSender) { this.messageSender = messageSender; } @XxlJob("qqRobotMorningReport") public void morningReport() { XxlJobHelper.log("morning report start"); messageSender.sendText("target_group_id", "早上好，每日早报。"); XxlJobHelper.log("morning report end"); } }

然后在调度中心管理页面新增任务，任务 JobHandler 填qqRobotMorningReport，cron 填0 0 8 * * ?，路由策略选第一个或轮询。

5.4 路由策略怎么选

XXL-Job 的路由策略会直接影响机器人消息是否重复发送。最安全的设置是“第一个”，意思是每次调度固定选择第一个在线执行器。如果你的任务需要所有节点都执行，才选择“分片广播”。

QQ 机器人推送场景建议使用“第一个”策略。因为发送消息是幂等性较弱的操作，两台机器同时发送会造成用户重复收到消息。

注意：即使选择“故障转移”，也要考虑消息发送失败的语义。如果任务第一次调用机器人接口时超时，但接口实际上已经发送成功，故障转移到另一台机器会再次发送，导致重复。

6. cron 表达式使用与避坑

6.1 常见 cron 写法

cron 表达式是定时任务最基础也最容易写错的部分。Spring Schedule 和 Quartz 都支持 cron，但两者的秒级格式相同，注意不要混用只有分秒级的非标准格式。

注意第七位的年字段默认是可选的，Spring 的 cron 支持 6 位写法，不写年份。

6.2 容易写错的场景

每周一执行看起来简单，但有几种等价写法容易混淆。

Quartz 的星期字段中，1表示周日，2-7表示周一到周六。这与很多开发者的直觉不一致，建议统一使用MON这种英文缩写，降低阅读成本。

另一个高频错误是“每隔一周周一执行”。cron 本身很难表达“每隔一周”，常见做法是在任务里用一个状态字段记录上次执行日期，或者记录执行周期数，判断本次是否为执行周。

public boolean shouldExecute() { LocalDate today = LocalDate.now(); LocalDate lastRun = getLastRunDate(); return lastRun == null || lastRun.plusWeeks(2).isBefore(today); }

6.3 工具校验方法

每次写完 cron，不要直接看效果。先把表达式放到定时任务框架中打印下次触发时间。

以 Quartz 为例：

public static void main(String[] args) { CronExpression expression = new CronExpression("0 0 9 ? * MON"); Date next = expression.getNextValidTimeAfter(new Date()); System.out.println(next); }

Spring 的CronExpression同样可以解析：

import org.springframework.scheduling.support.CronExpression; public void printNextRunTimes(String cron) { CronExpression expression = CronExpression.parse(cron); LocalDateTime now = LocalDateTime.now(); for (int i = 0; i < 5; i++) { LocalDateTime next = expression.next(now); if (next == null) { break; } System.out.println(next); now = next; } }

注意：不要只验证程序能启动，还要验证任务的输入、输出、异常分支和日志是否符合预期。cron 表达式的验证更是如此，必须看到真实的“下次触发时间”，而不是靠人肉推理。

7. 常见问题与排查路径

7.1 任务没执行

现象：应用启动成功，配置的定时任务到时间没有触发。

按以下顺序排查：

1. 启动类是否加了@EnableScheduling（Spring Schedule 场景）。
2. 类是否被 Spring 扫描到，是否加了@Component。
3. cron 表达式是否正确，用工具打印下次执行时间。
4. 服务器时区是否是Asia/Shanghai，执行环境的系统时间是否正常。
5. 日志是否出现调度异常堆栈。
6. 如果是 Quartz，检查QRTZ_TRIGGERS表中任务状态是否为PAUSED。
7. 如果是 XXL-Job，检查调度中心日志和执行器是否在线。

表格速查：

7.2 执行了但消息没发出去

现象：日志显示任务已执行，但群里没有收到机器人消息。

排查链路：

1. 查看任务执行日志，确认是否调用了发送接口。
2. 查看 QQ 机器人接口返回状态码，是成功还是限流。
3. 检查 access_token 是否过期或缓存是否失效。
4. 检查目标群 ID 是否正确，机器人是否已在群内。
5. 检查消息内容是否触发平台内容限制。

常见原因是凭证缓存时间与实际有效期不一致。如果凭证有效期是 7200 秒，缓存就按 7000 秒提前刷新，不要把时间卡到毫秒级。

7.3 任务重复执行

现象：同一条消息收到两次。

原因通常有三个：

• 应用部署了多个实例，Spring Schedule 在每个实例上都执行。
• Quartz 集群配置有问题，重复调度。
• XXL-Job 路由策略不当，比如使用分片广播。

排查方式：

# 查看当前机器实例数量 ps -ef | grep java # 查看日志中的执行时间戳是否完全一致 grep "morning report" app.log

解决方案：

• Spring Schedule：保证单实例部署，或引入分布式锁。
• Quartz：检查isClustered=true配置，应用节点使用同一个 scheduler-name。
• XXL-Job：路由策略改为第一个或轮询，不要用分片广播。

7.4 任务执行时间过长

现象：任务本身只需要发送一条消息，但实际执行耗时几十秒，影响后续任务。

如果在 Spring Schedule 默认配置下，所有任务共用一个线程池，一个慢任务会阻塞后面的任务。

调整方案：

spring: task: scheduling: pool: size: 10 quartz: properties: org.quartz.threadPool.threadCount: 5

同时要给发送消息设置超时时间，不要无限等待。

HttpURLConnection connection = (HttpURLConnection) url.openConnection(); connection.setConnectTimeout(3000); connection.setReadTimeout(5000);

7.5 时区问题

现象：任务配置为每天 8 点执行，但实际执行时间不是 8 点。

服务器执行date查看系统时区。如果时区不是Asia/Shanghai，在应用启动参数里显式指定：

java -jar app.jar -Duser.timezone=Asia/Shanghai

或配置：

spring: jackson: time-zone: Asia/Shanghai

Quartz 的 cron 触发基于服务器默认时区，如果有跨时区部署需求，需要在调度时传入时区设置。个人机器人场景大部分不需要。

8. 最佳实践与工程化建议

8.1 任务信息落库

不要把定时任务配置散落在代码注解里。建议在业务表中维护任务元数据：

这样可以通过管理后台维护任务，任务代码只负责执行，不改业务表。

8.2 幂等性设计

定时任务重复执行是不可避免的，必须假设“同一条任务可能会执行不止一次”。机器人消息场景一定要自行处理幂等。

推荐做法：在执行任务前生成一个唯一的业务流水号，写入发送记录表。发送成功后回写状态。如果重复触发，检查该流水号是否已处理。

public void sendWithIdempotent(String targetId, String content) { String messageId = generateMessageId(targetId, content, LocalDate.now()); boolean exists = sendRecordRepository.existsByMessageId(messageId); if (exists) { log.info("duplicate message skip, messageId={}", messageId); return; } messageSender.sendText(targetId, content); sendRecordRepository.save(new SendRecord(messageId, targetId, content)); }

8.3 日志和监控

定时任务必须有独立的日志标记。建议每个任务开头打印：

任务名 触发时间 业务参数 执行结果 耗时

日志格式示例：

log.info("[robot-push] job={}, targetId={}, startTime={}", jobName, targetId, LocalDateTime.now()); log.info("[robot-push] job={}, result=success, cost={}ms", jobName, cost);

有了日志还不够，要配置告警。简单方案是任务失败时调用独立的告警接口发送消息到管理员群，或者接入现有的监控平台。

8.4 从单机到分布式的演进路径

给一个清晰的落地建议：

• 个人机器人、任务少于 10 个：用 Spring Schedule。
• 业务量增长、需要动态配置：升级到 Quartz。
• 服务多节点、需要统一调度和运维界面：使用 XXL-Job。

不要一开始就引入 XXL-Job，除非你已经明显遇到单机调度无法解决的问题。框架本身会引入部署成本和运维成本，调度中心的高可用也需要维护。

替代方案也可以考虑 Spring 官方生态中的其他组件，或者在 Spring Schedule 基础上加 Redis 分布式锁。但这类方案对代码侵入较大，需要自己处理锁过期、续期、重入等问题。如果团队没有专门精力维护，直接用成熟的任务调度框架更划算。

QQ 机器人定时任务本质上没有一个完美的“一劳永逸”方案，正确思路是：先确认任务量级和部署模式，再选择对应框架；在代码层面做好分层，让调度层可替换；在业务层面做好幂等和日志，让推送可靠可追踪。把这四件事做扎实，定时推送就不是一个容易出问题的功能。