为什么我没有直接用 XXL-JOB，而是自己实现定时任务调度？

这个问题其实很适合面试里被问。

因为只要你项目里自己做了调度平台，面试官大概率都会追一句：为什么不直接用现成的，比如 XXL-JOB？

我觉得这个问题不能硬答成“现成框架不行，所以我要自己造”。那样很容易显得不成熟。更真实也更合理的回答应该是：成熟框架当然有价值，但我当时的目标、场景和想验证的能力，不完全等同于直接接入一个通用调度平台。

先说结论：不是为了造轮子而造轮子

我没有直接用 XXL-JOB，不是因为我觉得它不好，也不是因为我想故意把项目做复杂。

更准确地说，是因为我当时想做的不是“接入一个可用调度能力”，而是自己把定时任务平台里几个关键问题走一遍，包括：

• 任务生命周期怎么设计。
• 调度与执行怎么解耦。
• 延迟任务怎么高效推进。
• 幂等、重试、故障恢复怎么考虑。

如果直接接现成框架，这个项目确实能更快落地，但我能真正深挖和表达的部分会少很多。

XXL-JOB 解决的是通用调度问题

这个要承认。

像 XXL-JOB 这种成熟方案，优点很明显：

• 已经有完整的调度中心和执行器模型。
• 运维、监控、失败重试这些能力相对齐全。
• 对很多中后台业务来说，接进去就能用，性价比很高。

如果我是去做公司里的业务系统，需求就是把一批任务稳定跑起来，而且团队本身也已经有成熟调度基础设施，那我大概率不会自己从头做。

因为工程上最重要的不是“什么都自己写”，而是用最合适的方式解决问题。

那我为什么还要自己做

原因主要有三点。

1. 我的场景更偏“项目复盘和能力建设”

说白了，这个项目本身就承担了一部分学习和表达的目的。

我希望它不是一个“我会接框架”的项目，而是一个“我对调度系统关键问题有自己的设计和取舍”的项目。对于校招或实习面试来说，后者能展开的内容明显更多。

2. 我想控制系统边界

现成框架解决的是通用问题，但项目里有时候你更想自己定义边界。

比如我更关心的是：

• 如何把近实时调度和业务状态校验拆开。
• 如何把平台能力控制在通用层，不让业务逻辑反向污染平台。
• 如何围绕延迟任务和恢复策略做更贴近自己项目语境的设计。

这些东西不是 XXL-JOB 做不到，而是用了它之后，我在项目表达上会更多停留在“使用者视角”，而不是“设计者视角”。

3. 我想真正理解调度系统为什么难

这个是最实际的。

很多时候你看文章、看源码、听别人讲，感觉自己懂了。但只有真正自己做过，才会发现很多问题不是“知道有这个概念”就够了。

比如：

• 为什么扫描策略会影响数据库压力。
• 为什么重复投递和幂等是绑在一起讨论的。
• 为什么故障恢复比正常调度更难。

这些东西自己踩过一遍，后面无论是继续造轮子，还是回头用成熟框架，理解都会深很多。

自己实现的代价，我也承认

这件事肯定不是只有好处。

自己做调度平台，天然会面对几个问题：

• 功能覆盖面不如成熟框架。
• 边界 case 很多，容易漏。
• 运维成本和稳定性验证难度更高。

所以如果把它放到真实生产里，我不会轻易说“自己写一定更好”。很多时候成熟方案就是更合理的选择。

我觉得更成熟的态度不是一味崇拜自研，也不是一味迷信框架，而是你要知道：自己做到底换来了什么，同时又承担了什么。

如果面试里要一句话说清楚

我会这么回答：

“我没有直接用 XXL-JOB，不是因为现成框架不好，而是因为这个项目更希望自己把调度系统里的核心问题走一遍，包括任务生命周期、调度执行解耦、延迟队列推进、幂等和故障恢复。这样做成本更高，但能让我真正理解系统设计里的关键取舍，也更适合作为一个可深挖的项目来讲。”

我觉得这样的回答会比“因为我想锻炼自己”更有说服力一点。