对比props需要耗费额外性能就不说了，下面想说说另外的
1.很多时候我们为了代码可读性更好，也可能是为了方便，我们会这样写代码
<Comp style={{color: 'red'}} onClick={() => func(params)}} />
显然不会去到处写useMemo和useCallback 否则也太丑了，这种情况把Comp改成纯组件根本无济于事，因为props的引用总会变化。
2. 如果某次状态变更，导致你期望以外的组件执行了render方法，而这个组件又是庞大笨重的，那么首先应该思考的是，这个组件是否应该移到父组件层级？或者把state定义到子组件。因为这才是根本问题所在。通常一份特别笨重的东西，是不应该和琐碎的小零件平起平坐的。应当有这样的管理意识。
3. render并没有那么糟糕，diff算法还会在最后登场去优化真实dom更新过程。
4. 有人做了性能测试，把所有的组件默认改成纯组件，在接近一半的测试场景中都表现为负优化。（当然其实我是不太理解，props的浅对比真的这么耗费性能吗？有待研究，真心很奇怪。假设有10个props，那也仅仅相当于调用10次Object.is()方法而已，为什么会比执行render消耗更大？而且一般执行完render之后是需要去一个个dom节点做diff的，到后面对比的性能消耗岂不是更大？）
5. 重新思考父组件更新触发子组件render的行为，其实反而能避免一些bug。比方你传递了一个深层嵌套的对象给子组件使用，但使用了突变式修改值更改对象的属性，然后通过其他方式触发了父组件更新。那么问题来了，子组件是纯组件的话就不会被更新。也许你会说这是代码水平的问题，你突变式修改值了！但更重要的因素在于，这样的代码场景理论上会广泛存在，而只有真正去执行子组件render再去diff才能避免这样的问题。假如你是框架的开发者，你会作何取舍？想必答案会是一样的，还是“忍痛”render吧！毕竟不是完全没有好处的。你不去render对比了，那好嘛，人们可能会开始痛斥react更新不够智能了。
