JavaScript利用enumerable实现属性隐私保护

JavaScript 里其实没有真正意义上的私有属性，这是老生常谈的问题了。不过，如果不想依赖闭包或者 WeakMap 那一套复杂的方案，有没有更轻量的办法？答案是肯定的——通过 enumerable: false 配合其他机制，就能实现一种可预测的“隐私保护”效果：让属性不被 for...in、Object.keys()、JSON.stringify() 等默认遍历方式暴露，从而降低意外访问和序列化的风险。这种方法虽然谈不上绝对安全，但在很多日常场景下已经够用了。

利用 enumerable: false 隐藏属性（基础层）

把属性标记为不可枚举，是最直接的控制手段。它不影响属性的可读写性，只影响它是否出现在标准遍历中。具体来说：

• 使用 Object.defineProperty() 显式设置 enumerable: false
• 该属性仍然可以通过点号（obj.prop）或方括号（obj["prop"]）直接访问
• 不会出现在 Object.keys()、for...in、console.log(obj)（部分环境）中

举个例子：

const user = {};
Object.defineProperty(user, '_token', {
  value: 'abc123',
  writable: true,
  enumerable: false,  //  关键：不参与遍历
  configurable: true
});

console.log(Object.keys(user)); // [] —— 看不到 _token
console.log(user._token);       // 'abc123' —— 仍可直接读取

看到没？_token 虽然藏起来了，但直接读还是能拿到。这就是基础层的作用——防君子不防小人。

配合 get/set 实现受控访问（逻辑层）

光设 enumerable: false 还不够安全，因为属性依然可以被直接读写。更实用的做法是结合访问器（getter/setter），在隐藏的同时加入校验或转换逻辑：

• 把敏感字段定义为不可枚举的私有描述符（比如 _internalId）
• 提供公开的 getter/setter，对读写行为做约束（如只读、格式校验、日志记录）
• getter/setter 本身设为 enumerable: true，保持接口可见

来看一个实用的例子：

const config = {};
Object.defineProperty(config, '_apiKey', {
  value: '',
  writable: true,
  enumerable: false
});

Object.defineProperty(config, 'apiKey', {
  get() { return this._apiKey; },
  set(val) {
    if (typeof val === 'string' && val.length > 8) {
      this._apiKey = val;
    } else {
      throw new Error('API key must be a string longer than 8 chars');
    }
  },
  enumerable: true //  公开接口可见
});

这样一来，外部代码只能通过 config.apiKey 来读写，而且赋值时自动校验长度。内部存储的 _apiKey 既不可枚举，又无法被意外遍历到。

与 JSON 序列化协同（工程层）

JSON.stringify() 默认忽略不可枚举属性，这是天然优势。但有时候我们还需要更精细的控制——比如即使某个内部字段因为疏忽被设成了可枚举，仍然不希望它出现在序列化结果里。这时可以自定义 toJSON() 方法：

• 定义 toJSON() 返回一个精简对象，显式排除敏感字段
• 即使某个内部字段因疏忽被设为 enumerable: true，toJSON 仍能兜底
• 注意：toJSON 本身应设为 enumerable: false，避免暴露自身

代码示例：

Object.defineProperty(user, 'toJSON', {
  value() {
    return { id: this.id, name: this.name }; // 不含 _token
  },
  enumerable: false
});

这样，即使 _token 不小心被设成了可枚举，JSON.stringify(user) 输出的也只是安全的常规字段。

注意事项与边界说明

必须强调的是，这种方案不是加密，更不防恶意反射。几个关键边界需要拎清楚：

• Object.getOwnPropertyNames() 和 Reflect.ownKeys() 仍然能列出所有自有属性，包括不可枚举的
• 开发者工具（DevTools）中通常仍然可见所有自有属性，包括不可枚举的
• 这种方案适合防御“无意暴露”和“常规序列化”，不适合对抗主动探测或沙箱逃逸
• 如果需要更强的隔离，应该考虑 #privateFields（ES2022+）或模块级闭包

总结一下：enumerable: false 加上 getter/setter 和 toJSON，构成了一个轻量但实用的三层隐私保护方案。它不需要引入额外的运行时开销，代码可读性好，适合大多数不想搞复杂架构的前端项目。当然，如果你面对的是安全等级要求极高的场景，别犹豫，直接上真私有字段吧。