.NET 10 SSE: Real-Time Updates Without SignalR

原始來源與檔名：NET 10 SSE Real-Time Updates Without SignalR _ Medium.md

簡介

在 .NET 10 之前，要實現伺服器推播（Server Push）功能，開發者幾乎都會直覺地選擇 SignalR。但對於「僅需單向更新」的場景（如通知、即時 Log），SignalR 顯得太過笨重。本文介紹 .NET 10 原生支援的 Server-Sent Events (SSE)，讓你用最輕量的方式實現即時功能。

本段落總結： 這是「殺雞焉用牛刀」的完美例證。SignalR 雖然強大（支援雙向、自動降級），但在 90% 的簡單看板或通知場景中，標準的 HTTP SSE 才是更優雅、更省資源的選擇。

3. .NET 10 的原生支援

以前寫 SSE 需要手動設置 Header 和 Flush Response。 現在，ASP.NET Core 10 提供了 TypedResults.ServerSentEvents。 你可以直接回傳一個 IAsyncEnumerable<T>，框架會自動處理連線保持、序列化和格式化。

本段落總結： 微軟將 SSE 提升為與 JSON 一樣的一等公民。這意味著你可以像寫普通的 Async API 一樣寫即時串流 API，開發體驗極佳。

5. 客戶端實作 (EventSource)

無需任何第三方庫。瀏覽器原生的 EventSource API 即可處理連線、接收訊息，甚至支援自動重連。

const source = new EventSource("/events");
source.addEventListener("heartbeat", (e) => console.log(e.data));

本段落總結： 這就是 Web 標準的力量。不依賴 SignalR Client SDK 意味著你的前端更加輕量，且與技術棧無關（React, Vue, Vanilla JS 都能用）。

6. 生產環境注意事項 (Production Concerns)

雖然代碼簡單，但上線要注意：

1. Keep-Alives：負載均衡器可能會切斷閒置連線，記得發送定期心跳。
2. Cancellation：務必傳遞 CancellationToken，否則客戶端斷線後伺服器還在空轉。
3. Backpressure：SSE 仍是 HTTP 連線。對於大量用戶廣播，你需要自己處理 Fan-out（例如搭配 Redis Pub/Sub）。

7. SSE vs SignalR：該選誰？

• 需要雙向通訊 (聊天室、遊戲) -> SignalR
• 需要支援古老瀏覽器 (IE) -> SignalR
• 只需伺服器推播 (儀表板、通知) -> SSE

本段落總結： 不要因為習慣而預設使用 SignalR。如果是單向資料流，SSE 是更現代、更標準且更輕量的選擇。

全文總結

.NET 10 讓 SSE 變得觸手可及。 下次當你需要寫一個「即時股票價格」或「系統狀態監控」功能時，試試 TypedResults.ServerSentEvents。你會驚訝於它的代碼是如此簡潔，而效果是如此即時。