.NET 跨平台原理与实现

二十多年前，.NET 为 Windows 而诞生—— CLR、Winform、IIS，样样都和 Windows 深度绑定。今天，一个 .NET 应用可以毫无违和感地跑在 Ubuntu 容器、macOS 笔记本，甚至树莓派上。这篇文章简单介绍一下.NET跨平台的核心原理，以及微软为了“跨平台”对 .NET 做了哪些改造。

一、核心原理：IL 中间语言 + 平台适配层

.NET 跨平台的底层逻辑：不要让应用代码直接对话操作系统，中间垫一层"翻译官"。

具体拆开看是两层隔离：

1. 语言层隔离：C#/F#/VB 代码不会直接编译成某个 CPU 架构的机器码，而是先编译成 CIL（Common Intermediate Language，公共中间语言），配合元数据一起打包进程序集（DLL/EXE）。这一步和源代码用什么语言写、要跑在什么系统上完全无关。
2. 运行时层隔离：真正把 IL 变成机器码、并且和操作系统打交道（分配内存、创建线程、读写文件、收发网络包）的工作，交给 CoreCLR 这个运行时来做。CoreCLR 内部再通过一层 PAL（Platform Adaptation Layer，平台适配层），把"和 OS 打交道"这件事彻底封装掉。

.NET 程序的运行逻辑：

App(IL)  →  BCL(基础类库)  →  CoreCLR/CLR(JIT + GC + 类型系统)  →  PAL(平台适配层)  →  OS

跨平台架构

几个关键角色：

• BCL（Base Class Library）：System.IO、System.Threading、System.Net 等等，这是应用代码实际调用的 API 平面。BCL 内部会调用 CoreCLR 提供的运行时服务，但对外暴露的是统一、与操作系统无关的接口——这是"屏蔽平台差异"的第一道墙。
• JIT（RyuJIT）：在程序运行时，把 IL 即时编译成当前 CPU 架构（x64/Arm64/...）能直接执行的本机指令。同一份 IL，在 x64 机器上编译出 x64 指令，在 Arm64 机器上编译出 Arm64 指令——这就是"一次编译，到处运行"的字面含义。
• GC（垃圾回收器）：内存管理逻辑本身是平台无关的算法（分代回收），但底层申请/释放虚拟内存的系统调用因平台而异，这部分同样依赖 PAL。
• PAL（Platform Adaptation Layer）：这是最容易被忽略、但确实存在且至关重要的一层。它给 CoreCLR 提供一组"看起来像 Win32 API，实现上因平台而异"的函数集合——线程同步、异常处理（SEH 语义）、文件系统、网络 socket 等等。有意思的是，这不是 .NET Core 发明的新东西，早在 Silverlight 时代的 CoreCLR（对，历史上也叫这个名字）为了让 Silverlight 跑在 Mac 上，就已经设计过一版 PAL，其经验又进一步继承自更早的共享源码 CLI 项目（SSCLI/Rotor）。今天 dotnet/runtime 仓库里 src/coreclr/pal 目录下，Unix-like 系统上的 PAL 实现负责把这些"类 Win32"调用翻译成 pthreads、epoll/kqueue 之类的原生系统调用。

一句话总结：BCL 负责让"上层 API 长得一样"，PAL 负责让"底层实现能落地"，JIT 负责让"同一份中间码能变成不同 CPU 能听懂的指令"。三者叠在一起，才是 .NET 跨平台的完整拼图。

二、三种发布方式：怎么选？

.NET 应用最终交付给用户/服务器时，有三种打包策略，本质区别在于"运行时放哪儿、要不要提前编译成本机码"。

1. 依赖框架发布（Framework-Dependent Deployment, FDE）

只发布应用自身的 IL 程序集，运行时依赖目标机器上已安装的共享 .NET Runtime。就是用这种方式做成来的程序，如果想要在电脑上执行，你就必须首先在你电脑(Windows, Linux或者MacOS)上从微软的官网下载并安装.NET Runtime。

dotnet publish -c Release -r linux-x64 --self-contained false

• 优点：包体积小；多个应用共享同一份运行时，安全补丁只需升级一次运行时。
• 缺点：目标机器必须预先装好匹配版本的 Runtime，否则起不来。
• 典型场景：企业内部服务器、Kubernetes 里统一维护的基础镜像、CI/CD 环境本身就受控的场景。

2. 独立部署发布（Self-Contained Deployment, SCD）

把整个 .NET Runtime（含 CoreCLR、BCL）连同应用一起打包，目标机器不需要装任何东西。

dotnet publish -c Release -r win-x64 --self-contained true

• 优点：开箱即用，没有"目标机版本不对"的问题；不同应用可以用不同 Runtime 版本互不干扰。
• 缺点：体积明显变大（通常 60MB 以上）。
• 典型场景：桌面客户端分发给终端用户、给客户交付的私有化部署包、无法保证目标环境一致的场景。

3. Native AOT 发布（Ahead-of-Time Compilation）

.NET 7 开始成熟的发布模式，编译期直接把 IL 编译成目标平台的单一本机可执行文件，运行时不再需要 JIT，只内嵌一个精简过的运行时（GC、最小反射支持等）。

dotnet publish -c Release -r linux-x64 -p:PublishAot=true

• 优点：启动速度接近原生 C/C++ 程序（毫秒级）、内存占用更低、没有 JIT 预热开销。
• 缺点：不支持运行时动态代码生成/大部分反射场景（System.Reflection.Emit 不可用，动态 Type.GetType 受限），一些依赖运行时反射的库（早期版本的某些序列化框架）需要适配。
• 典型场景：命令行工具、Serverless/FaaS 函数（在意冷启动）、边缘计算/IoT 设备、对启动时间极度敏感的微服务。

怎么选？一个简单的判断顺序

1. 目标环境是否已经统一维护好 Runtime（比如公司自建的 K8s 基础镜像）？→ 选 FDE，省体积、好升级。
2. 目标环境不受你控制，或者要分发给不确定环境的最终用户？→ 选 SCD，图省心。
3. 应用是 CLI 工具/云函数/对启动延迟极度敏感，并且没有用到运行时反射黑魔法？→ 选 Native AOT，榨干性能。

三者不是互斥的，很多团队会用 SCD 兜底通用场景，同时给性能敏感的边缘服务单独做一版 AOT。

三、微软做了哪些工作，才让"跨平台"从口号变成现实

早期的 .NET Framework 本质上是"Windows 的一部分"，跟 Win32、注册表、GDI+ 这些东西是长在一起的。真正意义上的跨平台，是靠一系列结构性重写完成的，远不止你列的三项，这里补充完整一点：

1. 解耦 Windows 依赖：重写 BCL、引入 .NET Standard

.NET Framework 的 BCL 里有大量假设自己运行在 Windows 上的代码（比如直接调用 Windows 注册表、依赖 GDI 做图形）。.NET Core 时代对 BCL 做了近乎重写：抽掉所有 Windows 专属实现，把平台差异下沉到 PAL / 各平台专属的 Native 库（System.Native、System.Security.Cryptography.Native 等）里。

.NET Standard 则是在 .NET Framework、.NET Core、Xamarin、Mono 生态并存的过渡期，用来解决"类库要不要跨平台"的规范问题——它定义了一套所有 .NET 实现都必须支持的 API 集合，类库作者只要面向 .NET Standard 编译，就能同时被 Framework 和 Core 引用。到 .NET 5 之后，随着各实现统一到一条主线，.NET Standard 的历史使命基本完成，现在推荐直接面向 net8.0/net9.0 这样的 TFM 开发。

2. 服务端解耦：从 IIS 到 Kestrel

.NET Framework 时代，ASP.NET 网站几乎离不开 IIS——请求管道、模块（HttpModule/HttpHandler）都是 IIS 概念的延伸，天然是 Windows-only。ASP.NET Core 引入了完全托管、跨平台的内置 Web 服务器 Kestrel，基于 libuv（早期）/后来切换到自研的跨平台 Socket 传输层，本身不依赖任何 Windows 特有组件。IIS/Nginx 这类服务器，现在的角色降级为反向代理（可选），而不是运行时的必需品。

3. 工具链解耦：开源并重构 CLI 与 MSBuild

.NET Framework 时代离开 Visual Studio 几乎无法构建项目（.csproj 格式冗长、依赖 VS 生成的 GUID 和大量隐式约定）。微软重写了 dotnet CLI（dotnet build/dotnet run/dotnet publish 等命令），并把 MSBuild 本身开源、跨平台化，配合 SDK 风格的精简 .csproj（几行就能描述一个项目），使得整个构建链路可以在纯命令行、任意编辑器（VS Code、Rider、Vim）下完成，彻底摆脱对 Visual Studio GUI 的依赖。

4. 开源 CoreCLR、CoreFX，社区共建

2014-2015 年前后，微软把整个 .NET Core 运行时（CoreCLR）、基础类库（CoreFX）、编译器（Roslyn）陆续开源到 GitHub，并接受社区 PR。这一步在工程层面看似"只是开源"，实际意义重大：Linux/macOS 上的适配工作（PAL 的完善、各种 Native 库的移植）很大程度上是社区和微软工程师一起在 GitHub 上磨出来的，而不是微软内部闭门造出来再空投。

5. 包管理与依赖体系统一：NuGet + SDK 风格项目

配合工具链重写，NuGet 包管理也做了对应升级，跨平台的包还原、PackageReference 取代旧的 packages.config，让同一个项目文件在 Windows/Linux/macOS 上用同一套命令就能还原依赖、构建、发布，不再依赖 Windows 特有的路径约定。

6. 容器与云原生第一等公民

微软官方持续维护跨发行版的 Docker 基础镜像（Debian/Alpine/Ubuntu 变体），并持续压缩镜像体积、优化容器内 GC 行为（比如识别 cgroup 内存限制自动调整堆大小）。这一步严格说不算"跨平台原理"，但从工程实践角度看，是让 .NET 真正被云原生生态接纳的关键推动力——没有这些优化，"能跑在 Linux 上"和"适合被大规模运维"完全是两回事。

7. Mono/Xamarin 并入主线，实现移动端与 WASM 覆盖

.NET 6 把原本独立发展的 Mono 运行时并入统一的 .NET 主线，使得同一套 BCL 之上可以有两种运行时后端：CoreCLR（服务器/桌面）和 Mono（移动端 iOS/Android、浏览器 WASM、体积敏感场景）。这一步补上了 CoreCLR 天然覆盖不到的领域——浏览器内和移动设备。

四、跟 Java 比一比：相似的外壳，不同的骨架

.NET 和 Java 在"跨平台怎么做"这个问题上，答案表面上高度相似，都是"中间语言 + 托管运行时"的路数。放在一起看：

相同点

• 都是"源码 → 中间字节码 → 托管运行时即时编译成本机码"的架构。
• 都提供了跨平台的基础类库，把文件、网络、线程这些系统调用统一封装。
• 都在往"提前编译（AOT）"方向发展：.NET 有 Native AOT，Java 生态有 GraalVM Native Image，思路一致——用启动速度和体积换取牺牲部分动态特性（反射、动态类加载）。

本质区别

似乎又没什么“本质上”的区别，但可以从历史起点和生态治理模式这点看一下：

• Java 从第一天起就是为跨平台而设计的（Sun 在 1995 年喊出"一次编写，到处运行"时就是给企业级、多平台部署场景准备的），JVM 规范本身是开放标准，多家厂商（IBM、Oracle、Azul、Amazon Corretto）都能各自实现兼容的 JVM，形成了充分竞争的生态。
• .NET 是"半路出家"补的跨平台。.NET Framework 前十几年就是 Windows 专属技术栈，跨平台是 2014 年之后靠一次近乎从零重写的工程项目（.NET Core）才补上的。
• 治理模式上，Java 的跨平台能力靠多厂商实现同一规范保证（哪怕 Oracle 不干了，还有一堆 OpenJDK 发行版），.NET 的跨平台能力目前高度依赖微软一家公司主导的单一实现（dotnet/runtime），虽然开源、社区可以贡献，但架构决策权集中。

应用侧重领域的差异

• Java 长期是大型企业级后端、金融交易系统、Android 生态（虽然 Android 现在主要用 Kotlin/ART，但语法和生态血脉同源）的主力，胜在生态成熟度和"哪里都能跑"的确定性，超大规模分布式系统（Hadoop、Kafka、Spark 等大数据基础设施几乎全是 JVM 系）里占绝对主导。
• .NET 近几年的发力点更偏向：Windows 桌面/企业应用的存量优势 + 现代化后的高性能 Web API（ASP.NET Core 在各类 Web 框架性能榜单里长期名列前茅）+ 游戏（Unity 用 C#/Mono）+ 借助 Native AOT 切入的云原生/Serverless 场景。换句话说，.NET 在"新战场"（云原生、极致性能、跨端 MAUI）上更激进，Java 在"存量战场"（企业系统、大数据基础设施）上更稳固。

小结

.NET 的跨平台不是一句"支持 Linux 了"就能实现的营销话术，而是从 BCL 重写、PAL 抽象、JIT/AOT 双引擎，到工具链开源、服务端组件解耦这一整套系统工程堆出来的结果。

参考

• Introduction to .NET: https://learn.microsoft.com/en-us/dotnet/core/introduction