React结合Mobx使用时为何需用Store Provider包裹应用

你第一种直接给createContext传入store实例的写法确实可以在简单场景下正常运行，两种写法的核心差异是store实例的创建时机和作用范围，常规方案选择Provider封装主要是为了解决以下几个实际开发场景的问题：

• SSR（服务端渲染）场景兼容
  你第一种写法的store是模块加载时就创建的全局单例，在服务端运行时，所有用户的请求都会复用同一个store实例，会出现不同用户的数据互相污染的严重问题。而Provider方案的store是在每次渲染应用树的时候才新建实例，每个用户请求对应独立的store，完全避免数据串用问题。
• 单元测试成本更低
  写组件单测时经常需要传入模拟的store实例来测试不同状态的表现，硬编码默认store的写法需要额外mock Context才能替换依赖，非常繁琐。用Provider的话测试时直接给Provider传入你需要的mock store实例即可，不需要修改原组件的任何逻辑。
• 支持多实例隔离场景
  如果你的项目需要在同一个页面渲染多个完全独立的同业务模块（比如多个独立的计数器卡片），全局单例store会导致所有模块共用同一份数据，修改一个会同步改动所有。用Provider的话每个模块外层单独套一个StoreProvider，就能实现多个store实例完全隔离，互不影响。
• 支持store的动态重置/替换
  比如用户退出登录需要清空所有全局状态时，全局单例store需要你手动重置每一个字段，很容易遗漏。Provider方案只需要给Provider的value传入新的store实例，整个组件树下的所有组件都会自动获取到新的干净状态，重置逻辑非常简单。

补充说明：如果你的项目是复杂度极低的纯客户端单页应用，不需要SSR、不需要单测、没有多实例需求，第一种写法完全可以正常使用。但为了后续的可扩展性，业界普遍会选择Provider方案做统一封装，避免后续迭代遇到架构瓶颈。

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