Node.js代码库大量使用全局变量的重构策略咨询

一、你的判断完全正确：这种全局变量用法是严重的不良实践 #

你遇到的ReferenceError正是这种写法的典型问题——它彻底破坏了模块的封装性和依赖透明度：

• 依赖关系模糊：开发者无法直观知晓一个函数依赖哪些全局变量，也不清楚需要提前调用哪些初始化函数；
• 调用顺序敏感：初始化顺序稍有偏差就会导致变量未定义，在大型项目中几乎无法维护；
• 变量污染风险：全局变量可能被其他模块或第三方库意外覆盖，排查问题的难度极大；
• 测试困难：全局变量属于共享状态，单元测试时无法隔离不同测试用例的运行环境。

二、重构的可行策略 #

针对40个文件、50-100个全局变量的规模，建议采用渐进式重构，避免一次性大规模修改引发的风险：

1. 先梳理全局变量依赖清单 #

用代码编辑器的全局搜索功能（比如VS Code的Ctrl+Shift+F），标记每个全局变量的：

• 赋值位置（哪个函数设置了它）
• 引用位置（哪些函数用到了它）
  整理成表格或文档，这是后续重构的基础，确保不会遗漏任何变量的使用场景。

2. 模块级封装：先把全局变量收归模块 #

第一步不要直接改成面向对象，先将全局变量转为模块内部的私有变量，通过导出的方法访问/修改，降低重构难度：
比如修改A.js：

// A.js
let a; // 模块私有变量，不再暴露到全局

const A_init = () => {
  a = 1;
};

const getA = () => a; // 导出获取方法

exports.A_init = A_init;
exports.getA = getA;

对应的C.js需要显式依赖A模块：

// C.js
const { getA } = require('./A');
const { getB } = require('./B');
let c;

const C_init = () => {
  c = getA() + getB();
};

const getC = () => c;

exports.C_init = C_init;
exports.getC = getC;

这一步把隐式的全局依赖变成了模块间的显式依赖，开发者能清晰看到C模块需要A和B的方法。

3. 添加初始化校验，降低调试成本 #

在过渡阶段，给依赖全局变量的函数加上前置校验，抛出明确的错误信息：

// 未完成模块封装前的临时措施
const C_init = () => {
  if (typeof a === 'undefined' || typeof b === 'undefined') {
    throw new Error('调用C_init前必须先调用A_init和B_init');
  }
  c = a + b;
};

这样开发者遇到错误时能直接定位问题，而非面对模糊的ReferenceError。

4. 统一初始化入口 #

把分散的初始化函数集中到一个入口文件，按正确顺序调用，避免用户自行管理顺序：

// init.js
const { A_init, getA } = require('./A');
const { B_init, getB } = require('./B');
const { C_init, getC } = require('./C');

const initAll = () => {
  A_init();
  B_init();
  C_init();
  // 导出所有需要的变量，避免用户直接访问全局
  return {
    a: getA(),
    b: getB(),
    c: getC()
  };
};

exports.initAll = initAll;

用户使用时只需要：

const { initAll } = require('./init');
const { a, b, c } = initAll();
console.log(a, b, c); // 1,2,3

5. 逐步替换全局引用，最终消除全局变量 #

完成模块封装后，逐个替换代码中所有的全局变量引用，比如把console.log(a, b, c)改成console.log(getA(), getB(), getC())，直到所有全局变量被彻底移除。

6. 面向对象封装（最终推荐方案） #

当模块级封装完成后，把关联紧密的变量和函数进一步封装成类，让状态和行为绑定，依赖关系更清晰：

// A.js
class A {
  constructor() {
    this.a = 1; // 实例属性，不再是全局
  }
  getValue() {
    return this.a;
  }
}
exports.A = A;

// B.js
class B {
  constructor() {
    this.b = 2;
  }
  getValue() {
    return this.b;
  }
}
exports.B = B;

// C.js
class C {
  constructor(aInstance, bInstance) {
    // 显式依赖A和B的实例，依赖关系一目了然
    this.c = aInstance.getValue() + bInstance.getValue();
  }
  getValue() {
    return this.c;
  }
}
exports.C = C;

用户使用时：

const { A } = require('./A');
const { B } = require('./B');
const { C } = require('./C');

const a = new A();
const b = new B();
const c = new C(a, b);

console.log(a.getValue(), b.getValue(), c.getValue()); // 1,2,3

这种方式不仅消除了全局变量，还让代码的职责更清晰，单元测试时可以轻松mock实例，隔离测试环境。

三、全局变量的可接受场景 #

几乎没有适合这种随意设置全局变量的场景。唯一勉强可接受的是：存放整个应用生命周期中唯一、不可变、无依赖的全局配置（比如应用版本号），但即使是这种情况，也更推荐用模块导出常量，而非全局变量。

在大型代码库中，随意使用全局变量完全不可取，它会彻底摧毁代码的可维护性。

四、全局变量的约束规范（仅过渡阶段使用） #

如果因为某些原因无法立即消除全局变量，必须遵守以下规范：

• 统一命名前缀：所有全局变量加上项目专属前缀，比如myapp_a、myapp_b，避免和其他库冲突；
• 明确初始化入口：所有全局变量必须在指定的初始化函数中设置，禁止在随机函数中随意赋值；
• 完整文档：每个全局变量的用途、依赖的初始化步骤必须写入文档；
• 只读约束：禁止在非初始化函数中修改全局变量，保持状态稳定。

五、是否推荐面向对象方法？ #

非常推荐。面向对象的封装能把相关的状态和行为绑定在一起，让依赖关系显式化，避免全局变量带来的所有问题。尤其是在大型代码库中，类/构造函数能让代码的职责更清晰，更容易扩展和维护。

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