Hangfire 里怎么安全地处理文件上传后的后台任务
文件操作不能直接塞进 Hangfire 的
BackgroundJob.Enqueue，因为序列化会失败，路径在 worker 进程里也大概率不存在。必须把「文件内容」或「可复现的标识」传进去，而不是
FileStream或
FileInfo实例。 上传后立刻把文件存到共享存储（如本地固定目录、
\servershare、或 Azure Blob），只把路径字符串或 blob URL 传给任务 任务函数里用
File.ReadAllBytes或
HttpClient.GetAsync拉取内容，别依赖原始请求上下文 加
[DisableConcurrentExecution]特性防多个任务同时改同一个文件，尤其涉及
File.Move或覆盖写入时 注意 Hangfire 默认使用 SQL Server 存储作业，如果文件路径含特殊字符（比如
&、
%），要 URL 编码再存，否则反序列化可能出错
Quartz.NET 调度文件扫描任务：触发器选 CronTrigger 还是 SimpleTrigger
扫描目录看有没有新文件，本质是轮询，不是精确时间点执行——用
CronTrigger更合适，但得避开常见陷阱。
CronTrigger表达式别写成
"0/5 * * * * ?"（每 5 秒），Windows 文件系统缓存可能导致刚写完的文件扫不到；建议最低间隔设为 30 秒以上 扫描逻辑里必须用
Directory.EnumerateFiles(path, "*.*", SearchOption.TopDirectoryOnly)，别用
GetFiles，大目录下容易 OOM 记录上一次扫描的
DateTime到数据库或文件（比如
last_scan_time.txt），下次只查
CreationTime > lastScan的文件，避免重复处理 Quartz 默认不支持异步 Job，若文件处理要 await（如上传到云存储），得继承
IJob并手动调用
Task.Run，否则线程会被占死
两个框架共有的坑：文件锁、权限、路径硬编码
不管用 Hangfire 还是 Quartz.NET，只要碰文件 I/O，这三类问题必现。
任务里用File.OpenRead打开文件时没加
FileShare.Read，而上传服务还在写，直接抛
IOException: The process cannot access the fileHangfire worker 或 Quartz 的
QuartzSchedulerThread运行在 Windows 服务账户下，默认没权限访问用户目录（如
C:UsersAliceDownloads），路径必须指向
C:AppDataJobs这类服务可读位置 本地开发用
"./uploads"，部署到 Linux 容器就挂了——统一用
Path.Combine(AppContext.BaseDirectory, "uploads")，别拼字符串 别在任务里直接
File.Delete原始上传文件，先
File.Move到归档目录，等确认处理成功后再删，留个回滚余地
要不要自己手写队列？什么情况下 Hangfire/Quartz 反而是累赘
如果只是“用户上传 → 转码 → 返回结果”，且并发不高（Task.Run +
ConcurrentQueue更轻量，还少一层序列化和存储依赖。 Hangfire 需要 Redis 或 SQL Server，Quartz.NET 要配 ADO.NET 数据源，小项目纯属增加部署复杂度 文件处理耗时稳定（比如都 ThreadPool 就够用 但一旦要“失败后 1 小时重试”“按优先级排序”“看历史 30 天处理记录”，就得切回 Hangfire——它的
RetryAttribute和 Dashboard 是真省心 Quartz.NET 的优势只在需要 Cron 精确控制（比如每天凌晨 2:17 扫描日志目录），其他场景基本被 Hangfire 吊打
路径、权限、锁、序列化——这四个点卡住，90% 的文件后台任务就跑不起来。调通之前先确保 worker 进程能
File.Exists到那个路径，别的都是后话。
