react-redux v5迁移至v8技术咨询：潜在破坏性变更与注意事项

一、connect 相关的其他破坏性变更 #

• mapDispatchToProps 参数调整：v6+ 中，mapDispatchToProps 默认不再接收 ownProps 作为第二个参数（仅当显式设置 { pure: false } 时才会传递）。如果你的代码依赖该参数动态生成 dispatch 方法，需改为在组件内部通过 useSelector 获取 props 后处理，或调整 connect 配置。
• pure 选项默认行为强化：v6+ 里 connect 默认是纯组件（pure: true），会对 mapState 和 mapDispatch 的返回值做浅比较。若组件依赖的 props 变化未在 mapState 中体现，可能导致不触发重渲染，需显式设置 pure: false 或优化状态映射逻辑。
• 移除 connectAdvanced：v6 开始彻底移除了 connectAdvanced 高阶组件，若代码中直接使用了该 API，需替换为 connect 或改用 Hooks（useSelector/useDispatch）。

二、Hooks API 的强制适配趋势 #

v8 虽仍支持 connect，但后续优化和新特性会聚焦于 Hooks 方案，建议逐步迁移：

• useSelector 支持精准选择状态片段，比 connect 的浅比较更灵活，能有效减少不必要的重渲染。
• useDispatch 可直接获取 dispatch 方法，无需再通过 mapDispatchToProps 包装逻辑。
• 类组件若暂不迁移，需注意 connect 在 v8 中的内部实现已基于 Hooks 重构，部分边缘场景可能出现行为差异。

三、Context 机制的深层变化 #

• 默认 Context 不可自定义：v6+ 禁止修改默认 Redux Context，多 store 或自定义 Context 场景下，必须创建自定义 Context 并同步传递给 <Provider> 和 connect/Hooks。
• Hooks 必须在 Provider 范围内使用：useSelector、useDispatch 等 Hooks 只能在被 <Provider> 包裹的组件内调用，否则会抛出错误，需检查组件层级是否存在 Provider 遗漏。

四、TypeScript 类型系统重构 #

若项目使用 TypeScript，v6+ 的类型定义完全重写：

• connect 的类型参数顺序、结构大幅调整，旧代码中的类型断言大概率失效，需重新适配。
• Hooks 类型更简洁，但需正确定义 RootState 类型，通过 useSelector<RootState> 约束状态选择逻辑。

五、性能优化相关的行为差异 #

• shallowEqual 使用逻辑变化：v6+ 中 useSelector 默认不做浅比较，需手动导入 shallowEqual 作为第二个参数避免不必要重渲染；而 connect 仍默认启用浅比较，两者行为差异需重点注意。
• 批量更新逻辑适配 React 18：v8 集成了 React 18 的自动批量更新，异步操作（如 setTimeout、Promise 回调）中的 dispatch 会自动批量处理。若代码之前手动依赖 unstable_batchedUpdates，React 18+ 环境下可移除，低版本需保留。

六、废弃 API 彻底移除 #

• 移除了 <Provider> 除 store 外的所有废弃 props。
• 移除了 mapDispatchToProps 中自动绑定 dispatch 的旧逻辑（直接传递对象的方式仍支持，但内部实现已变更）。

迁移实操建议 #

1. 分阶段升级：先升级到 v6，验证所有功能正常后再逐步过渡到 v7、v8，降低跨版本直接迁移的风险。
2. 优先迁移 Hooks：新开发组件直接使用 Hooks API，旧组件逐步替换，减少对 connect 的依赖。
3. 针对性测试：重点覆盖依赖 ref、ownProps、多 store 的组件，以及 TypeScript 类型校验场景。
4. 检查第三方依赖：确认项目中使用的第三方 UI 库或工具已兼容 v6+ 版本，避免兼容性冲突。

内容的提问来源于stack exchange，提问作者Anroche