何时使用types.ts与types.d.ts？二者的优劣势分别是什么？

首先需要先澄清一个常见误区：只有没有顶层import/export的全局声明文件.d.ts，里面定义的类型才是全局可用无需导入的；如果.d.ts文件顶层包含导入导出语句，它和普通的.ts文件没有区别，里面的类型也需要导出导入才能使用。

types.d.ts（全局声明模式）的优劣势 #

优势 #

• 通用高频类型全局可用，无需在每个使用的文件中重复导入，减少样板代码，提升开发效率
• 唯一支持全局类型增强的方案，比如给window对象挂载自定义属性、给第三方库扩展内置类型的场景，只能通过全局.d.ts实现
• 可以在不修改JS源码的前提下，为项目中的JS代码补充类型提示，适配JS/TS混合的项目

劣势 #

• 全局命名空间容易出现类型命名冲突，大项目多人协作时如果重复定义同名类型，会出现类型异常，排查成本极高
• 无显式导入逻辑，类型定义来源不清晰，降低代码可维护性
• 如果是对外发布的包，全局类型会污染使用者的全局命名空间，不符合npm包类型规范

types.ts（模块导出模式）的优劣势 #

优势 #

• 所有类型默认属于模块作用域，不会污染全局命名空间，从根本上避免类型命名冲突，更适合大型项目多人协作
• 显式的导入导出逻辑让类型来源清晰可查，可维护性远高于全局类型
• 类型封装灵活性更高，支持按业务域分类聚合类型、二次导出、组合类型等高级用法，适配复杂的类型复用需求
• 符合npm包的类型发布规范，对外发布时不会污染使用者的全局环境，是现在开源库对外导出类型的标准方案

劣势 #

• 所有类型都需要显式导入，高频通用类型会带来一定的样板代码开销
• 不支持全局类型增强，无法覆盖自定义全局属性等场景

开源库的混用逻辑 #

类似material-ui这类大型项目，都会根据场景搭配使用两种方案：全局通用的基础类型、全局类型增强逻辑放在全局.d.ts里提升开发效率，各个业务模块的内部类型、对外发布的类型都采用模块类型方案保证可维护性和规范性，兼顾二者的优势。

内容的提问来源于stack exchange，提问作者ale917k