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

来源：这里教程网时间：2026-02-21 17:40:14 作者：

什么时候该用

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: ...\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
中间件），而
SignalR
Hub 有
[Authorize]
—— 两者权限模型割裂你在
SignalR
中清理用户状态（如
OnDisconnectedAsync
），但
SSE
连接没有对应钩子，导致服务端残留无效监听者 前端同时持两个连接，网络波动时重连节奏不同步，UI 可能收到重复或错序事件

真正需要双向能力时，就全量用