类型声明文件在TypeScript中的演进
TypeScript的类型声明文件随着版本迭代和社区发展，经历了从手动管理到标准化命名的过程。早期开发者需要自行下载.d.ts文件并配置，后期通过DefinitelyTyped实现了集中化管理和自动类型获取。
DefinitelyTyped项目的核心作用
谷歌主导的DefinitelyTyped成为JavaScript生态类型定义的中央仓库，采用@types/作为命名空间规范。该项目通过严格的类型定义审核机制，为数千个主流JavaScript库提供高质量的类型支持，显著降低了TypeScript项目的类型维护成本。
@types命名空间的具体实现
通过npm安装的类型包遵循@types/<package-name>格式，例如@types/react。这些包会自动被TypeScript编译器识别，无需额外配置。编译器会根据项目中的import语句自动加载对应的类型定义，实现智能补全和类型检查。
typings的历史定位
在TypeScript 2.0之前，typings作为独立工具管理类型依赖，采用全局安装或项目本地配置的方式。其配置文件typings.json与package.json并存，通过/// <reference path="..." />指令显式引用类型定义。这种模式在现代化项目中已逐渐被淘汰。
类型获取机制的差异比较
@types采用声明式依赖管理，与npm包版本松耦合，允许单独更新类型定义。typings则需要显式声明每个依赖项的版本范围，且存在全局类型污染风险。现代TypeScript项目默认会检查node_modules/@types目录，而typings需要额外的工具链支持。
版本兼容性处理策略
当库作者未提供内置类型时，DefinitelyTyped会维护社区版本。对于同一库的不同版本，@types采用版本后缀标识（如@types/jquery__v3），而typings通过版本号目录区分。TypeScript 4.1+版本增强了类型版本选择能力，可自动匹配库的主版本号。
实际项目中的选用建议
新项目应优先使用@types机制，其类型定义更新更及时。遗留系统若使用typings，建议逐步迁移到@types体系。对于自包含类型定义的库（如Vue 3），应禁用对应的@types包以避免冲突。混合使用时需注意类型解析优先级问题。
构建工具集成差异
webpack等构建工具对@types有原生支持，通过ts-loader或babel-plugin-transform-typescript自动处理类型引用。typings则需要额外配置typings-loader或显式类型导入。Rollup等工具需要@rollup/plugin-typescript插件来正确处理两种类型来源。
类型冲突解决实践
当出现多重类型定义时，可通过compilerOptions.typeRoots指定加载路径。对于全局类型冲突，使用types编译器选项白名单控制加载的范围。模块类型冲突可通过路径映射或patch-package修改类型定义实现版本对齐。