我从学react起，一共写了三次react项目
第一次是学生选课系统，完全不知道生命周期的规律和顺序，也不知道axios到底应该放在哪里才能更好的请求到，文件分工不明确，没有体现组件化的优势，各处state异常混乱，完全定位不到错误位置。
第二次是研究生双选导师的系统，由于时间原因，很多的组件、方法都是堆积在一个js文件中，单个文件过于臃肿，且大部分方法都是上一次的方法照搬。优点是明确了各生命周期该干的事情，且明白了当系统慢慢扩展，慢慢变大时，普通的state渲染界面的缺陷就会逐渐暴露而出，状态管理几乎是所有bug的根源之处：
一、排错困难：当出现问题的时候，难以定位到错误位置，组件嵌套组件，不知道到底是传进去的时候出现的错误，还是在子组件某一生命周期出现的错误。
二、过多嵌套的state，让开发者对于数据逻辑的混乱无所适从。
redux就是为此而生的一种技术，它使用单一的state仓库(store)来保存数据，修改其中数据只能通过动作(action)来进行，拿出来的数据只能可读不可修改，保证了开发者对数据的修改都在同一位置，不会出现各生命周期各有一堆请求数据的代码的情况。
第三次就是我现在正在写的餐厅管理系统，新使用的技术就是redux，使用前觉得，怎么会有这么麻烦的东西？修改还要通过动作，还不如我直接setState呢，还只有一个仓库来存state，我每个界面一个state不好吗？但是使用后才会发现，Redux很像是一个矫正工具，让你保证单项的数据流流入单一位置，再只从这个仓库取出数据。redux中修改数据的代码就像下方我举的例子
1 const action = changeHeadColor(index); 2 store.dispatch(action);