在组件树外管理React状态/上下文：优缺点及合理性分析

你提到的这种通过全局变量+工具函数在组件树外管理状态的方式完全可行，但仅适合特定简单场景，具体分析如下：

示例代码整理 #

状态管理工具文件（myUtil.js）

let apples = 0;

export function addApple() {
    apples++;
}

export function getApples() {
    return apples;
}

React组件调用

import { addApple } from "./myUtil";

// 修正原代码笔误：组件函数需加()，onClick绑定正确的函数名
export function AddAppleButton() {
    return <button onClick={addApple}>添加苹果</button>;
}

非React代码调用

import { addApple } from "./myUtil";

export function addMultipleApples(numberOfApples) {
    for (let i = 0; i < numberOfApples; i++) {
        addApple();
    }
}

优点 #

• 实现成本极低：不需要依赖任何第三方状态管理库，只用原生JavaScript语法就能完成状态的存储与修改，上手快。
• 跨场景通用性强：状态逻辑完全独立于React组件体系，不管是React组件、原生工具函数还是其他非React模块，都能直接调用，适合混合架构的项目。
• 无组件层级限制：不用通过props向下传递状态，也不需要嵌套在React Context的范围内，任何位置都能直接访问和修改状态。

缺点 #

• 无法自动触发组件重渲染：这是最核心的问题——React组件无法感知全局变量的变化。如果组件需要展示apples的数值，必须手动实现状态监听（比如结合useState和useEffect轮询，或者自己写订阅发布机制），反而会增加代码复杂度。
• 状态变更难以追踪：全局变量的修改可以发生在代码的任何地方，调试时很难定位到状态变化的具体来源，项目越复杂，维护难度越高。
• 缺乏状态管控能力：没有内置的状态快照、回滚或中间件机制，无法实现撤销操作、状态变更日志等进阶功能。
• 并发渲染下存在风险：在React并发模式中，全局状态的修改可能和组件渲染不同步，导致页面展示的状态和实际全局状态不一致，引发难以排查的bug。
• 测试干扰大：全局状态是共享的，多个测试用例之间会互相影响，每次测试前都要手动重置状态，增加测试的工作量。

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