之前做过一版，但不是流式返回，是等待全部结果再返回，不得不说确实等待过程挺长，然后就有了现在的优化。想着功能都写好了，只是改一下接口，应该是个简单的需求。
后端使用的post接口，经过一番搜索，最后使用的fetch。经过短短几个小时，配置写好，准备联调，以为需求就顺利完工了。奈何就这流式联调，还耗了两天。只因为后端在postman上测试时正常的，然后前端在本地连调就是无法获取分段式数据，拿到的总是一整块数据。表现成这样，我们就开始纠结前端配置是否有误，网关转发是否有误。
就这样前端也试了好几种方式去发请求，奈何结果都一样。想着先测其他部分，这个接口最后测试。意外的是部署在线上的环境竟然能正常接收流式接口！！！那问题可能就是本地与部署线上的区别了，今天主要记录一下使用的配置。
EventSource
创建EventSource对象：首先，使用new EventSource()构造函数创建一个EventSource对象。该对象将用于与服务器建立连接并接收服务器发送的事件流。
var eventSource = new EventSource('sse_url');在上面的代码中，将'sse_url'替换为实际的SSE请求URL。2. 监听事件：使用EventSource对象的onmessage事件监听器来接收服务器发送的事件数据。当接收到数据时，事件处理函数将被调用，并可以通过事件对象的data属性访问数据。
eventSource.onmessage = function(event) {
console.log('Received data:', event.data);
};错误处理：为了处理可能发生的错误，可以使用EventSource对象的onerror事件监听器。当发生错误时，可以在事件处理函数中进行处理。
eventSource.onerror = function(error) {
console.error('SSE error:', error);
};关闭连接：当不再需要接收事件流时，可以使用EventSource对象的close方法关闭连接。
eventSource.close();完整的示例代码如下所示：
var eventSource = new EventSource('sse_url');
eventSource.onmessage = function(event) {
console.log('Received data:', event.data);
};
eventSource.onerror = function(error) {
console.error('SSE error:', error);
};但是EventSource只支持get请求，配置请求头也不太友好。
fetch
async function getStream() {
try {
let response = await fetch('url');
if (!response.ok) {
throw new Error('Network response was not ok');
}
const reader = response.body.getReader();
const textDecoder = new TextDecoder();
let result = true;
let output = ''
while (result) {
const { done, value } = await reader.read();
if (done) {
console.log('Stream ended');
result = false;
break;
}
const chunkText = textDecoder.decode(value);
output += chunkText;
console.log('Received chunk:', chunkText);
}
} catch (e) {
console.log(e);
}
}插件
@microsoft/fetch-event-source 使用方法我就 不放了，看了一下源码也是基于fetch实现的，网上例子很多，可以看看。
问题
本地运行的环境也是用的代理访问的部署好的环境的接口。插件是 Node.js 的 HTTP 代理中间件http-proxy-middleware。所以为何同样的配置，本地运行不行，而部署到环境上就正常了？有大佬遇到过吗
