告别难以理解的 Class；
解决业务逻辑难以拆分的问题；
使状态逻辑复用变得简单可行；
函数组件从设计思想上来看，更加契合 React 的理念。
1. 告别难以理解的 Class：把握 Class 的两大“痛点”: this 和生命周期
this
changeAge 监听函数。点击后，会报错。原因很简单，changeAge 里并不能拿到组件实例的 this
为了解决 this 不符合预期的问题，用 bind、箭头函数。本质上都是在用实践层面的约束来解决设计层面的问题。有了 Hooks，函数组件是不用关心 this
生命周期
---学习成本
---不合理的逻辑规划方式
事情 [异步请求，更新dom，设置订阅等] 之间看上去毫无关联，逻辑就像是被“打散”进生命周期里了一样，一个生命周期不止做一件事情
设置订阅和卸载订阅的逻辑，逻辑强关联，但是却只能被分散到不同的生命周期函数里去处理
2. Hooks 如何实现更好的逻辑拆分
而Hooks可以有管理订阅的函数组件、专门处理 DOM 的函数组件、专门获取数据的函数组件等。Hooks 能够帮助我们实现业务逻辑的聚合，避免复杂的组件和冗余的代码。
3. 状态复用：Hooks 将复杂的问题变简单
过去复用状态逻辑，HOC（高阶组件）和 Render Props 这些组件设计模式(“嵌套地狱”)
自定义 Hook，达到既不破坏组件结构、又能够实现逻辑复用的效果
保持清醒：Hooks 并非万能
Hooks 的局限性
Hooks 暂时还不能完全地为函数组件补齐类组件的能力：比如 getSnapshotBeforeUpdate、componentDidCatch 这些生命周期，目前都还是强依赖类组件的。官方虽然立了“会尽早把它们加进来”的 Flag，但是说真的，这个 Flag 真的立了蛮久了……（扶额）
“轻量”几乎是函数组件的基因，这可能会使它不能够很好地消化“复杂”：我们有时会在类组件中见到一些方法非常繁多的实例，如果用函数组件来解决相同的问题，业务逻辑的拆分和组织会是一个很大的挑战。我个人的感觉是，从头到尾都在“过于复杂”和“过度拆分”之间摇摆不定，哈哈。耦合和内聚的边界，有时候真的很难把握，函数组件给了我们一定程度的自由，却也对开发者的水平提出了更高的要求。
Hooks 在使用层面有着严格的规则约束：牢记并践行 Hooks 的使用原则，如果对 Hooks 的关键原理没有扎实的把握，很容易把自己的 React 项目搞成大型车祸现场。
