signalr并非实时银弹，其性能取决于推送频率、数据量、服务端负载与客户端处理能力；hub实例每次调用新建，不可存状态，需用分布式缓存或并发字典；避免onconnectedasync耗时操作；大数据分块推送并加延迟；js端需防重、保序、节流更新；生产环境需配置反向代理支持websocket，并启用自动重连。
SignalR 不是“实时”的银弹，它只是帮你把 WebSocket、Server-Sent Events、长轮询这些底层机制封装得更省心；真正决定“实时性”的，是你推送的频率、数据量、服务端负载和客户端处理能力。
SignalR Hub 怎么写才不会丢消息或卡死
Hub 类不是普通类，它的生命周期由 SignalR 管理，每次客户端调用都会新建实例——所以不能在 Hub 里存状态（比如 private List<string> _cache</string>），否则数据不共享、也不持久。
- 需要共享状态？用
IDistributedCache或静态ConcurrentDictionary，但要注意并发写入和过期清理 - 避免在
OnConnectedAsync里做耗时操作（如查数据库），会阻塞连接建立；改用后台任务或延迟加载 - 推送大量数据时，别直接
Clients.All.SendAsync("UpdateData", bigList)，容易触发InvalidOperationException: The connection is closed；先分块（比如每 50 条一批），加await Task.Delay(1)防爆
客户端 JavaScript 怎么接住 SignalR 推送并更新仪表板
前端不是“收到就渲染”，得考虑重连、重复消息、数据乱序。SignalR JS 客户端默认不保证顺序，也不去重。
- 服务端推送时带上时间戳或递增序列号（如
new { Timestamp = DateTime.UtcNow, Seq = Interlocked.Increment(ref _seq), Data = ... }） - 客户端用
Map缓存最近 100 条消息 ID，收到重复Seq就跳过 - 用
requestIdleCallback或queueMicrotask延迟 DOM 更新，避免高频推送导致页面卡顿（尤其图表库如 Chart.js） - 别在
connection.on("UpdateData", handler)里直接调chart.update()，先debounce300ms，合并连续推送
为什么本地跑得飞快，上线后延迟飙升甚至断连
开发环境默认走 WebSocket，但生产环境常被反向代理（Nginx、IIS、Azure App Service）拦截或降级，实际走的是长轮询——延迟从毫秒级变成秒级。
- Nginx 配置必须显式开启 WebSocket 支持：
proxy_http_version 1.1+proxy_set_header Upgrade $http_upgrade+proxy_set_header Connection "upgrade" - IIS 要启用 WebSocket 协议（Windows 功能里勾选“WebSocket Protocol”），且应用池 .NET 版本 ≥ 4.7.2
- Azure App Service 默认关闭 WebSocket，需在门户中手动打开“Web Sockets”开关（不是“Always On”）
- 用浏览器开发者工具的 Network → WS 标签，确认连接协议是
websocket而非http，否则就是被降级了
最常被忽略的一点：SignalR 的 HubConnection 在页面刷新或标签页休眠时会自动断开，但你写的重连逻辑如果没监听 onclose 或没设 withAutomaticReconnect()，仪表板就再也不会更新——而用户根本看不出断连，只会觉得“数据不动了”。
