在Redux中存储函数/组件的实际弊端有哪些？

1. 高频无意义重渲染，引发用户可见卡顿 #

Redux的订阅更新依赖状态的浅比较逻辑。函数、组件属于引用类型，哪怕你只是修改状态里的其他字段，浅比较会判定函数/组件的引用“已变化”，导致所有订阅该状态的组件强制重渲染。

如果这个状态被多个组件依赖，会出现大面积无意义的重渲染，直接拖慢应用响应速度，用户能明显感觉到操作卡顿。更糟的是，若你在组件内部动态创建函数（比如const handleClick = () => {}）再存入Redux，每次组件重渲染都会生成新的函数引用，触发Redux状态频繁更新，形成重渲染的恶性循环。

2. 彻底破坏Redux的可调试性与状态可预测性 #

Redux的核心价值之一是状态变化可追踪、可回溯，但函数/组件是不可序列化的：

• Redux DevTools无法正确显示状态内容，也没法记录状态变化历史，调试难度直接拉满；
• 若你需要持久化状态（比如存到localStorage），函数/组件会被转成[object Object]或undefined，完全无法恢复，直接导致状态异常。

3. 内存泄漏与随机崩溃风险 #

组件实例绑定了大量上下文（DOM节点、hooks状态、refs等），存入Redux后，即使组件已经卸载，Redux里的实例仍会持有这些引用，导致内存无法被GC回收，长期运行会引发内存泄漏，严重时直接导致应用崩溃。

另外，函数若捕获了外部作用域的变量，存入Redux后会形成闭包陷阱，变量引用无法释放，同样会加剧内存问题。这类问题往往不会立刻爆发，而是在应用运行一段时间后随机出现，排查难度极高。

4. 状态更新的意外副作用 #

从Redux中取出函数执行时，函数的依赖上下文可能已经失效：比如原本依赖的组件已卸载、外部变量已更新，这时候执行函数会直接抛出错误，导致应用崩溃。

而且，其他组件可能意外修改Redux中函数/组件的引用，导致原本依赖该逻辑的代码出现不可预期的行为，大幅提升代码维护成本。

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