signalr 不提供后台任务进度跟踪能力，需通过 ihubcontext 主动推送；hub 实例生命周期短且非单例，不能存储状态，必须由外部服务（如 backgroundservice）结合 connectionid 绑定 taskid 来精准推送进度。
SignalR 本身不提供后台任务进度跟踪能力，必须靠你自己在任务执行过程中主动计算并推送——IHubContext 是唯一可靠出口，别指望 Hub 实例能“记住”某个长期运行的任务。
为什么不能在 Hub 方法里直接跑长任务并实时 SendAsync
Hub 实例生命周期极短，每次客户端调用都可能新建一个；在 OnConnectedAsync 或普通 Hub 方法里 await Task.Delay(10000) 这类操作，会阻塞连接握手或导致超时断连。更危险的是：若你在 Hub 方法里启动后台线程或 Task.Run，该线程无法安全访问 Clients（因为 Hub 实例可能已被回收）。
- Hub 类不是单例，不能存状态、不能缓存 connectionId 到字段里
- 想推进度，必须从外部服务（如
BackgroundService、控制器、定时器）通过IHubContext<myhub></myhub>推送 - 推送目标要明确：用
Clients.Client(connectionId)或Clients.User(userId)，别用Clients.All泄露他人进度
后台任务如何把进度传给 IHubContext
关键不是“怎么发”，而是“谁来发、怎么关联到用户”。推荐用“任务 ID + connectionId 绑定”的方式：
- 前端上传/触发任务时，先建立 SignalR 连接，拿到
connectionId，再发起 HTTP 请求（如POST /api/start-export），把connectionId放在请求头（如X-Connection-ID）或 body 里 - 后端控制器收到请求后，生成唯一
taskId，存入内存字典或 Redis（taskId → connectionId），然后启动后台任务（如Task.Run或注入IHostedService） - 任务执行中，每完成一个 chunk（比如处理完 100 条记录），就查出对应
connectionId，调hubContext.Clients.Client(connectionId).SendAsync("TaskProgress", new { taskId, percent = 35 }) - 任务结束或失败时，再推一次
"TaskComplete"或"TaskFailed"，前端据此清理 UI 状态
常见错误现象和避坑点
进度卡在 0%、前端收不到任何推送、多个任务互相覆盖进度——基本都出在这几处：
-
connectionId传丢了：检查前端是否真等connection.start()resolved 后才发上传请求；后端是否从 header 正确读取（Request.Headers["X-Connection-ID"]） - 推送时 connectionId 已失效：用户刷新页面或断网后，旧 ID 不再有效；不要静默忽略错误，可加日志：
if (!await hubContext.Clients.Client(id).SendAsync(...)) { _logger.LogWarning("Client {id} offline", id); } - 并发任务写同一个字典没加锁：用
ConcurrentDictionary<string string></string>存taskId → connectionId，别用普通Dictionary - 进度推送太频繁：每毫秒都推一次会压垮客户端；建议按百分比阶梯（每 5% 推一次）或最小间隔（如
TimeSpan.FromMilliseconds(200)）节流 - 没配大请求体限制：导出大数据量时，若任务参数带 JSON 配置，可能触发
MaxRequestBodySize限制，需在Program.cs加：services.Configure<kestrelserveroptions>(o => o.Limits.MaxRequestBodySize = 100_000_000)</kestrelserveroptions>
真正难的不是推送那行代码，而是让每个任务的生命周期、状态归属、连接有效性三者对齐——connectionId 一错，整个链路就断了，而且不会报错，只会静默丢消息。
