先记住这个答案
模块增强是在外部模块语境中，用 declare module 指向可解析的已有模块，再对其中可合并的声明补充成员。常见做法是在补丁 .d.ts 顶层导入原模块，确保原声明被加载，然后扩展一个具名接口。它不同于重新定义无类型包的环境模块，也不能任意改变已有属性类型、直接合并类型别名或凭空安装运行时功能。补充字段必须有实际库行为依据；若新增的是插件方法，还需要真实插件代码被加载，类型增强本身不会执行方法挂载。
- 先加载并定位已有声明，再补充可合并成员
- 已有属性的类型和修饰要求不能随意改写
- 类型补丁要跟随运行库版本验证并及时清理
补丁文件要保留已有模块的类型入口
如果只在脚本式 .d.ts 中重写 declare module，可能建立新的环境模块声明，使消费者看到的契约不再是原库完整导出。顶层 import 表明这是面向已有模块的补丁，也让 TypeScript 有机会找到要合并的原接口。
示例给请求选项加一个可选超时字段，原有 path 等成员应继续存在，其他函数导出也不应消失。可选字段意味着旧调用仍能满足契约；真实代码如何处理省略、零值和超时单位，仍要与库实现保持一致。
// types/tiny-client-patch.d.ts
import 'tiny-client';
declare module 'tiny-client' {
interface RequestOptions {
timeoutMs?: number;
}
}该文件被编译程序读取后，消费者会看到原 RequestOptions 加上 timeoutMs。因为这是 .d.ts，顶层导入也不会为应用生成运行时加载代码；如果需要插件初始化，应在实现入口另外执行。
不是所有类型都能按接口方式合并
接口可以按声明合并规则增加兼容成员，但已有同名属性不能随意从字符串改成数字，必填和可选修饰也需要一致。类型别名不是开放接口，重复声明同名别名通常会冲突；这时应考虑包装类型或推动上游修复。
模块增强针对可命名的已有导出，不能把默认导出当作普通接口名直接补丁。模块说明符还要解析到真正声明所在位置，包根入口的转导出与内部子路径可能需要仔细核对。仅仅在编辑器里搜到相同名字，不证明增强命中了正确符号。
类型增强不会让运行时自动具备能力
如果补的是库已支持但声明遗漏的选项，验证应包含真实运行库是否读取该字段。若补的是插件挂到原型上的方法，则要同时确保插件加载顺序和初始化范围正确。只扩展接口后调用不存在的方法，仍然会在运行时抛错。
补丁应记录适用库版本和原因，并在升级后检查上游是否已经修复。原库后来增加不同类型的同名字段时，本地补丁可能冲突；开启 skipLibCheck 让声明错误不显示，不等于两份契约已经兼容，应及时合并或删除过期补丁。
容易答错的地方
- 模块增强可以把原属性重新定义成任意类型
- 声明合并要求同名成员兼容，增强不是覆盖配置。真正需要不同输入时可设计包装接口与适配函数，不能强行改写库的既有承诺。
- 增强 .d.ts 中 import 插件就会初始化运行时
- 声明输入不会生成应用加载逻辑，类型引用与执行依赖是两回事；真实插件初始化应出现在运行的实现模块里并验证加载顺序。
面试官还会怎么问？
给 type 别名增加字段应该怎么办？
可以在自己的边界定义交叉或映射后的包装类型，再通过实际适配使用；不要重复声明同名别名来模仿接口合并，也别承诺库支持未实现字段。
原库已经修复类型后还保留补丁吗？
应先核对新声明是否覆盖原需求，再移除冗余补丁并运行消费测试。长期保留相同字段会增加升级冲突，也让维护者难以判断真实来源。
增强文件必须由每个消费者显式导入吗？
不一定，关键是它进入同一个类型程序，可以通过项目输入或包类型入口纳入。但运行时插件仍有单独加载要求，不能混为一谈。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。