这是因为阈值不能很容易地提前定义。我会说它的时候：

• 你的应用程序的性能开始崩溃，因为你有这么多的状态。
• 你的应用程序的状态管理逻辑变得不可维护和可怕的地步，* 你 * 是足够的恼火，以改变它。
• 你碰巧提前知道你有真正复杂的状态。

过早优化是一个非常常见的陷阱。如果你的状态很简单，而且不是很大，那么从一开始就使用redux会产生完全相反的效果--不必要的复杂性。
我的建议是，在没有进一步了解应用程序是什么和用例的情况下（如果有，请提供），从背景开始，在问题出现时处理问题，除非你现在真的确定你的应用程序将是巨大而复杂的。
为了添加一个数据点，我在一个相当大的企业应用程序上工作，该应用程序基本上由50多个表单组成（这些表单并不太交错），我们已经通过上下文和特定于本地目的的表单存储（以及像URQL这样的网络缓存层）处理得很好，没有真实的的更改愿望。
作为另一个数据点，我有一个朋友建立了一些加密 Jmeter 板，其中有许多小部件每隔几秒钟都独立更新。这完全是一场噩梦。他把所有的东西都移到了redux，这样他就可以每隔5秒在整个屏幕上将状态更新缓冲到一个更新中，然后问题就消失了。这是一种独特而复杂的情况，你需要考虑它。所以......这取决于情况。
我发现另一种应用程序是非常需要协作的，比如在线实时多人游戏或实时文档编辑。这类应用程序的复杂性非常高。
一个正在运行的线程与这些例子是状态是复杂的和真正的全局性质。
“知道”的经验无法用语言表达或量化。它来自经验。但从简单的背景出发，只有在你有直觉的情况下才能改变它，这是一个公平的起点。
我还要补充一点，redux已经成为“所有状态都在顶部”的同义词。这取决于你的应用程序，可能不是一个好主意。不同子树的状态范围通常是你想要的。如果是更新的 * 复杂性 * 和数据大小的 * 规模 * 太大，也可以通过https://xstate.js.org/这样的解决方案来减少