hangfire 任务不持久、dashboard 打不开、cron 不触发，根本原因是 program.cs 中漏了三件事：未注册持久化存储、未调用 addhangfireserver() 启用后台服务、未正确挂载 usehangfiredashboard() 中间件。
Hangfire 任务不持久、Dashboard 打不开、Cron 不触发——基本都是 Program.cs 里漏了三件事：注册存储、启用 Server、挂载 Dashboard 中间件。
为什么 Hangfire 启动后任务状态丢失或根本不执行
最常见原因是没配持久化存储，或没调用 AddHangfireServer()。Hangfire 默认不启动任何后台工作线程，它靠 HangfireServer 实例轮询数据库取任务；没这一步，所有 BackgroundJob.Enqueue 或 Schedule 都只会卡在 Enqueued 状态，永远不跑。
-
AddHangfire()必须传入具体存储配置，比如UseSqlServerStorage("...")；只写AddHangfire()不带参数会抛InvalidOperationException: No storage registered -
UseMemoryStorage()仅限开发调试，且必须写成UseMemoryStorage()（不带参数），写成UseMemoryStorage("xxx")会编译失败 - SQL Server 存储需确保连接字符串真实可连，否则应用启动时就崩，错误日志里常含
Failed to create schema - 首次运行时若数据库用户无建表权限，Hangfire 会静默失败——检查
HangFireschema 下是否生成了Job、JobQueue、State等表
Dashboard 404 或提示 “No service for type IBackgroundJobClient”
这两个现象本质是同一类配置断裂：IBackgroundJobClient 依赖未注册，或中间件挂载位置错误。
-
UseHangfireDashboard()必须放在app.UseEndpoints(...)之前，否则路由注册失败，访问/hangfire直接 404 - 必须在
builder.Services.AddHangfire(...)之后、app.Build()之前调用builder.Services.AddHangfireServer()，否则IBackgroundJobClient解析失败 - Dashboard 默认开放给本地请求，生产环境如需远程访问，得自定义
DashboardOptions.Authorization，但别直接删掉授权过滤器 - 路径可自定义，比如
app.UseHangfireDashboard("/jobs", new DashboardOptions {...})，但对应 URL 就得访问/jobs
Cron 表达式写了却从不触发？时区和并发是隐形杀手
RecurringJob.AddOrUpdate 挂了任务，不代表它就会准时跑——Cron 解析、时区、并发控制全得手动对齐。
- Cron 表达式默认按服务器本地时区解析，不是 UTC；Docker 容器里系统时区常为 UTC，你写
"0 0 * * *"（每天 0 点）实际是北京时间早上 8 点执行 - 推荐显式指定时区：
RecurringJob.AddOrUpdate("job", () => Do(), "0 0 * * *", TimeZoneInfo.FindSystemTimeZoneById("China Standard Time")) - 不加
DisableConcurrentExecution过滤器，同一 Cron 任务可能多个实例并发跑，比如清理脚本重复删数据 - 秒级 Cron（如
"*/30 * * * * *"）需确认用了Hangfire.Cronos或 Hangfire ≥ 1.7.28，且UseRecommendedSerializerSettings()已启用
延迟任务用 Schedule 还是 ContinueWith？别混着来
想让任务 10 分钟后执行，别用 ContinueWith 模拟延时——它本质是链式依赖，前序失败整个链就断，且延时不精确。
- 正确做法是
BackgroundJob.Schedule(() => SendEmail(), TimeSpan.FromMinutes(10))，这是独立作业，从“现在”起算绝对延迟 -
ContinueWith只适合真正需要依赖上游结果的场景，比如“订单创建成功后 → 发送短信 → 更新推送状态” - 时间精度受
QueuePollInterval影响，默认 15 秒，所以“精确到秒级延时”不现实；如需 sub-second 级调度，该换 Quartz - 泛型调用如
BackgroundJob.Schedule<imyservice>(x => x.Do(), ...)</imyservice>要求IMyService注册为Scoped或Transient，注册成Singleton可能引发状态污染
最容易被忽略的是：Cron 表达式与时区绑定、AddHangfireServer() 的调用时机、以及内存存储与 SQL 存储在部署阶段的切换动作——这三处出错，Dashboard 看得见，任务却永远不动。
