救助： 前端根据 api 请求后端返回数据，并把数据导出成 csv。现在的问题在后端返回的数据很多，会导致传输时间久，并且有可能会导致浏览器崩溃，实践中有没有什么好的办法去实现这种大数量的导出

参考 #15 楼，后端什么都不用干，响应头都不用动，前端把接口的调用改成浏览器自己去下载处理就目测 ok 了。

最简单的办法： 把原有的 api 地址 直接粗暴的扔给 a[download] 标签手动 click 一下去触发浏览器去下载这个 url 的数据

肯定后端生成文件啊
数据量大一点，前端就会卡住，很不友好
后端可以异步生成文件，生成后通知前端去下载就可以了

webworker 或者 wasm 也可以考虑下

起一个 worker 来处理这个

kpi 怎么能让， 起个 worker 多线程来搞哇，除非内存泄露，请求超时可以让后端分批给数据

后端上 worker 导出 csv，成功后前端获取下载的 url 。点击下载。

生成文件同步到 CND 或云盘，然后下载就可以了。

流式处理。前端现在是可以实现的。

返回文件流+1

然后 header 是 attachment

生成临时文件（用 Redis 之类的，或者缓存工具，定时删除），数据源就稳定了。直接 Expose 这个文件给 Client 就可以了。

我的想法是 前端肯定有些参数列表，调 api 请求数据 getData 呢，后端可以先返回一个 queryId 。 大约 10s 后，前端带着 queryId 调用 api 再问询下， 后端服务器如果处理好了后，还可以把 queryId 的内容缓存下来呢。

另外写文件到 FTP 目录，客户端用 FTP 协议获取。

银行支付行业，对账很多用 FTP 协议，定时处理。

后端导出文件并上传 oss，前端轮询结果，或者刷列表(需要实现一个导出文件管理功能)。

一般是两个方案
1. 文件流：后端给前端传文件流，前端只要把流存成文件就可以了
2. 异步文件： 后端异步生成文件，直接给前端一个最终文件的下载地址

文件流下载学到了

后端异步生成, 存到 OSS.

前端轮询状态, 完成后 出现下载按钮.