javascript封装靠作用域、闭包和symbol实现访问控制，而非访问修饰符；继承冲突源于原型链同名属性覆盖，隐蔽难调试。
JavaScript 中的封装不是靠访问修饰符实现的，而是靠作用域、闭包和语言机制（比如 Symbol）来划清边界；继承冲突则往往源于原型链上同名属性/方法的覆盖或共享，而非语法报错——它更隐蔽，也更难调试。
封装的核心：控制访问路径，而非隐藏数据
JS 没有 private 关键字，但封装的本质是“谁有权读写”。常见手段包括：
- 闭包私有变量：在构造函数或模块作用域内声明变量，仅通过返回的函数访问，外部无法直接触碰
- this 绑定的实例属性：每个实例独有一份，适合公开或半公开状态（如 this.id、this.name）
- Symbol 键属性：用 const _cache = Symbol() 定义键，确保该属性不被遍历、不被字符串名意外覆盖，且归属明确
- WeakMap 私有存储：以实例为键存私有数据，避免污染实例本身，也防止内存泄漏
继承中属性冲突的典型场景
冲突常发生在父子类或多个 Mixin 同时操作同一名称时：
- 父类 this.handlers = []，子类也赋值 this.handlers = [] → 实际共享数组，一个 push 影响所有实例
- 第三方库扩展你的类，也用 this.data 存状态 → 你自己的 data 被覆盖或误读
- 多个 Mixin 都定义 this.config → 最后加载的 Mixin 写入生效，前序配置丢失
- 子类 constructor 中调用 super() 后又重设 this.id → 父类初始化逻辑被绕过
用 Symbol 切断属性覆盖链
Symbol 不是“加锁”，而是“换钥匙”——每次 Symbol() 都生成唯一键，天然隔离：
- 父类定义 const _id = Symbol("id")，子类定义 const _retry = Symbol("retry")，两者互不影响
- obj[_id] = 123 后，Object.keys(obj)、JSON.stringify(obj)、for...in 都看不到它
- 只有持有该 Symbol 变量的位置才能访问，外部代码无法靠字符串猜测或覆盖
- 避免使用 Symbol.for("id") 处理私有状态，它会跨模块复用同一个 Symbol，破坏封装边界
方法重名时的三种应对策略
同名方法在原型链上不是错误，而是行为选择问题：
- 想完全替换：直接重写子类方法，无需额外操作；但要注意是否切断了必要逻辑
- 想增强父逻辑：在子方法中用 Object.getPrototypeOf(Child.prototype).methodName.call(this, ...) 调用父版，或升级到 class + super 获得更清晰语法
- 想共存不干扰：改用语义化命名（如 validateInput / validateWithAuth），或把通用逻辑抽成独立工具函数，不挂载在原型上
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
