JavaScript私有字段底层依赖WeakMap映射机制：以实例为弱引用键，值存于闭包封装的不可枚举结构中，确保自动回收、不可遍历、继承隔离。
私有字段的底层实现，不是靠语法糖“锁住”属性，而是依赖运行时机制来隔离访问路径。不同语言采用不同策略，但核心思路一致：让私有数据不暴露在对象自身的可枚举属性中，同时限制外部代码的直接触达能力。
JavaScript：WeakMap 是事实上的底层模型
ES2022 引入的 #field 语法，引擎（如 V8）在内部普遍采用类似 WeakMap 的映射结构来存储私有状态。它不是把字段挂到实例上，而是用实例本身作键，把值存在一个外部不可见的 WeakMap 中：
- 键必须是对象（天然适配类实例），且为弱引用——实例被销毁时，对应私有数据自动释放，避免内存泄漏
- WeakMap 变量被闭包封装，外部无法获取或遍历，in、Object.keys()、Reflect.ownKeys() 全部查不到私有字段
- 子类构造时调用 set(this, ...)，就自然获得独立存储空间，无需额外处理继承逻辑
Java：字节码 + JVM 访问控制双层保障
Java 的 private 字段在编译后仍保留在字节码中，但 JVM 在运行时强制执行访问检查：
- 字段元数据（名称、类型、修饰符）写入常量池，并未隐藏，只是禁止非授权访问路径
- 普通调用会触发 access control check，失败则抛出 IllegalAccessError
- 反射可通过 Field.setAccessible(true) 绕过检查，本质是 JVM 层面临时关闭校验，依赖 Unsafe 直接读写内存偏移量
Python 和 Go：约定与包级作用域主导
它们没有真正的“运行时私有字段”，而是靠语言规范和作用域规则达成等效效果：
- Python 使用 _name（单下划线）或 __name（双下划线名称改写）作为命名约定；__name 会被解释器重命名为 _ClassName__name，虽可绕过但需明确意图
- Go 的私有性由标识符首字母大小写决定：小写字母开头的字段/方法仅在定义它的包内可见；同包内的方法可直接访问，无需反射或特殊语法
- 两者都不阻止反射访问，但 Python 的 getattr(obj, '_name')、Go 的 reflect.Value.FieldByName("name") 都属于显式越界操作，不属于常规使用路径
为什么不用 Map 或闭包变量？
早期模拟方案暴露了关键缺陷：
- Map：键为实例引用但属强引用，实例销毁后 Map 条目仍驻留内存，导致泄漏
- 闭包变量（如 const name = new WeakMap()） 若未严格封装，可能被意外导出或挂载到全局，破坏私有性边界
- Symbol 虽唯一，但可通过 Object.getOwnPropertySymbols() 枚举获取，无法真正隐藏
不复杂但容易忽略：私有字段的“私有”，从来不是数据藏起来了，而是访问通道被收窄了——谁可以走、怎么走、走了之后能不能被发现，才是底层实现真正较量的地方。
