翻这套工业数据 WebApi 时，有几件事是半夜自己干的：每天同步一次数据、每小时跑个统计、每周清一次临时文件。我早年用系统自带的计时器，散在代码各处，有回排查"为什么半夜有笔操作"，翻了半天才找到一个藏在某类里的定时器。
定时任务最怕"藏起来"。这套平台把它做成贴标签就上岗。
（等价改写，名字换掉了）
// 给方法贴标签，就说清"隔多久跑、几点段跑、优先级"
[Scheduled(Interval = 30, AllowedHour = "0-8", Priority = Normal)]
void 每日统计() { /* 业务只管写"干什么" */ }
我在代码里数到，这套调度在 Quartz 之上封装了 124 处——全仓的定时任务都走这层薄薄的封装，业务方只面对"贴标签"这件事。标签上写清：隔几秒跑一次、哪天跑、一天里哪个时段允许跑、优先级多高。引擎读标签，自动排进自己的时间表。改这段代码的人，一眼看见"这个方法每天半夜跑"，自然就会多想一步：它跑的时候依赖的数据在不在、它失败了谁知道。意图写在代码身上，比写在文档或脑子里牢靠。
我接手这段代码时，看方法头上的标签就知道它的脾气：每 30 秒一次、只在凌晨 0 到 8 点跑、优先级普通。不用去翻调度配置。我早年那套散装的计时器，恰恰相反——任务藏在类深处，半年后连我自己都忘了它还在跑。声明式的好处，是先让"什么时候跑"自己喊出来。
我后来才看清，这跟 es06 那套"贴标签就上岗"是一脉相承的：把意图写在代码自己身上。调度引擎很复杂，但用一层封装把它藏起来，维护的人少掉很多头发。我现在的习惯就是，评审调度任务先看标签在不在方法上。