c# Server-Sent Events (SSE) 和 SignalR 在实时推送中的选择

当场景只需服务器单向推送、客户端无需发送消息且运行于现代浏览器时，应优先选用SSE；它更轻量，基于http流，无协议开销，适用于仪表盘指标、日志流、通知广播等。

什么时候该用 Server-Sent Events (SSE) 而不是 SignalR

当你的场景只需要「服务器单向推」、客户端不需发消息、且目标环境是现代浏览器（chrome/firefox/edge/safari 17.4+）时，SSE 更轻量。它基于 HTTP 流，无额外协议开销，服务端只需返回 text/event-stream 响应头 + 持续写入 data: 行，无需维护连接状态或心跳逻辑。

常见适用场景：

• 仪表盘实时指标（如 CPU 使用率、订单计数）
• 日志流式输出（CI/CD 构建日志、审计日志）
• 通知广播（系统公告、配置变更提醒）

注意：SSE 不支持 IE，无法穿透某些企业代理（会缓冲 chunked 响应），且连接超时后浏览器自动重连，但重连间隔由浏览器控制（通常几秒），你无法干预重试策略。

SignalR 的真实开销和连接行为

SignalR 不是单一协议，而是一套自适应传输层：默认优先尝试 websockets，失败则降级为 Server-Sent Events 或长轮询（Long Polling）。这意味着它在老旧环境里能“兜底”，但也带来隐性成本：

• 每次连接建立前会发多个预检请求（/negotiate → /connect），首屏延迟明显高于纯 SSE
• 若强制指定传输方式（如 transport: HttpTransportType.WebSockets），降级逻辑失效，IE 或禁用 WebSocket 的网络下直接失败
• Hub 类实例生命周期绑定连接，高频连接断开/重连可能触发 GC 压力，尤其在未正确 Dispose IDisposable 资源时

如果你的客户端全是可控的现代 Web 应用，又不需要双向通信，SignalR 的“智能降级”反而成了累赘。

如何在 ASP.NET Core 中安全暴露 SSE 端点

别用 HttpResponse.Body.WriteAsync 手动写流——容易阻塞线程、忽略客户端断连、导致内存泄漏。正确做法是使用 IHttpResponseBodyFeature 或更推荐：返回 Task 并持续 await response.BodyWriter.WriteAsync，配合 HttpContext.RequestAborted 监听取消。

关键点：

• 必须设置 Response.ContentType = "text/event-stream" 和 Response.Headers["Cache-Control"] = "no-cache"
• 每条消息以 data: ...nn 结尾（两个换行符分隔事件），支持 id:、event:、retry: 字段
• 避免在循环中直接 Thread.Sleep，改用 await Task.Delay(ms, HttpContext.RequestAborted)

app.MapGet("/events", async context => {     context.Response.ContentType = "text/event-stream";     context.Response.Headers["Cache-Control"] = "no-cache";     context.Response.Headers["Connection"] = "keep-alive";      var writer = context.Response.BodyWriter;     var buffer = new byte[256];      while (!context.RequestAborted.IsCancellationRequested)     {         var msg = $"data: {{"time":"{DateTime.UtcNow:O}"}}nn";         var span = System.Text.Encoding.UTF8.GetBytes(msg);         await writer.WriteAsync(span, context.RequestAborted);         await writer.FlushAsync(context.RequestAborted);          await Task.Delay(1000, context.RequestAborted);     } });

为什么混合使用 SSE 和 SignalR 反而更危险

有人想“用 SSE 推数据，用 SignalR 做认证或心跳”，这会引入竞态和状态不一致。例如：

• SSE 连接未校验用户权限（因它绕过 Authorize 中间件），而 SignalR Hub 有 [Authorize] —— 两者权限模型割裂
• 你在 SignalR 中清理用户状态（如 OnDisconnectedAsync），但 SSE 连接没有对应钩子，导致服务端残留无效监听者
• 前端同时持两个连接，网络波动时重连节奏不同步，ui 可能收到重复或错序事件

真正需要双向能力时，就全量用 SignalR；如果只是推送，就彻底放弃 SignalR 客户端 SDK，用原生 EventSource。混搭看似灵活，实则把问题从框架层推给了业务代码去缝合。