构造函数调用链受JS调用栈容量约束而非原型链长度限制；真正导致栈溢出的是同步连续调用（如super()链或递归new），而非继承层数本身，需通过控制执行流（如深度守卫、迭代替代、微任务切片）规避风险。
constructor 构造函数在继承中的调用链本身没有深度限制，但它的执行受 JavaScript 调用栈（call stack）的物理容量约束——也就是说，不是“构造函数不能嵌太多层”，而是“调用它们的递归或连续构造过程会撑爆栈”。
构造函数调用链 ≠ 原型链长度
这两者常被混淆，但本质不同：
- 原型链长度：由
Object.getPrototypeOf()串起的对象引用链，终点是null；它不占调用栈，无引擎硬性层数限制，只受内存影响 - 构造函数调用链：指子类构造函数中显式调用父类构造函数（如
Parent.call(this)或super()），再由父类继续调用更上层构造函数所形成的同步调用序列；每次调用都压入一个栈帧
真正卡住你的，是调用栈溢出
当你写这样的多层继承时：
class A extends B {}
class B extends C {}
class C extends D {}
// ……一直写到 Z
new A()
看似只是“定义”，但真正执行 new A() 时，V8 会按顺序触发 Z.constructor → Y.constructor → … → A.constructor 的同步调用。这个链条一旦过深，就会触发：
RangeError: Maximum call stack size exceeded
各引擎安全深度参考（实测值，非固定）：
- Chrome（V8）：约 13,500 层内较稳妥，但参数多、闭包大时可能跌破 10,000
- Firefox（SpiderMonkey）：通常 4,000–7,000 层即告警
- Safari（JavaScriptCore）：最宽松，可达 20,000–25,000 层
- Node.js：默认约 8,000–12,000 层，可用
--stack-size=16384扩展，但不解决设计问题
实际开发中几乎不会触达这个上限
因为没人会写 100 层 class 继承。真正容易出问题的是：
-
构造函数内部又递归调用自身（比如错误地在
constructor里 new this.constructor()） - 多个类互相在 constructor 中调用对方（循环构造依赖）
- 构造函数里执行了深层嵌套的初始化逻辑（如加载树形结构并逐节点 new 子实例）
这些场景下，哪怕只有 10 层继承，也可能因每层再展开 100 次调用，迅速耗尽栈空间。
如何规避风险
不靠“数层数”，而靠控制执行流：
- 避免在 constructor 中做重操作或递归；把初始化逻辑移到独立方法中，按需调用
- 对可能深度嵌套的创建行为（如解析 JSON 树、构建 UI 组件树），加显式深度守卫（例如传入
depth = 0，超 50 层就报错或降级） - 用迭代替代递归创建：把待构造对象存进数组，用
while循环 + 栈模拟逐个处理 - 必要时用微任务切片（
queueMicrotask）释放栈帧，让每层创建异步推进
