quartz.net不能直接new stdschedulerfactory().getscheduler()就用，因为getscheduler()返回未启动的调度器实例，必须显式await scheduler.start()，否则触发器处于standby状态、作业永不执行。
Quartz.NET 为什么不能直接 new StdSchedulerFactory().GetScheduler() 就用？
因为 GetScheduler() 返回的是未启动的调度器实例，调用后必须显式 await scheduler.Start()，否则所有触发器（ITrigger）注册成功但完全不执行。常见现象是日志里显示 “Added job”、“Added trigger”，但作业函数从不被调用。
实操建议：
- 务必在
await scheduler.Start()后再添加作业和触发器，或至少确保它在Scheduler.ScheduleJob()之前完成 - 若使用依赖注入（如 ASP.NET Core），推荐用
ISchedulerFactory.GetSchedulerAsync()+await scheduler.StartAwait()，避免同步阻塞 - 检查日志级别是否为
INFO或更低——Quartz 默认不输出触发细节，需配置log4net或Microsoft.Extensions.Logging并启用Quartz.Simpl.RAMJobStore相关命名空间
如何让 IJob 实现类访问 DI 容器里的服务（比如 ILogger、DbContext）？
Quartz 默认使用无参构造创建 IJob 实例，直接注入会报错：“No parameterless constructor defined”。根本原因是 Quartz 的作业生命周期不由 DI 管理，必须桥接。
实操建议：
- 不要在
IJob类上直接加构造函数注入；改用JobFactory派生类，重写NewJob()方法，从IServiceProvider解析实例 - ASP.NET Core 下更推荐用
Microsoft.Extensions.DependencyInjection提供的QuartzHostedService+AddQuartz()扩展：它自动注册MicrosoftDependencyInjectionJobFactory，并在JobDataMap中透传IServiceScope - 若手动管理，注意
JobDataMap中存入的 service scope 必须在Execute()结束时Dispose()，否则引发内存泄漏
SimpleTrigger 和 CronTrigger 选哪个？关键看时间表达是否含“非固定周期”逻辑
SimpleTrigger 只支持“每 N 秒/分/小时执行一次”或“执行 N 次后停止”，而 CronTrigger 支持复杂日程（如“每月最后一个周五上午9点”、“每周一至五早8点”）。一旦需求出现“第几个星期几”“月中的某天范围”“年份限定”，SimpleTrigger 就无能为力。
实操建议：
- 用
CronTrigger时，务必确认 cron 表达式格式与 Quartz 版本匹配：v3.x 使用“秒 分 时 日 月 周 年”7段（年可省略），不是 Linux crontab 的5段 - 测试 cron 表达式别靠猜——用在线工具（如 quartz-scheduler.org 的
CronExpressionGenerator）验证下一次触发时间 - 避免在生产环境用
0/30 * * * * ?这类高频触发（每30秒），若作业执行耗时超过30秒，可能并发堆积；应加DisallowConcurrentExecution特性或改用WithMisfireHandlingInstructionIgnoreMisfires()
为什么部署到 Windows Server 后定时任务突然不执行？
最常见原因是：IIS 应用池默认“空闲超时”设为20分钟，应用被回收后，Quartz 的内存型调度器（RAMJobStore）彻底丢失所有作业状态，且不会自动恢复。
实操建议：
- 开发阶段可用
RAMJobStore，但生产必须切到AdoJobStore（配合 SQL Server / PostgreSQL），并开启quartz.jobStore.useProperties = true避免二进制序列化兼容问题 - 若坚持用 IIS，需禁用应用池“空闲超时”、启用“定期回收”并勾选“发生回收时生成事件日志”，同时配置 Windows 任务计划程序定期访问站点 URL 保活（仅临时方案）
- 更稳妥的做法是脱离 IIS，改用
Worker Service（.NET 6+）或Topshelf（.NET Framework）托管 Quartz，进程常驻，不受 Web 容器生命周期影响
Quartz 的作业恢复、集群协调、持久化失败重试这些能力，全依赖 JobStore 层实现。跳过这步直接跑内存调度器，等于把定时任务当 Console.ReadLine() 用——本地能跑，上线就静音。
