Quartz差在哪？
Spring @Scheduled、Elastic-Job、XXL-JOB 与国内多数作业平台默认采用 Quartz 风格六域：从左到右常见为秒、分、时、日、月、周，有时还带可选年位；「日」与「周」互斥时常用问号占位，和 Linux 五域从「分」开始、根本没有问号的肌肉记忆完全两回事。检索「Quartz cron 解析」「Spring 定时任务 表达式」「0 0 12 * * ? 含义」「misfire 补偿」的人，多半在联调「为什么少跑了一次」或「为什么秒级抖动」。把六域逐个展开成人话并列出未来触发，能在评审里当场确认「周字段到底指周日还是周一习惯」；同时提醒错过触发后的补偿策略并不在表达式本身，而在调度器配置里另表。别再把老服务器 crontab 直接粘进 Spring，秒位一错位，全表同步可能在错误的小时窗口扫库。与中间件同事核对线程池、错过触发阈值与集群并发策略后，再把人话与样例触发截屏附在发布单，可显著减少大促当晚电话会轮次。再把「周起始习惯」与「节假日额外暂停」两张小表附在评审末尾，外包同事也不容易按错日历理解周字段。
如何在评审材料里逐项核对 Quartz 六域并与错过触发、并发阈值配置分开写清责任边界
- 确认表达式是否以秒开头并核对是否含年位；若从旧 crontab 迁移，先在表格里列出「旧五域→新六域」对照，显式补零秒或删年位，避免复制粘贴少一列。
- 检查「日」与「周」是否同时写成具体值：若需「每月某日且为周几」这类组合，应改用官方允许的组合写法或拆成两条规则，而不是凭感觉各填一个星号。
- 在预发或沙箱打开调度器日志，对照解析出的未来触发点与业务窗口；若使用集群部署，还要确认是否启用错过触发重跑、是否加了分布式锁，避免人话对了但执行仍打架。
Quartz 常见问题
我把 Linux crontab 五域原样粘进 Spring，任务居然每分钟都在跑，这种典型少域错位该怎么写进新人手册一页纸自查表？
Spring 侧若按 Quartz 解析，最左域是秒；五域串会被当成「从秒开始缺一位」的误读，常见症状是频率整体偏快或解析失败。手册应强制要求「先标注方言再粘贴」，并附一条黄金样例供复制比对。
表达式里同时写了具体「日」和具体「周几」，控制台能保存但触发行为诡异，这种互斥规则在评审纪要里该怎么描述才不让业务误以为是「随机」？
应写明「日与周只能其一为具体值，另一域用问号或星号按引擎规则」并贴官方文档链接；解析工具若给出警告，必须把警告原文粘进变更单。不要用口语「两个都指定」含糊带过。
大促当晚任务大面积错过触发，研发说是 misfire 策略吞了，业务质疑「表达式明明写着整点」，这类争议该用人话与日志哪几列对齐？
人话只解释「计划何时触发」，实际是否补跑取决于线程池、并发上限与 misfire 阈值；应在监控里对齐 scheduler 实例、触发时间与 nextFireTime 字段，并在配置库单独截屏 misfire 策略。纪要里分栏写清「计划」与「补偿」两层语义。
「L」「W」「井号周几」这类扩展在开源 Quartz 与云托管作业平台之间支持度不同，我们怎么在架构评审里写死「禁止用哪几类扩展」以免换平台就全挂？
应维护一份「允许子集」白名单并在静态扫描里校验表达式；评审时把不支持的符号列成表格与厂商 SLA 绑定。迁移前用批量解析工具跑全库，输出不支持清单推动改造，而不是上线后才发现。
多实例部署下同一 Cron 触发两次导致重复扣款，我们怀疑解析没问题而是并发控制缺失，这类事故在人话评审阶段能提前暴露什么信号？
若人话显示触发时刻密集且与业务高峰重叠，应在评审强制问「是否全局唯一执行」并检查是否配置 shedlock 或数据库行锁；人话对齐后仍要在压测环境开双实例空跑验证互斥。别把「只跑一次」当隐含需求。