.NET 是一套“语言运行平台 统一类型系统 通用中间语言 托管运行时 基础类库 SDK/构建工具 应用框架”的完整软件开发平台。Microsoft 官方将 .NET 定义为免费、开源、跨平台的开发平台可用于构建桌面、Web、云服务、移动端等多种形态的应用。其底层运行模型并非私有黑盒核心部分由ECMA-335《Common Language InfrastructureCLI》正式标准化包括通用中间语言、元数据格式、类型系统、虚拟执行系统等核心规范。一、概念理解 .NET 的第一步是厘清常被混淆的一组术语。概念本质定位C#高级编程语言开发者编写业务逻辑使用的语言.NET完整软件开发平台承载 C#/F#/VB 等语言的开发与运行环境CLIECMA 国际标准定义“通用语言基础设施”应当具备的能力与规范CLRCommon Language Runtime.NET 的托管运行时是 CLI 标准的具体实现CIL / ILCommon Intermediate Language与 CPU 架构无关的通用中间指令集CTSCommon Type System.NET 统一类型系统定义类型的规则与结构CLSCommon Language Specification不同 .NET 语言之间互操作的公共规则子集BCLBase Class Library.NET 平台提供的基础类库SDKSoftware Development Kit包含编译器、构建工具、运行时的完整开发工具包Runtime运行时环境负责加载与执行托管程序的最小环境其中最容易混淆的是CLI 与 CLRECMA-335 CLI 是标准与规范定义了通用语言虚拟机应当遵循的规则CLR / CoreCLR / Mono 是具体实现在不同场景下承载程序的实际执行。可以类比为ECMA-335 CLI 标准 ↓ CLR / CoreCLR / Mono 实现 ↓ 程序真正运行在现代统一 .NET 平台中CoreCLR 主要服务于云、服务器与桌面场景Mono 运行时则在移动端、WebAssembly 等场景继续发挥作用二者同属 .NET 生态体系。二、托管执行模型程序从源码到 CPU 的链路C# 不是编译成 exe 就直接跑在 CPU 上。默认的托管执行模型是一条清晰的多级编译链路C# / F# / VB 源码 ↓ 语言编译器 CIL 指令 元数据 ↓ 打包 程序集 Assembly (.dll / .exe) ↓ CLR 加载 程序集加载器 → 类型加载器 ↓ JIT 编译 目标架构本机代码 (x86-64 / ARM64) ↓ 操作系统 CPU语言编译器首先将源代码翻译为通用中间语言CIL并生成配套元数据程序执行时再由运行时的 JIT 编译器将 CIL 翻译为对应 CPU 架构的本机代码并执行。什么是 CILCILCommon Intermediate Language早期也称 MSIL是一种与具体 CPU 指令集无关的虚拟机指令集。例如一段简单的加法intcab;在 CIL 层面被表达为ldloc.0 // 加载局部变量 a ldloc.1 // 加载局部变量 b add // 执行加法 stloc.2 // 保存结果到局部变量 c它既不是高级语言语法也不是 x86/ARM 的机器指令而是处于二者之间的中间表示。ECMA-335 标准完整定义了 CIL 的指令集、类型系统编码与元数据格式。三、程序集与元数据反射能力的底层来源一个典型的静态程序集包含四部分程序集清单Manifest记录程序集的身份、版本、依赖关系、文件列表类型元数据Type Metadata描述程序集中所有类型的定义、成员签名、引用的外部类型CIL 代码方法的中间语言指令资源位图、字符串表、配置文件等嵌入资源。Microsoft 官方将 Assembly 定义为 .NET 中部署、版本控制、重用、作用域与安全权限的基本单元运行时通过元数据感知类型的完整实现。元数据的价值CLR 为了实现托管执行与类型安全必须在运行时掌握完整的类型信息。CoreCLR 类型加载器设计文档明确指出运行时必须能够随时确定任意对象的类型且类型查询必须足够高效不能依赖字典查找等慢速路径。这套机制也直接支撑了运行时反射与动态代码生成序列化与反序列化依赖注入容器ORM 框架的对象关系映射Attribute 元数据编程插件化与动态程序集加载运行时泛型实例化四、CLR 子系统可以把 CLR 看作托管程序与操作系统/CPU 之间的一层大型运行系统其核心由多个子系统协同构成。 CLR 公共语言运行时 其他核心服务异常系统SEH托管线程管理ThreadPool程序集加载互操作P/Invoke元数据访问 类型系统值类型引用类型继承接口字段方法属性泛型特性⚡ JIT 编译器IL验证安全校验编译IL→本机优化内联/边界异常子句EH♻️ 垃圾回收器分代回收Gen 0/1/2标记压缩复制终结器队列大对象堆LOH后台并发回收4.1 JIT 编译器从快速启动到深度优化JITJust-In-Time Compiler负责在运行时将 CIL 翻译为目标 CPU 的本机指令。现代 CoreCLR 的主力 JIT 编译器名为RyuJIT支持 x86-64、ARM64 等多种架构具备完整的 SSA 优化、值编号、线性扫描寄存器分配等能力。经典 JIT 模型面临一个根本矛盾编译越充分代码质量越高但启动越慢编译越简单启动越快但长期运行性能越差。现代 .NET 通过分层编译Tiered Compilation解决这一矛盾Tier 0方法首次调用时使用 Quick JIT 快速生成代码或直接加载 ReadyToRun 预编译映像优先保证启动速度Tier 1运行时检测到高频调用的方法后在后台线程重新进行完整优化编译替换原有代码。.NET Core 3.0 之后分层编译默认开启通过“冷代码快启、热代码深优”的策略平衡启动性能与峰值性能。在此基础上动态 PGOProfile-Guided Optimization还会基于 Tier 0 的运行时剖面数据进一步指导 Tier 1 的优化方向。4.2 垃圾回收自动内存管理的实现.NET 采用自动垃圾回收机制开发者通常不需要手动释放托管内存。GC 的核心逻辑并不是“变量出作用域就立即释放”而是基于可达性分析。GC 根与可达性GC 从一组被称为GC Roots的根对象出发遍历所有引用关系构建对象可达图线程栈上的局部变量与参数静态字段CPU 寄存器中持有的对象引用GC 句柄表终结队列能够被 Roots 直接或间接到达的对象标记为“存活”不可达的对象则被判定为垃圾并回收内存。分代回收基于“绝大多数对象生命周期很短”的经验假设.NET GC 采用分代回收策略第 0 代Gen 0年轻代新分配的对象默认在此回收频率最高、速度最快第 1 代Gen 1缓冲代存活过一次 Gen 0 GC 的对象晋升至此第 2 代Gen 2老年代存放长期存活对象回收频率最低、开销最大。大小 ≥ 85000 字节的大型对象直接进入大型对象堆LOH逻辑上属于 Gen 2默认不会被压缩以避免移动大对象的性能开销。GC 的边界需要特别注意GC 只负责托管内存的管理。对于文件句柄、套接字、数据库连接、非托管内存、原生 SDK 对象等非托管资源GC 无法确定性地自动释放。为此 .NET 提供了IDisposable接口与标准 Dispose 模式用于确定性释放非托管资源。官方文档明确指出GC 不分配也不释放非托管内存Dispose 模式专门用于处理文件句柄、系统句柄、非托管指针等资源的清理。4.3 类型加载器类型加载器Type Loader负责根据元数据构建运行时类型结构其核心数据结构包括MethodTable每个类型对应一个方法表存放虚函数表、基类信息、接口列表、字段布局等“热”数据EEClass存放类型加载、JIT 编译、反射所需的“冷”数据多个泛型实例化可以共享同一个 EEClass 以节省内存。为了解决循环依赖等问题类型加载采用分级加载Load Levels机制类型结构逐步构建完成避免了原子性加载带来的死锁与无限递归。五、跨语言互操作的基石CTS 与 CLS.NET 与单语言运行时最本质的区别之一是从设计之初就支持多语言统一运行。这一能力建立在 CTS 与 CLS 两层规范之上。5.1 通用类型系统 CTSCTSCommon Type System定义了 .NET 世界中类型的完整规则所有类型分为值类型与引用类型两大类统一规定了类、结构、枚举、接口、委托五种类型范畴定义了类型的成员、继承、可见性、泛型等规则。无论你用 C# 的int、VB 的Integer还是 F# 的int在运行时都对应同一个类型System.Int32。这就是不同 .NET 语言能够无缝共享类型、互相调用库的根本原因。5.2 公共语言规范 CLSCTS 的规则非常完整但不同编程语言未必支持 CTS 的全部特性。例如有些语言不支持无符号整数有些语言不区分大小写。为此 .NET 定义了CLSCommon Language Specification它是 CTS 的一个子集规定了所有 .NET 语言都应当共同支持的一组规则。如果类库的公开接口遵循 CLS 规范那么它可以被所有支持 CLS 的语言无障碍使用。三者的关系可以总结为CLI整个运行平台标准 │ ┌─────────┴─────────┐ │ │ CTS CIL 类型系统 指令集 │ ↓ CLS 跨语言公开接口规则子集六、基础类库 BCL平台能力的载体如果只有 CLR 虚拟机.NET 只能运行 IL 代码无法完成任何实际业务。.NET 同时提供了庞大的基础类库Base Class Library覆盖基础类型与文本处理集合与数据结构文件与流 IO网络通信与 HTTP线程、任务与同步原语反射与动态编程加密与安全进程与环境交互这里需要特别区分语言特性与平台能力async/await属于C# 语言特性由编译器生成状态机Task、CancellationToken、SemaphoreSlim属于.NET 平台 API由运行时与类库提供实现。语言负责表达能力平台负责提供运行机制与基础设施。七、生态脉络.NET Framework、.NET Core 与现代 .NET7.1 三条技术线的定位.NET Framework2002 年诞生Windows 专属技术体系包含 WinForms、WPF、ASP.NET Web Forms、WCF 等传统 Windows 技术.NET Core2016 年发布完全开源、跨平台的全新实现面向云与跨平台桌面场景现代 .NET从 .NET 5 开始.NET Core 去掉“Core”后缀成为统一品牌每年 11 月发布一个大版本。注意不是“.NET Framework 4.8 升级到了 .NET 5”而是两条技术线并行发展后新的统一平台以 .NET Core 代码库为主体向前演进。7.2 当前支持状态.NET Framework4.8.1 是该产品线的最新版本。从 4.5.2 开始.NET Framework 被定义为 Windows 操作系统的组件其支持生命周期跟随所在 Windows 系统的生命周期。现代 .NET采用每年一发的节奏偶数版本为 LTS长期支持奇数版本为 STS标准支持。根据官方 2026 年最新支持政策.NET 8LTS支持至 2026 年 11 月 10 日.NET 9STS支持周期已延长至 24 个月同样至 2026 年 11 月 10 日.NET 10LTS2025 年 11 月发布支持至 2028 年 11 月 14 日八、标准化与兼容性.NET Standard 的定位.NET Standard 是一份 API 规范。它的作用可以理解为一份契约只要某个 .NET 实现声明支持某个版本的 .NET Standard它就必须提供该版本规定的全部 API。这样面向 .NET Standard 编译的类库可以在所有符合该版本的 .NET 实现上运行。几个关键事实.NET Standard 2.0是最后一个同时兼容 .NET Framework 与现代 .NET 的版本也是跨平台类库最常用的目标.NET Standard 2.1不再支持 .NET Framework仅适用于 .NET Core 3.0、Mono 等实现进入 .NET 5 统一时代后不再发布新版本的 .NET Standard。对于不需要兼容 .NET Framework 的新项目直接目标对应版本的 .NET 即可。官方建议如果需要同时支持 .NET Framework 与现代 .NET类库应目标netstandard2.0否则建议直接使用现代 .NET TFM。九、开发与部署SDK、Runtime 与目标框架9.1 目标框架TFM项目文件中的TargetFramework字段使用目标框架名字对象TFM声明程序面向的 API 契约例如net481.NET Framework 4.8.1net10.0.NET 10 跨平台 APInet10.0-windows.NET 10 Windows 专属 API如 WinForms、WPFOS 特定 TFM 继承基础 TFM 的全部 API并额外叠加对应操作系统的专有能力。通过多目标框架与预处理器指令可以编写同时适配多个平台的代码。9.2 SDK 与 Runtime.NET Runtime只包含运行托管程序所需的最小环境用于生产环境或用户终端.NET SDK包含 Runtime、C#/F# 编译器、MSBuild 构建引擎、dotnet 命令行工具等完整开发环境。安装 SDK 时会自动附带对应版本的 Runtime开发机安装 SDK 即可纯运行环境可只安装 Runtime。9.3 部署模型框架依赖部署FDD依赖目标机器上已安装的 .NET Runtime程序包体积小独立部署SCD将运行时与程序一起打包目标机器无需预装 .NETNative AOT编译时直接生成本机可执行文件无运行时依赖启动快、内存占用低但限制反射、动态代码生成等能力。十、执行模型的演进多元编译体系经典 .NET 的“IL JIT”模型仍是主流但现代 .NET 已经演化出多元编译体系适配不同场景需求编译方式时机特点适用场景JIT 编译运行时按需编译可根据当前 CPU 做针对性优化代码质量高长期运行的服务端程序、桌面应用ReadyToRun编译时预生成 运行时补足减少启动阶段 JIT 开销平衡启动与性能中等启动要求的桌面、服务端程序Native AOT编译时完全生成本机代码无运行时依赖启动极快内存占用小云原生函数、命令行工具、短生命周期程序CIL CLR JIT 仍是 .NET 的经典与核心执行模型但现代 .NET 同时提供多种 AOT 编译方式以满足不同场景需求。十一、为什么说 CLR 是“通用语言虚拟机”常有人将 CLR 与 JVM 类比二者确实同为托管虚拟机但设计出发点有显著差异JVM 最初围绕 Java 语言设计而 CLR 从诞生之初就以“多语言共享运行时”为核心目标。通过统一的 CTS、统一的 CIL、统一的元数据格式不同语言编译后都运行在同一个 CLR 上可以互相调用、互相继承、共享异常与泛型。这正是 CLR 名称中Common Language的真正含义——它不是“C# 运行时”而是“通用语言运行时”。总结最后用一张全景图收尾以后遇到任何 .NET 名词都可以对应到体系中的相应位置.NET 平台 │ ┌───────────────┼───────────────┐ │ │ │ 语言层 运行时层 类库层 │ │ │ C# CLR BCL F# ┌────┼────┐ System.IO VB │ │ │ System.Net │ │ │ 线程与任务 JIT GC 加载器 ... │ ├── CTS / CLS ├── 异常系统 ├── 线程调度 ├── 反射机制 └── 互操作服务 │ ↓ 程序集 Assembly CIL 指令 元数据 │ ↓ 本机机器码 │ ↓ 操作系统 CPU而从历史维度看.NET 生态 ├── .NET Framework — Windows 传统体系4.8 / 4.8.1 ├── .NET Core — 跨平台开源体系1.x / 2.x / 3.x └── 现代 .NET — 统一平台5 / 6 / 7 / 8 / 9 / 10 ...