组件通常拥有生命周期——开启、关闭、和中间的很多阶段，它由组件的类型决定。通常情况下，组件的生命周期由创建开始，随着组件的运行，它的内部状态会发生改变。这些状态很可能就是导致组件之后出错的原因。

例如，如果组件处于忙碌状态，并且没有处理任何外部请求，那我们通常会在系统的其他部分寻找问题。可能组件的忙碌是合理的，也可能是某些原因导致组件被错误地卡在忙碌状态。如果是第二个原因，那么重启组件应该能解决所有问题，并且可以使组件再次回到运行状态，处理外部请求。

实际上，重启组件应该是从错误中恢复的最后一搏。走到这一步意味着我们不知道组件出错的原因，只知道有些功能没有正常工作，并对整个应用造成极大的破坏。在出现错误时重启组件的真正难点在于，清理了错误的内部状态后，组件需要重启并恢复到它出错的那个状态。如果某个组件保存着从后端获取的集合，那么将其重启之后，需要再次获取该集合，才能让组件回到当时的状态。

因此，在为组件设计重启功能之前，需要进行如下考虑。首先，应该在什么情况下重启组件？这通常要根据应用的具体情况而定，但大多数重启行为都集中在组件出错的边缘情况。当组件中存在一个bug时，重启它不见得有所帮助，但也不见得有所损害。另一个要考虑的方面，是对数据源的存储，即应用使用的数据，而不是内部状态。这是两个不同的东西——内部状态是由组件计算出来的，而数据则是由外部输入的源。

我们实现组件重启机制，不是为了掩饰代码中的其他问题。它是一个优秀的组件设计思想，迫使我们思考组件在运行环境中可能出现的各种情况。即使只是提出问题，也是有意义的——如果在运行时重启组件或使用一个新的实例代替它，会发生什么事情？我们可能永远不会去做这些事情，即使想做，也不一定可行。但是，通过这些练习，可以将组件设计得在这些场景中更具弹性。