随着DeepSeek的爆火，作为一名前端开发，我闲暇时间就在思考一件事：如果让我来做一个类似DeepSeek的功能，从前端的角度考虑，我能实现哪些核心功能？
首先是通信问题，看到这种类似聊天框的方案，我首先想到的是通过WebSocket建立长连接，但是慢慢的探索发现，原来从产品类型/产品功能上考虑，WebSocket
1. 客户端与服务器通信
当打开网页端DeepSeek时，我们输入的问题会通过 HTTPS（加密的 HTTP） 发送到 DeepSeek 的服务器。
服务器处理请求后，生成的回复同样通过 HTTPS 返回，确保数据在传输过程中不会被窃取或篡改。
但是从页面的角度，我们输入问题到结果持续流式输出，看似像即时通讯WebSocket，而非单向的http请求；然后经过下图F12检查请求可以看出，我们发送一次提问，并不是建立长链接，而是通过event-stream进行单项流式输出
所以可以看出，DeepSeek网页端主要采用 请求-响应模式（短连接），即每次交互都是独立的 HTTP 请求，而非 WebSocket 长连接。但在流式输出（逐字显示回答）时，会采用Event Stream (SSE)技术，实现实时数据传输。
我们通过如下的对比图，也可以看出和长链接方案对比，Event Stream (SSE)的优缺点：
我们要考虑到，技术本身是服务产品的，所以在确保实现产品功能的情况下，我们应该尽可能减少开销；虽然长连接的形式也可以实现相关功能，但是综合考虑开销成本，很明显单向HTTP请求更合适这种输入请求和流式输出的方案
扩展：
前端 HTTP 请求流式响应的方案扩展说明
一、Fetch API + ReadableStream（现代浏览器方案）
适用场景：处理任意格式的流式数据（JSON、文本、二进制等），需要精细控制数据处理过程;比如dify.ai使用该方式进行交互
核心优势：
原生浏览器支持，无需额外依赖
可处理各种内容类型（不限于文本）
支持双向流式传输（请求和响应均可流式处理）
二、EventSource（Server-Sent Events，SSE）
适用场景：单向服务器推送场景（如实时通知、日志流、实时统计）；上述说的deepSeek处理方案
核心优势：
专门为服务器推送设计，API 简单易用
内置断线重连机制
自动处理消息边界（基于事件类型）
