无状态组件是将来进行优化的候选者，文档中对此进行了提示，而无需赘述：
在理想的情况下，您的大多数组件都是无状态功能，因为在将来，我们还可以通过避免不必要的检查和内存分配来针对这些组件进行性能优化。如果可能，这是推荐的模式。
资源
但是，目前，如果道具未更改，则无状态组件无法通过跳过渲染过程来优化性能。反应小组的一位成员已确认：
对于复杂的组件，定义
shouldComponentUpdate（例如，纯渲染）通常将超过无状态组件的性能优势。文档中的句子暗示着我们已经计划了一些未来的优化，这些优化将不会为无状态功能组件分配内部实例（我们只会调用该函数）。我们也可能不保持道具等。微小的优化。我们不会在文档中讨论细节，因为尚未真正实现优化（无状态组件为这些优化打开了大门）。[…]
关于
pureRender是否可以在函数上设置标志或允许其参与shouldUpdate生命周期的讨论，目前尚未实现。目前，无状态功能不能是纯渲染的。值得牢记的是，有时人们滥用/过度使用纯渲染。它有时可能会比再次运行渲染更昂贵，甚至更昂贵，因为您要遍历道具数组并可能执行字符串比较之类的事情，这对于最终返回true然后无论如何都要进行渲染的组件来说都是额外的工作。PureRender
/shouldComponentUpdate实际上被认为是性能的逃生之门，并不一定应盲目地应用于每个组件。
资源
我从这次讨论中得出的结论是，在某些情况下，对于复杂组件，与shouldComponentUpdate
无状态组件相比，可以通过实施来提高性能。另一方面，我将强烈考虑性能优势是否足以抵消组件增加的复杂性和更大的占地面积。
