我理解 React Lifting-state-up “ https://reactjs.org/docs/lifting-state-up.html ”。通过这种方法，开发人员需要将父级中的状态函数作为props传递给子级。之后我做了几个关于 redux 的会议。但是，在简单的比较中，我无法理解提升状态与 Redux、通量状态管理的主要区别。
这是否意味着在大型 Web 应用程序中不应使用“提升状态”并且 redux/flux 变得不可避免
绝对不是，您需要使用 redux/flux，只有当您的应用程序正在使用的数据在大量没有共享足够接近的父级的组件之间共享并且数据不断变化并且视图需要时神清气爽。
如果数据在您的应用程序的一小部分共享，您也可以考虑Context-API用于此目的。
Redux 简化了状态管理的整个过程，但是除了抽象化和简化之外还有什么优势吗？
是的，redux 提供了广泛的优势
将状态持久化到本地存储，然后从它启动，开箱即用。
在服务器上预填充状态，将它以 HTML 格式发送到客户端，然后从它启动，开箱即用。
序列化用户操作并将它们与状态快照一起附加到自动错误报告中，以便产品开发人员可以重放它们以重现错误。
通过网络传递动作对象以实现协作环境，而无需对代码的编写方式进行重大更改。
通过使用 Redux，与“提升状态”相比，我们将拥有单一的事实来源，我们需要在多个组件中保持状态，从而增加整体代码的复杂性。在提升状态中，您可以拥有单一的事实来源，该方法的唯一缺点是您的父组件会被许多状态杂乱无章。
正如我之前所说，如果数据在没有非常直接的共同祖先的组件之间共享，您可能更喜欢 Redux。Redux 还提供了一个优势，它将连接实现为 a PureComponent，因此状态更新仅影响正在使用它们的组件，而不会导致其他不使用这些特定状态作为props的组件的重新渲染。
随着 Lifting state up，您需要通过每个组件一直向下传递值，然后您需要确保中间组件是 Pure。
redux 和提升状态之间是否存在性能角度
当您向下传递状态并且不使用 PureComponents 时，性能问题就会出现，从而导致不必要的重新渲染。Redux 在这里很有帮助
Redux 只是一个抽象，它没有提供任何你自己无法实现的性能优化。
但是，要实现 Redux 提供的开箱即用的性能优化，您需要做很多工作，例如shouldComponentUpdate为几乎每个组件实现。
例如，如果某些组件需要共享一个公共状态，则必须将该状态提升到组件之间的公共父级。父组件和那些不使用共享状态的组件之间的所有其他组件都需要忽略与该状态相关的 prop 更改shouldComponentUpdate。
每个组件还需要实现shouldComponentUpdate/PureComponent来检查它的 props 是否改变，否则所有子组件将在父组件重新渲染时自动重新渲染。
Redux 还提供了其他一些便利功能：
localStorage通过redux-persist直接持久化状态这里已经有一些很好的答案。我会采取更务实的方法：
Redux 为您的所有状态提供了单一的事实来源，尽管在您拆分减速器时它可能会变得不同。
组件状态意味着应用程序状态自然更加不同，但是正如您提到的那样，部分将通过提升状态来集中。
您在项目中管理状态的方式将随着时间的推移而发展。您管理状态的方式也应该以您正在编写的应用程序为指导。
另请注意，Redux 和提升状态根本不是相互排斥的技术 - 您可以适当地使用两者。
对于新项目，我会权衡将所有状态集中在一个位置（单一事实来源）的便利性与必须编写操作和连接组件的不便开销。
如果有疑问，我建议从组件状态开始，将它提升一两层，除此之外我会将它提升到一个 redux 存储并直接连接我的组件。这以务实的方式让您了解这两种方法的好处。
集中式 redux 存储的工具和单例性质意味着免费获得各种功能（持久性、时间旅行、redux devtools 等）。另一方面，我可能会在早期浪费大量时间使用 redux 连接应用程序，并且更容易忽略我坐下来编写的内容。
因此，在我看来，您必须首先尝试在没有 Redux 的情况下开发一个 React 应用程序（中等复杂性）。使用“提升状态”的概念。在开发过程中的某个时刻，您会直觉地意识到拥有像 Redux 这样的状态管理库会让生活变得更轻松。有时，通过艰苦的方式学习它会更好。在绝对必要时迁移到 Redux 会让你更加欣赏它。