如何避免在使用合并复杂配置对象时因忽略原型链而造成继承丢失

合并复杂配置对象时继承丢失，是因为Object.assign和展开运算符只复制自身可枚举属性，不处理原型链，导致原型方法和默认配置缺失；正确做法是先创建实例再合并，或手动提取原型属性显式合并。

合并复杂配置对象时，继承丢失不是因为“继承被删了”，而是因为合并操作绕过了原型链——Object.assign、展开运算符（{...a, ...b}）等默认只处理对象自身的可枚举属性，原型上的方法或默认配置根本不会被复制过去。结果是：新对象看似结构完整，实则缺失关键行为或默认值。

别把原型属性当“普通字段”去合并

原型上的配置（比如 BaseConfig.prototype.defaults 或 Service.prototype.timeout）是共享的、动态可维护的。一旦用浅合并覆盖整个对象，这些原型级能力就断连了。

• 错误做法：直接 Object.assign({}, baseConfig, userConfig) → 新对象没有 baseConfig 的原型，defaults 方法调不了
• 正确思路：先创建实例，再用 Object.assign(this, userConfig) 合并到实例自身，保留原型链完整
• 更稳妥：用构造函数或 class 初始化，让原型方法天然可用，配置只负责覆盖实例属性

需要合并原型级配置？显式提取，不依赖自动遍历

如果确实要将原型上的默认配置“拍平”进最终对象（例如生成纯 JSON 配置），必须手动读取，不能指望合并工具自动抓取：

• 查原型：const defaults = Object.getPrototypeOf(baseConfig)?.defaults
• 深拷贝合并：mergeDeep({ ...defaults }, userConfig)，而不是 Object.assign
• 注意：若原型链被切断（如用了 Object.create(null)），Object.getPrototypeOf 返回 null，需提前判断

警惕“干净对象”陷阱：Object.create(null) 不等于安全

有人为避免原型污染用 Object.create(null) 创建配置对象，但这会让对象彻底脱离原型链——没有 toString、hasOwnProperty，也无法继承任何基类方法，后续所有合并、校验、序列化都可能出错。

• 除非明确需要无原型环境（如 Map 替代品），否则不要对配置对象用 Object.create(null)
• 替代方案：用普通对象 + 属性白名单过滤，或使用 Map 存储键值，避免污染风险
• 检查是否已断链：Object.getPrototypeOf(config) === null → 就是人为切断了，得重构初始化逻辑

工具链里埋的雷：Babel/TS 输出可能偷偷改原型

某些旧版编译器会把类转换成带 Object.create(null) 或直接操作 __proto__ 的代码，导致实例原型链异常。这类问题在合并配置前就已存在，但直到调用原型方法时才暴露。

• 验证方式：创建实例后立即执行 Object.getPrototypeOf(inst)，确认它指向预期的原型对象
• 修复不是改合并逻辑，而是升级构建工具、禁用危险插件，或手动补全原型：Object.setPrototypeOf(inst, Constructor.prototype)
• CI 中加检查脚本：对关键配置类实例运行 inst instanceof ExpectedClass，失败即告警