React Native 实现全局主题（含明暗模式）的最优方案是什么？

关于React Navigation主题实现的确认 #

你的理解完全正确，React Navigation的主题系统底层就是基于React Context封装实现的，它内部通过Context容器存储全局主题配置，暴露的useTheme Hook本质就是从Context中读取主题值，和自定义Context实现主题的逻辑完全一致。

两个主流方案的疑问解答 #

• Context方案的StyleSheet访问问题：你的理解没有问题，静态声明的StyleSheet.create是在模块加载阶段就执行完成的，而Context值只能在React组件的渲染周期或Hook调用中获取，确实无法直接在静态StyleSheet中访问主题。如果要兼容这个场景，可以放弃静态StyleSheet，改为在组件内部调用Hook拿到主题后动态生成样式，不过这种方式在组件频繁重渲染时会产生额外的样式计算开销，中小项目可以忽略，大型复杂项目需要做对应的memo优化。
• Styled Components的场景覆盖问题：不需要在每个组件内手动引入主题相关Hook。Styled Components本身已经在内部封装了Context注入逻辑，你只需要在应用根组件外层包裹ThemeProvider传入主题对象，所有通过styled方法创建的组件都可以直接在样式声明中访问props.theme拿到当前主题值。对于自定义组件的场景，只要你给自定义组件透传style属性，或者直接用styled(自定义组件)的方式包裹自定义组件，几乎所有样式配置场景都可以覆盖，没有明显的功能短板。

Zustand存储主题方案的利弊分析 #

这个方案并不是非主流方案，很多实际项目都有落地，它的弊端主要集中在以下几点：

1. 重渲染粒度控制成本更高：默认情况下如果组件订阅了完整的主题对象，主题任意属性变更都会触发所有订阅组件的重渲染，需要手动将订阅粒度拆分到具体用到的主题属性（比如useThemeStore(state => state.theme.cardBg)）才能避免不必要的重渲染，而Context配合useContextSelector或者Styled Components的内部优化，会自动处理粒度问题，使用成本更低。
2. 第三方生态适配成本更高：目前React Native生态的主流路由、UI组件库（比如React Navigation、Gluestack UI、NativeBase等）默认都是适配Context主题协议的，你如果用Zustand存储主题，需要额外写一层适配层，将Zustand中的主题状态同步到Context中供给第三方库使用，多了额外的维护成本。
3. 跨端同构适配成本高：如果你的项目后续需要适配React Native Web+SSR/SSG场景，Context是和React渲染树绑定的，天然支持多请求的状态隔离，而Zustand默认是全局单例，多请求并发场景下会出现状态污染问题，需要额外做实例隔离处理，配置复杂度更高。

如果你的项目没有非组件环境（比如工具函数、全局请求拦截器）访问主题的需求，更推荐优先用Context或者Styled Components的原生方案；如果有非组件环境访问主题的强需求，只要做好状态订阅的粒度优化，Zustand方案完全可以正常使用，没有致命问题。

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