TypeScript的模块化之路：namespace与module的演进
TypeScript自2012年诞生以来，模块化一直是其核心设计之一。随着JavaScript生态的演变，TypeScript的模块化方案也从最初的namespace逐步转向了ES module，这一过程反映了前端工程化的发展趋势。本文将回顾namespace与module的历史背景，分析现状，并探讨它们的优缺点及适用场景。
命名空间的起源与局限
在TypeScript早期，namespace（原名internal modules）是组织代码的主要方式。它通过嵌套的命名空间隔离作用域，避免全局污染，适合浏览器环境下的脚本合并。但随着项目规模扩大，namespace的依赖管理变得笨拙，需手动通过`/// `引入文件，且缺乏静态分析支持。2015年ES6标准发布后，TypeScript迅速拥抱了ES module，namespace逐渐边缘化。
ES module的崛起
ES module凭借静态化、可树摇（tree-shaking）等特性成为现代前端标配。TypeScript通过`import/export`语法与之无缝对接，支持跨文件类型检查与编译优化。与namespace不同，module依赖关系清晰，工具链支持完善，尤其适合配合Webpack、Rollup等构建工具。TypeScript 2.0后，官方推荐使用module替代namespace，除非维护遗留代码。
兼容性与共存现状
尽管module是主流，namespace仍未被废弃。某些场景下，如生成全局类型声明（`.d.ts`）或兼容旧版UMD库，namespace更简单。TypeScript允许两者混用，但需注意编译目标（如`moduleResolution`配置）。部分老项目因历史包袱仍依赖namespace，迁移成本较高。
工程实践中的选择
新项目应优先使用module，利用其模块化优势。若需扩展第三方库类型，可通过`declare module`或namespace合并。对于复杂场景，如微前端共享类型，可结合`paths`别名和模块联邦。TypeScript 5.0后，对ES module的支持更加完善，进一步巩固了module的主导地位。
总结来看，namespace与module的演进映射了前端从脚本化到工程化的转型。理解二者的历史与特性，能帮助开发者更高效地应对不同场景的模块化需求。