可以继承Array但存在关键限制：语法合法且原生行为基本保留，但map/filter等返回新数组的方法会丢失子类类型，需手动重写构造器调用；而Error子类则稳定可用。
可以，但存在关键限制，实际项目中通常不建议直接继承 Array 这类内置对象。
语法合法，运行时也支持
ES6 规范明确将 Array、Error、Date、RegExp 等设计为可子类化（subclassable）。例如：
-
class MyArray extends Array {}是完全合法的语法； -
new MyArray(1, 2)能正常创建实例； -
Array.isArray(new MyArray())返回true； - 原生行为基本保留：length 自动更新、支持
for...of、展开运算符、push/pop等都可用。
核心问题：返回新数组的方法丢失子类类型
几乎所有生成新数组的原生方法（map、filter、slice、concat、flatMap）内部调用的是 Array 构造器，而非当前子类构造器。结果是：
-
new MyArray(1, 2, 3).map(x => x * 2)返回普通Array，不是MyArray； - 子类上定义的自定义属性（如
this.meta = { version: 1 }）全部丢失； - 扩展的方法（如
toJSONSafe()）无法在返回值上调用。
修复代价高，组合更实用
若坚持继承，需手动重写所有“返回新数组”的方法，确保使用 new this.constructor(...)：
立即学习“Java免费学习笔记（深入）”；
-
map中不能写return super.map(...)，而要写return new this.constructor(result)； - 静态方法如
Array.from也要覆盖，否则仍返回原生Array； - 某些边界情况（如
JSON.parse的 reviver、Web API 返回的数组）无法拦截，修补难全覆盖。
相比之下，封装一个私有数组并代理行为（组合模式）更可控、安全、易维护。
Error 是例外：推荐继承
与 Array 不同，Error 子类行为稳定：
- 抛出后被
catch捕获的对象仍是子类实例； - 自定义属性（如
this.code = 'VALIDATION_ERROR'）完整保留； - 无需重写任何方法，开箱即用。
