Redux reducer默认分支return state与return {...state}的区别

所有差异的根源来自Redux的核心工作机制：它判断状态是否发生更新的唯一标准，是新旧状态的内存引用是否相等（使用Object.is比较），而非状态对象内部的字段值是否一致。

两种返回方式的核心行为差异 #

1. return state（直接返回原状态引用） #

• 执行逻辑：完全不创建新对象，直接把reducer入参传入的旧状态原样返回
• 内部判断逻辑：新旧状态引用100%一致，会被Redux直接判定为「状态没有任何变化」
• 连锁影响：所有订阅该状态的逻辑（包括react-redux的useSelector、connect连接的组件）都会因为引用匹配，跳过重渲染流程，没有任何额外性能开销
• 合规性：完全符合Redux开发规范——Redux要求的「不可变更新」本质是禁止直接修改原state的字段值，从来没有要求无改动的场景下必须生成新对象返回。

2. return { ...state }（返回浅展开的全新状态对象） #

• 执行逻辑：基于原state的所有字段值，浅拷贝生成一个内存地址完全独立的全新对象；哪怕新旧对象所有字段值完全一致，二者也不存在任何引用关联
• 内部判断逻辑：新旧状态引用完全不同，会被Redux直接判定为「状态发生了更新」
• 连锁影响：所有订阅该状态的组件，不管是否用到了被拷贝的字段，都会触发完整的重渲染流程——哪怕新拷贝出来的对象和原对象没有任何值上的差异
• 合规性：这种写法只有和字段更新搭配时才是合理的，比如需要更新某部分内容时写{ ...state, someField: newValue }；如果完全没有修改任何内容，单独在分支里返回这个展开后的新对象，属于无意义的性能浪费。

开发中常见的认知误区 #

很多开发者会在default分支写return { ...state }，本质是踩了对不可变原则理解的常见坑：误以为只要reducer返回了原state引用，就算违反了不可变规则。
实际上，switch语句default分支的设计初衷，就是在没有匹配到任何可处理的action类型时，不改动任何状态。这种场景下最合理、性能最好的写法就是直接return state。如果在default分支返回展开后的新对象，会导致哪怕是完全不相关的action触发（比如用户触发了一个未在当前reducer注册的自定义action、切换无关路由），都会生成新的state引用，连带触发大量无意义的组件重渲染，长期积累会造成明显的应用卡顿。

特别澄清：这里的讨论和reducer函数的默认参数逻辑没有关系。很多人提到的“默认状态解构”，指的是reducer函数签名里写的function reducer(state = initialState, action)——这部分逻辑是为了在应用初始化、state参数为undefined时，自动传入初始状态，和switch分支内部的返回逻辑是两个完全独立的运行流程，不要把二者的规则混为一谈。

内容的提问来源于stack exchange，提问作者Paweł Baca