现代项目应优先使用 es 模块而非命名空间；模块具独立作用域、显式依赖与优化能力，命名空间仅适用于 .d.ts 类型声明或旧版脚本兼容。
在 TypeScript 中，命名空间（namespace）和模块（ES Module）是两种不同年代、不同设计目标的代码组织方式。现代项目应优先使用模块，命名空间仅用于特定场景，比如类型声明文件（.d.ts）或兼容旧库。
模块：现代标准，推荐首选
只要文件中包含顶层 import 或 export，TypeScript 就将其视为一个模块。模块天然拥有独立作用域，不会污染全局环境。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
导出方式灵活：支持具名导出（
export const a = 1）、默认导出（export default class X）、重命名导出（export { foo as bar }） -
导入方式明确：可按需导入（
import { clamp } from "./math"）、全部导入（import * as math from "./math"）、甚至动态导入（const m = await import("./lazy")） -
依赖关系清晰：每个
import都显式声明了依赖，便于打包工具分析和 tree-shaking
命名空间：已过时，慎用
命名空间本质是编译后生成的 IIFE（立即执行函数），最终挂载到全局对象上。它不解决依赖管理，只做简单的逻辑分组。
-
适用场景有限：主要用于
.d.ts文件中为 JS 库补充类型定义，或维护极老的纯前端脚本项目（多个<script></script>标签拼接） -
嵌套可用但不推荐：如
namespace MyApp.Utils编译后变成MyApp.Utils = {}，但会加深全局污染层级 -
跨文件需手动合并：用
/// <reference path="file.ts"></reference>声明依赖，且必须配合--outFile才能正确合并，与现代构建流程脱节
关键区别：作用域与工程实践
模块内所有顶层声明默认私有；命名空间内成员默认全局可见（除非不加 export）。这意味着：
- 写一个模块文件，哪怕没写
export，也不会影响其他文件 - 写一个命名空间文件，若漏写
export却误用了内部变量，可能引发隐蔽冲突 - 模块支持树摇、懒加载、循环依赖检测；命名空间无法参与这些优化
实际建议：一条清晰路线
- 新项目一律用 ES Module（
import/export），配置module: "ES2020"或更高，moduleResolution: "bundler" - 遇到第三方库只有命名空间类型（如
jQuery的$全局对象），直接在declare global或.d.ts中用namespace $补充类型，不自己写运行时命名空间 - 已有命名空间代码需迁移时，逐文件添加
export并改用import替代全局引用，而非混合使用
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
