使用全局变量替代React Context传递常量的可行性及弊端咨询

场景前提 #

• 变量值仅在首次渲染时设置一次
• 运行期间变量值不会改变
• 项目多位置需使用该变量
• 变量可在所有用户间共享

具体实现 #

根组件代码 #

'use client'

...

const MyRootComponent: React.FC<{ rawEnvData: string }> = ({ rawEnvData }) => {
  setConstants(rawEnvData);
  ...
}

constants.ts代码 #

let constants: ReturnType<typeof createConstants> | undefined = undefined;

export const setConstants = (rawEnvData: string) => {
  if (!constants) {
    constants = createConstants(JSON.parse(rawEnvData));
  }
  return getConstants();
};

const getConstants = () => {
  if (!constants) throw Error('constants not defined');
  else return constants;
};

期望优势 #

无需使用useContext Hook，不必遵循Hook规则即可访问常量。

已识别的弊端 #

• 可能在React Server Component或MyRootComponent初始化前误调用getConstants()
• 可能在常量初始化前于全局层面（如文件顶层）误调用getConstants()，例如const myValue = getConstants().myValue

遗漏的潜在问题 #

1. SSR/SSG环境的全局污染风险：如果项目涉及服务端渲染或静态生成，模块级的全局变量会被所有请求共享。虽然当前场景是变量在所有用户间共享，但如果后续部署环境变更、或需求调整为用户专属常量，这个全局变量会直接导致不同请求间的数据污染。
2. 测试用例互相干扰：单元测试时，全局变量的状态会在测试用例间残留。每次测试前都需要手动重置constants为undefined，否则前一个测试的状态会影响后一个测试，增加测试的复杂度和维护成本。
3. 依赖关系隐蔽：全局变量没有明确的依赖链路标识，新开发者可能不清楚constants的初始化时机，容易在不合适的地方调用getConstants()触发报错。相比Context，这种方式的依赖追踪难度更高，不利于长期维护。
4. 热更新兼容性问题：开发环境下React的热模块替换（HMR）可能会重新加载constants.ts模块，导致constants被重置为undefined，但MyRootComponent未必会重新执行setConstants，进而引发运行时错误。

是否违反核心原则？是否可行？ #

这种方式没有违反React的核心原则，但属于不够规范的实践。在你当前的场景（变量全局共享、运行期不改变）下，短期是可行的，但长期来看存在不少维护隐患。

如果要继续使用该方案，建议做以下优化：

• 在getConstants()的注释中明确标注初始化时机，避免误用
• 在测试框架中添加自动重置constants的逻辑，确保测试隔离
• 将constants包装为单例类，更清晰地管理初始化状态

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