Symbol.isConcatSpreadable 仅专用于控制 Array.prototype.concat() 对对象的展开行为，不影响继承链、不参与原型查找，也不作用于扩展运算符或 Array.from()。
直接说结论：Symbol.isConcatSpreadable 不是给“复杂业务继承”用的，它是专为 Array.prototype.concat() 行为定制的开关，作用范围极窄——只影响该方法对某个对象的展开逻辑。强行在类继承链里“利用”它，反而容易掩盖设计问题。
为什么 Symbol.isConcatSpreadable 和类继承关系弱
这个 Symbol 是运行时行为控制符，不是面向对象的设计机制。它不参与原型链查找（除非你显式定义在 prototype 上），也不触发任何生命周期钩子。即使你在基类里设置 [Symbol.isConcatSpreadable] = false，子类实例默认也不会继承该属性——因为它是不可枚举、不可配置、不可写的标准 symbol 属性，必须手动赋值到每个实例或通过 getter 暴露。
- 数组实例默认自带
[Symbol.isConcatSpreadable] === true，但这是引擎内置逻辑，不是从Array.prototype继承来的 - 自定义类若 extends
Array，它的实例默认仍可被concat()展开；想禁用，得在构造函数里或实例上设this[Symbol.isConcatSpreadable] = false - 普通 class（非 extends Array）即使有
length和数字索引，concat()也完全无视它，除非你主动挂上[Symbol.isConcatSpreadable] = true
concat() 调用时到底检查什么
引擎执行 arr.concat(arg) 时，对每个 arg 做三件事：
- 先判断
arg是否为原生数组（内部标识）→ 是则展开 - 否则检查
arg[Symbol.isConcatSpreadable]是否为true→ 是则展开其类数组结构（需含length+ 数字键） - 否则把整个
arg当作单个元素推入结果
注意：arg 是对象时，不会去查它的 __proto__ 或 constructor，只看自身是否拥有该 symbol 属性且值为 true。这意味着：即使你写了 class MyList extends Array，只要没在实例上设 [Symbol.isConcatSpreadable]，它的行为就和普通对象一样——不展开。
真正在业务中该怎么做
别试图靠 Symbol.isConcatSpreadable 实现“继承式合并策略”。它解决不了深层嵌套、类型混合、副作用处理等真实业务问题。更务实的做法是：
- 把合并逻辑收口到明确的方法里，比如
mergeItems(other: Item[] | ItemCollection)，内部用Array.isArray()+Array.from()+ 自定义扁平规则 - 如果必须兼容
concat()，只在极少数需要伪装成数组/类数组的场景下使用该 symbol，例如封装 DOMNodeList并希望它能被concat()展开：const nodeList = document.querySelectorAll('div');<br>nodeList[Symbol.isConcatSpreadable] = true;<br>['header', ...nodeList].concat(['footer']); // 正确展开 - 避免在基类构造函数里统一设
this[Symbol.isConcatSpreadable]，因为子类可能有不同合并语义；按需在具体实例化时决定，比如new ApiResult(data, { flatten: true })
真正容易被忽略的是：这个 symbol 一旦设为 false，连 Array.from() 和扩展运算符 [...arr] 都不受影响——它们走的是 Symbol.iterator 路径。所以别指望它能统一控制所有“展开”行为，它只管 concat 这一个方法。
