避免合并复杂配置对象时忽略原型链造成继承丢失

在 JavaScript 开发中，你可能会遇到这样的困扰：辛苦合并了两个配置对象，结果对象里的方法却无法调用，默认值也莫名消失。其实问题并不在于“继承被删除了”，而是合并过程绕过了原型链——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/TypeScript 输出可能无意中修改原型

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

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