Immutable.js
使用不可变数据类型的头一条理由肯定是能够保证做项目的人不能违反不可变原则。 严格地说，Immutable.js 库有助于简化开发过程，因为大家不再需要在代码中追踪数据，寻找数据变更的位置。不可变数据类型取而代之，能始终精确表现当前存储对象(store)中存储的程序状态。
有了这种库，就能发挥上述不可变数据类型的优点，但缺点也确实存在
不便与调试
如果要查看数据直接使用 console.log 需要翻来覆去的深层次的找，如果使用 toJS() 它自带的转换则一定层度上减缓开发速度。 javascript 语法错误就不存在了，若 a.b.w.d ‘w’ 对象名称写错了，现在得到的只会是一个 undefined 而真正的问题无法得知。
不便与迁移
1.toJS() 可以把Immutable对象转换成普通对象，不难免的会在代码中用到(例如与服务器交互)，但如果该对象较为深，则性能消耗的代价也是巨大的，PC 端这一点可以忽略，但移动端则需要考虑，包括 fromJS
不符合主流ES6原生代码的格式
比如 ES6 的解构，就变成了只能使用 get() 或 getIn()，若 props 携带有一定数量，则会带来更多的冗长代码，ES6 的 … 扩展语法也是
压缩后的 Immutable.js 大约 57kb
配合redux的话，中间必用来做转换的 redux-Immutable 引入了整个 Immutablejs 库 无法做 Tree shaking 代码缩减优化
侵入性强
例如引用第三方组件的时候，不得不进行数据转换
入手不易
需要对 Immutable.js 一套 api 进行熟悉才可上手
这是我总结的一些缺点，最终发现 缺点大过了缺点，最后想问一个问题，现在移动端项目盛行，若对于移动端项目而言，Immutable.js 是否真的合适？如果只是为了 不可变约束，immutability-helper 这类更加更加贴近原生的库是不是要更合适一些