合并复杂配置对象时继承丢失，是因为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，失败即告警
