“深度耦合”并非 JavaScript 原型继承或 new 绑定的设计目标，二者本意是实现松耦合、可复用的对象创建机制：new 绑定隔离实例状态，原型继承共享行为而隔离数据，所谓“深度耦合”实为误用所致。
“深度耦合”不是 JavaScript 原型继承或 new 绑定的设计目标，也不是推荐实践。实际上，new 绑定与原型继承共同构成的是松耦合、可复用、可扩展的对象创建机制——它们的本意恰恰是降低耦合度，而非加深。
new 绑定的核心作用：隔离实例状态
new 调用执行四步（创建空对象 → 关联原型 → 绑定 this → 返回实例），其中关键一步是：为每个实例独立初始化自有属性。这意味着：
- 每个实例的
this.name、this.id等数据属性互不干扰 - 构造函数内定义的变量（如
let cache = new Map()）不会被共享 - 即使多个实例共用同一原型方法，它们的操作上下文（
this）始终指向自身
原型继承的本质：共享行为，隔离数据
原型链实现的是方法与非私有属性的共享复用，而非状态绑定：
- 方法定义在
Constructor.prototype上，所有实例通过[[Prototype]]链访问，节省内存 - 但
this在调用时动态绑定到具体实例，保证obj1.method()和obj2.method()操作各自数据 - 若误将引用类型（如数组、对象）直接写在原型上，才会导致意外共享——这不是机制问题，而是使用错误
所谓“深度耦合”的常见误解来源
开发者有时会误把以下情况当作“深度耦合”，实则是设计不当或理解偏差：
-
手动篡改原型链：如
Child.prototype = Parent.prototype，使子类与父类原型完全同引用，修改一方直接影响另一方 -
在原型上存储可变状态：例如
Parent.prototype.counter = 0，所有实例共用该计数器 - 过度依赖构造函数内部闭包：用 IIFE 封装私有变量并暴露方法，导致实例间通过闭包环境隐式共享数据
-
滥用
bind(this)或硬编码this：在原型方法中强行绑定特定实例，破坏方法的复用性和上下文灵活性
真正需要关注的是解耦策略
要让对象体系健康可维护，应主动避免耦合：
- 构造函数只负责初始化实例自有属性；公共逻辑尽量放原型
- 若需共享状态，显式使用单例、模块级变量或外部 store，而非塞进原型
- 多层继承时，用
Object.create(Parent.prototype)替代new Parent()，避免父类构造函数副作用 - ES6 class 中善用
super()和静态字段区分实例层与类层逻辑
