继承Array会导致map、filter等方法返回原生Array而非子类实例，丢失自定义属性和方法；虽支持push/pop/for...of等语义，但构造行为不一致且难以完全修复，推荐优先使用组合模式。
直接继承 Array 在 JavaScript 中看似能复用原生数组方法和行为，但实际存在隐性陷阱。核心问题在于：ES6 的 class SubArray extends Array 虽语法合法，但部分原生方法（如 map、filter、slice）返回的是真实 Array 实例，而非你的子类实例——这会丢失自定义属性和方法。
继承 Array 的主要优势
✅ 保留大部分数组语义和原型链能力：
- 支持 push、pop、length 自动更新、for...of 遍历、展开运算符等；
- 可以重写或增强原生方法（如在 push 中添加校验逻辑）；
- 类型检测较友好：Array.isArray(new MyArray()) === true，且 instanceof MyArray 也成立。
不可忽视的关键缺陷
❌ 原生高阶方法不保留子类构造器：
- new MyArray(1,2).map(x => x * 2) 返回普通 Array，不是 MyArray；
- 同样适用于 filter、slice、concat、解构赋值后的结果等；
- 导致自定义字段（如 this.meta）、扩展方法（如 .toJSONSafe()）全部丢失。
❌ 构造行为不一致：
- new MyArray() 和 MyArray.of() 行为可控，但 Array.from(iterable) 默认返回 Array，需手动传入 MyArray 作为 map 的 thisArg 或重写静态方法；
- 子类无法拦截 Array 内部的创建逻辑（如 map 内部调用 Array 构造器），除非重写整个方法。
更稳妥的替代方案
? 组合优于继承：
- 定义一个普通类，内部持有一个私有 Array 实例（如 #data = []）；
- 显式代理关键方法（push、at、map 等），并在 map/filter 中返回新实例（return new ThisClass(result)）；
- 完全掌控返回类型，可自由扩展元数据、响应式逻辑、序列化策略等。
? 若必须继承，需主动修复“构造器丢失”问题：
- 重写所有会新建数组的方法（map、filter、slice 等），确保返回 new.target 或 this.constructor 实例；
- 在构造器中检查 new.target，必要时调整 this（需配合 Reflect.construct）；
- 注意：V8 引擎对这类重写可能有性能开销，且难以 100% 覆盖所有边界场景（如某些内置 API 的间接调用）。
实际选型建议
? 仅需轻量扩展（如带默认校验的数组）→ 优先用组合 + 代理模式，清晰可控；
? 需要深度融入数组生态（如被第三方库当作真数组使用）→ 可尝试继承，但必须重写关键派生方法，并充分测试；
? 涉及高频计算或性能敏感场景 → 避免继承，组合 + TypedArray 或普通数组 + 工具函数更高效；
? TypeScript 用户注意：类型系统无法约束运行时构造器行为，map 返回类型声明为子类 ≠ 实际返回子类实例。
