当场景只需服务器单向推送、客户端无需发送消息且运行于现代浏览器时，应优先选用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 压力，尤其在未正确DisposeIDisposable资源时
如果你的客户端全是可控的现代 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: ...\n\n结尾（两个换行符分隔事件），支持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}\"}}\n\n";
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中间件），而SignalRHub 有[Authorize]—— 两者权限模型割裂 - 你在
SignalR中清理用户状态（如OnDisconnectedAsync），但SSE连接没有对应钩子，导致服务端残留无效监听者 - 前端同时持两个连接，网络波动时重连节奏不同步，UI 可能收到重复或错序事件
真正需要双向能力时，就全量用 SignalR；如果只是推送，就彻底放弃 SignalR 客户端 SDK，用原生 EventSource。混搭看似灵活，实则把问题从框架层推给了业务代码去缝合。
