Symbol.isConcatSpreadable 仅在 Array.prototype.concat() 中控制传入参数是否展开，不参与继承，只检查参数对象自身属性，不沿原型链查找。
直接说结论：Symbol.isConcatSpreadable 不是用来“配合继承”的，它只在 Array.prototype.concat() 调用时起作用，且只影响**被传入的参数对象**是否被展开——和类继承链、prototype 链、super 调用完全无关。
为什么 Symbol.isConcatSpreadable 和继承无关
Symbol.isConcatSpreadable 是一个“接收方控制”属性：它只检查你传给 concat() 的那个参数对象自身有没有这个 symbol 属性、值是什么。引擎不会沿着 __proto__ 向上查找，也不会关心这个对象是不是某个类的实例、有没有继承自 Array。
- 即使你写
class MyArray extends Array {}，新实例默认仍继承Symbol.isConcatSpreadable === true（因为Array.prototype上有该属性） - 但如果你手动在实例上设
obj[Symbol.isConcatSpreadable] = false，那就生效；设在父类 prototype 上？无效——concat()只读实例自身属性 - 普通对象哪怕
Object.setPrototypeOf(obj, Array.prototype)，也不自动获得该行为，除非显式赋值
真正有效的设置位置：必须是 concat 参数对象自身
常见错误是试图在基类里统一配置，比如：
class DataCollection extends Array {
constructor(...items) {
super(...items);
// ❌ 错误：这不会影响 concat 行为
this.constructor.prototype[Symbol.isConcatSpreadable] = false;
}
}
正确做法只有两种：
-
对具体实例赋值：
myArr[Symbol.isConcatSpreadable] = false -
对类数组对象赋值：
domList[Symbol.isConcatSpreadable] = true（DOM 集合本身不是 Array 实例，必须手动开启）
注意：不能在构造函数里对 this 赋值后就以为“所有子类实例都继承”，因为 concat() 不查原型，只查参数对象自身的 symbol 属性。
复杂业务中容易踩的坑：多层嵌套 + 动态拼接
典型场景：后端返回结构如 { items: [...], metadata: {...} }，前端封装成 ResponseData 类，并希望 .items 在拼接时不被展开（比如要保留为单个元素）。
- ❌ 错误假设：
ResponseData.prototype[Symbol.isConcatSpreadable] = false→ 无效果，concat()根本不看这个 - ✅ 正确做法：在需要拼接前，临时标记该字段：
response.items[Symbol.isConcatSpreadable] = false - ⚠️ 注意副作用：修改原数组的 symbol 属性会影响后续所有对该数组的
concat()调用，建议用Object.assign([], arr)创建副本再设，或用slice()+ 属性赋值
替代方案更实用：避免污染原始数据
实际项目中，硬改 Symbol.isConcatSpreadable 容易引发隐性耦合。更可控的做法是：
- 用
[...arr1, ...arr2]替代arr1.concat(arr2)，语义清晰且不受 symbol 影响 - 需要“不展开”时，统一包装成单元素数组：
arr1.concat([arr2])，比改 symbol 更直观 - 封装工具函数：
safeConcat(target, ...sources)，内部判断Array.isArray(source)决定是否展开，彻底绕过 symbol 机制
真正关键的点只有一个：这个 symbol 不参与继承体系，它只是一次性、参数级的开关。任何想靠“基类统一配置”来控制它的思路，都会在第一次 concat() 调用时失效。
