用JS闭包模拟私有变量：模块模式封装技巧

在原生 JavaScript 语言规范中，早期的语法设计并没有提供类似强类型语言中的 private 访问修饰符。对象字面量或原型链上挂载的属性默认均为公开状态，任何外部调用方都可以直接进行读取和修改。为解决数据不变量遭到意外篡改、避免全局命名冲突，前端工程演进出了经典的模块模式（Module Pattern）。该模式的核心思路是：利用函数的局部执行栈作为物理隔离墙，结合闭包（Closure）对内部词法作用域的引用能力，实现内部私有状态与外部受控特权方法的清晰划分。

一、封装难题：为什么需要模拟私有变量

在开发具有复杂状态的业务单元时，直接公开对象属性会带来两个关键隐患：一是内部数据缺乏校验契约，外部调用代码可能赋入破坏逻辑的值；二是模块的内部实现细节与外部公共接口发生紧密耦合，后续重构时任何内部命名的变更都会导致调用方崩溃。

假设我们需要管理一个银行账户对象：

// 缺少私有封装的裸露对象
const account = {
  balance: 1000,
  withdraw(amount) {
    this.balance -= amount;
  }
};

// 隐患：外部可随意绕过业务逻辑直接修改内部关键状态
account.balance = -99999;

在上述代码中，balance 是完全暴露的。外部代码可以随意给其赋予非法负值，既没有经过合法性校验，也没有状态变更审计。要彻底杜绝此类操作，就必须让 balance 在外部无论通过何种路径都不可寻址，仅能通过预先设定的接口方法进行受控读写。

二、核心机制：作用域隔离与闭包捕获

JavaScript 采用词法作用域（Lexical Scoping），函数的内部变量在函数外部无法被直接访问。当一个外部函数执行完毕后，其内部变量原本会被垃圾回收机制释放；但如果该函数返回了一个或多个内部函数，并且这些内部函数在其代码中引用了外部函数的局部变量，那么这些局部变量所处的词法环境就不会被销毁，而是作为闭包驻留在内存中。

这正是模拟私有变量的关键机理：外部代码无法突破作用域链去直接读取外部函数的局部变量，但却能持有被导出的内部函数。这些被导出的内部函数充当了“特权方法（Privileged Methods）”，成为与私有状态交互的唯一受控桥梁。

如上图所示，当外部调用者尝试执行 console.log(count) 时，由于全局作用域链上并不存在 count 标识符，引擎会直接抛出 ReferenceError 错误。反之，当调用 counter.increment() 时，特权方法沿着自身的 [[Environment]] 作用域链向上寻址，精准捕获并更新了私有作用域内部的 count 变量。外部调用方在此过程中只能看到接口契约，根本无从感知内部状态存储的具体实现细节。

三、落地实操：经典模块模式的四步封装流程

掌握了闭包捕获原理后，构建一个具备工业强度的模块模式通常遵循严格的四步封装顺序：

1. 构建立即执行函数表达式（IIFE）：利用 (function() { ... })() 建立一个完全独立的局部执行作用域，切断与外部全局环境的变量命名关联。
2. 在内部声明私有状态与辅助函数：使用 let 或 const 声明私有变量，这些变量对外部调用方彻底隐形。
3. 编写带有防御性逻辑的特权方法：在特权方法中包含参数验证、状态转移保护逻辑，杜绝非法变更。
4. 返回公有接口字面量：构造一个仅包含公有 API 方法的纯对象字面量并导出，完成接口与实现的分离。

下面是一个完整的生产级单例模块代码实现，展示了一个具备金额校验与流水审计的电子钱包模块：

/**
 * 电子钱包模块（经典模块模式实现）
 */
const WalletModule = (function () {
  // 1. 声明私有变量（外部不可寻址）
  let _balance = 0;
  const _logs = [];

  // 2. 声明私有辅助函数（内部逻辑封装）
  function _record(type, amount, balanceAfter) {
    _logs.push({
      timestamp: Date.now(),
      type: type,
      amount: amount,
      balanceAfter: balanceAfter
    });
  }

  function _isValidAmount(amount) {
    return typeof amount === "number" && !Number.isNaN(amount) && amount > 0;
  }

  // 3. 构建并返回公共 API 对象（特权方法集合）
  return {
    // 存入金额特权方法
    deposit: function (amount) {
      if (!_isValidAmount(amount)) {
        throw new TypeError("存款金额必须为大于零的有效数字");
      }
      _balance += amount;
      _record("DEPOSIT", amount, _balance);
      return _balance;
    },

    // 支出金额特权方法
    withdraw: function (amount) {
      if (!_isValidAmount(amount)) {
        throw new TypeError("取款金额必须为大于零的有效数字");
      }
      if (amount > _balance) {
        throw new Error("账户余额不足，操作已拒绝");
      }
      _balance -= amount;
      _record("WITHDRAW", amount, _balance);
      return _balance;
    },

    // 安全读取当前余额
    getBalance: function () {
      return _balance;
    },

    // 防御性拷贝导出流水日志
    getLogs: function () {
      // 避免返回内部引用，防止外部调用方修改内部历史数组
      return _logs.map(log => ({ ...log }));
    }
  };
})();

运行结果验证如下：

// 正常业务调用
WalletModule.deposit(500);
WalletModule.withdraw(200);
console.log(WalletModule.getBalance()); // 输出: 300

// 验证私有状态不可被外部直接获取或破坏
console.log(WalletModule._balance);     // 输出: undefined
console.log(typeof _balance);          // 输出: undefined

// 验证防御性逻辑生效
try {
  WalletModule.withdraw(1000);
} catch (err) {
  console.log(err.message);            // 输出: "账户余额不足，操作已拒绝"
}

四、进阶扩展：模块模式的高级封装技巧

在实际复杂前端项目开发中，经典模块模式衍生出了若干进阶演进形态，以满足更高的代码可读性、可测试性以及分块解耦需求。

1. 揭示模块模式（Revealing Module Pattern）

经典模块模式中，特权方法往往以内联匿名函数的形式直接挂载在 return 对象上。当模块体积膨胀时，公开方法与私有实现的排版容易混乱，且公开方法之间互相调用必须借由 this.method()，存在上下文丢失风险。

揭示模块模式的改进方案是：将所有函数和变量统统定义在 IIFE 内部的私有作用域中，最后返回的对象字面量仅仅充当“指针映射表”。

// 揭示模块模式（Revealing Module Pattern）示例
const OrderModule = (function () {
  let _orderStatus = "PENDING";
  let _itemCount = 0;

  function doSetCount(count) {
    _itemCount = Math.max(0, count);
  }

  function doCheckout() {
    if (_itemCount === 0) return false;
    _orderStatus = "COMPLETED";
    return true;
  }

  function doGetStatus() {
    return _orderStatus;
  }

  // 仅在末尾明确“揭示”哪些函数向外暴露
  return {
    setCount: doSetCount,
    checkout: doCheckout,
    status: doGetStatus
  };
})();

此模式的最大优势在于：内部代码全部保持一致的声明语法；即使外部调用代码执行了属性重写（如 OrderModule.checkout = null），模块内部 doCheckout() 对其他函数的调用也不会受到任何破坏，因为内部协作走的是稳定的局部函数标识符引用。

2. 全局参数依赖注入（Dependency Injection）

在大型应用中，模块通常需要依赖外部全局环境（例如 window、document 或第三方工具库）。直接在 IIFE 内部引用外部变量虽然可行，但更规范的做法是将全局变量作为实参显式传入 IIFE：

(function (global, document, undefined) {
  let _cache = {};

  function store(key, val) {
    _cache[key] = val;
    global.sessionStorage.setItem(key, JSON.stringify(val));
  }

  global.StorageModule = { store };
})(typeof window !== "undefined" ? window : globalThis, document);

3. 松耦合模块扩展（Loose Augmentation）

当一个模块非常庞大、需要拆分存放在多个独立的 .js 文件中时，脚本的加载先后顺序可能会产生竞态。通过松耦合扩展技巧，可以让各个文件自由扩展同一个模块：

// 在 module.partA.js 或 module.partB.js 中运行
var AppEngine = (function (my) {
  // 扩展 Part 模块专属逻辑
  my.calculate = function (x, y) {
    return x * y;
  };
  return my;
})(AppEngine || {}); // 若尚未初始化则兜底传入空对象

无论哪个脚本先下载并执行完毕，AppEngine || {} 都能确保传入一个合法对象，并在最后将其重新赋值回全局引用，实现平滑、无顺序依赖的模块拼装。

4. 单例 vs 工厂函数：从唯一实例到多实例

直接执行 IIFE 产生的是单例（Singleton）。如果业务场景需要生成多个拥有独立私有状态的对象，只需将 IIFE 改写为普通的工厂函数（Factory Function）：

function createCounter(initialVal = 0) {
  // 每个工厂实例拥有独立的闭包环境
  let _count = initialVal;

  return {
    inc() { return ++_count; },
    get() { return _count; }
  };
}

const c1 = createCounter(10);
const c2 = createCounter(50);
c1.inc();
console.log(c1.get()); // 输出: 11
console.log(c2.get()); // 输出: 50 (与 c1 互不干扰)

五、避坑指南：必须防范的关键漏洞

1. 引用类型的值泄漏（Reference Leak）

这是闭包私有变量封装中最容易被忽视的安全盲区。如果私有变量保存的是对象、数组或 Set/Map 等引用数据类型，特权方法在导出该变量时，切不可直接返回原引用：

// 存在漏洞的实现
const ConfigModule = (function () {
  const _config = { env: "production", debug: false };
  return {
    getConfig() { return _config; } // 致命失误：导出了真实内部引用
  };
})();

// 外部代码虽然无法直接访问 _config，却可以通过返回值绕过封装篡改状态
const cfg = ConfigModule.getConfig();
cfg.debug = true; // 内部 _config 的 debug 属性被非受控篡改！

2. 闭包与垃圾回收（Memory Retention）

只要导出的公共模块对象依然存在于活动执行环境中，闭包所捕获的整个函数词法环境就无法被 V8 等 JS 引擎的垃圾回收器（Garbage Collector）回收。如果闭包环境中无意保留了庞大的 DOM 节点、二进制 Buffer 或超大列表，将导致这部分内存在整个应用生命周期内无法释放。针对此类场景，应提供显式的 dispose() 或 cleanup() 接口将不需要的内部变量置为 null。

六、现代技术演进与选型决策

随着 ECMAScript 规范的不断演进，JavaScript 逐步引入了更多实现私有状态的语法方案。现代开发中主要存在以下三种主要技术路径：

在工程选型中，若模块本身是天然的单例对象（如全局缓存管理器、网络请求代理、配置字典），基于闭包与 IIFE 的模块模式依然是最简洁、最成熟且无需任何转译工具支持的最佳实践。而对于需要频繁 new 产生成千上万个实例的业务实体，使用 ES2022 的原生 #privateField 语法配合 Class 则能在保证私有性的同时获得最优的内存利用率和引擎执行效率。