大数据存入Redux是否可行？多Notepad组件场景技术问询

嘿，这个问题挺典型的，咱们一步步拆解来看：

首先明确：把N个GB级的Notepad数据全存在Redux里绝对不合理。

Redux的核心是把应用状态存在内存中的JavaScript对象里——内存是有限的！浏览器单标签页的内存配额虽然因设备和浏览器而异，但几个GB的占用很容易触发内存溢出、页面卡顿甚至直接崩溃。而且Redux的状态是临时的，用户刷新页面后所有数据都会丢失，你之前存的N*1GB数据等于白占了内存，完全没起到持久化的作用。

不用非走极端——“全存Redux”和“每次都调API”之间有更优的折中方案：

• 仅缓存当前活跃的Notepad数据：当用户切换到某个Notepad时，再调用API加载对应数据到Redux；当用户切换离开这个Notepad时，立即从Redux中清除它的数据。这样Redux里永远只保留1份GB级数据，内存压力就小多了。
• 用IndexedDB做本地持久化缓存：这是处理浏览器端大文件存储的最佳选择，它支持GB级别的数据存储，而且是持久化的（刷新页面也不会丢）。你可以在数据保存成功后，把数据同步存入IndexedDB；下次用户查看时，先从IndexedDB读取，只有当本地没有数据或者数据过期时，再调用API获取。既避免了重复请求，又不会占用过多内存（Redux依然只存当前活跃的数据）。
• 特殊场景下的妥协：如果你的数据更新异常频繁，或者用户网络环境极好且不在乎加载等待，那每次查看调用API也能接受，但体验肯定不如本地缓存好。

Redux本身没有设置任何存储上限——它只是把数据存在JavaScript的内存堆里。真正的限制来自浏览器的单标签页内存配额：

• 桌面浏览器（比如Chrome）的单标签页一般能分配到几GB的内存（具体取决于设备总内存），但一旦占用接近这个上限，浏览器会频繁触发垃圾回收，导致页面卡顿；如果直接超出，浏览器会强制关闭标签页。
• 移动端浏览器的内存配额更小，可能几百MB就会出问题。

所以别指望用Redux存大量大文件，这完全不是它的设计场景。

内容的提问来源于stack exchange，提问作者Mick