很多现在用 .NET Core 写服务的年轻朋友可能已经不太能理解“跨平台”这件事为什么值得单独写一篇文章。默认不就是dotnet build一下然后丢到 Linux 容器里跑吗但如果你经历过.NET Framework4.x 时代或者曾经被客户要求在 CentOS 上部署一个老 ASP.NET 项目而劝退过就会知道“ .NET Core 跨平台”这几个字背后其实是整个 .NET 生态跟历史遗留包袱打了一场多年的战争。这篇是系列上篇不急着讲 CoreCLR 和依赖注入那些事先聊历史的枷锁为什么当年的 .NET 天生就长在 Windows 上为什么跨平台这么难又是什么力量把它一步步撬开的。适合看这篇的人大概是两类一类是刚接触 .NET Core、想知道“为什么以前不行、现在行”的新人另一类是还在维护老 .NET Framework 项目、想上云或者迁移到 Linux 的开发者。前者能少走弯路后者能看清坑在哪。只要你动手做过一次跨平台迁移对这些历史包袱的体感就会完全不同。1. 从“Windows的唯一答案”说起.NET 的基因里刻着什么1.1 .NET 出生时的定位为 Windows 而生的“下一代开发平台”很多人现在回头看 .NET 1.0容易下意识拿它跟 Java 对比觉得“都是托管运行时为什么 Java 一开始就跨平台.NET 不跨”。这其实是用今天的视角美化历史。2002 年 .NET Framework 1.0 发布时它的定位根本不是“跨平台”而是微软押注 Windows 生态的下一代开发模型。那时候微软的主要对手是 Java 和 Sun 的整套体系微软要做的是把开发者留在 Windows 上让 Windows 成为唯一合适的宿主机。这不是我事后总结出来的而是从 .NET 早期的架构细节里能直接看出来的。CLR 在很大程度上被设计成操作系统的一部分而不是一个独立运行的应用层运行时。.NET Framework 的很多组件是跟着 Windows 补丁一起分发的Windows XP、Vista、7、8、10 都内置了特定版本的 .NET Framework。这种绑定带来的好处是开发者在部署时很省事系统自带就能跑坏处是运行时本身无法脱离操作系统独立进化。尤其到了 Windows 8 时代.NET Framework 4.5 几乎就是 Windows 的一个系统组件你想换版本得看操作系统脸色。更麻烦的是.NET 的整个框架库并不是空中楼阁。BCL 里大量功能的实现直接依赖 Win32 API。比如你写一句File.ReadAllText底层很可能就是一次CreateFile加ReadFileRegistry.GetValue听名字就知道只有 Windows 注册表才有。一个运行时如果能在 Linux 上跑 JIT充其量只是“肌肉”过来了“内脏”还全是 Windows 的。这就是当时所有跨平台尝试面临的第一个结构性障碍框架代码比运行时代码更不平台无关。1.2 组成 .NET 的几根“绑定绳”P/Invoke、COM、WinForms 与 IIS如果只讲“底层调用了 Win32”还是太抽象。具体一点.NET Framework 的跨平台障碍实际上是几个大块头绑在一起的P/Invoke 机制本身不是问题问题在于它调用的大多是 Windows 专属 API。连System.IO、System.Diagnostics.EventLog、System.ServiceProcess这种基础命名空间都长着 Windows 的脸。COM 互操作是 .NET 早期的重要卖点但 COM 几乎等于 Windows 的代名词。当年大量企业组件、Office 自动化、WMI 管理接口全依赖 COM这套生态天然排斥非 Windows 平台。WinForms 和 WPF 是桌面 UI 的两大王牌但它们分别依赖 User32、GDI 和 DirectX 渲染。把这些搬到 Linux 上等于把 Windows 的窗口管理器也搬过去工程量巨大。ASP.NET WebForms 和早期 ASP.NET MVC 的宿主是 IIS。IIS 本身是 Windows 服务请求管线、进程模型、身份认证都和 Windows 账户体系深度耦合。就算 CLR 能跨平台Web 框架这层也过不去。这些绑定不是某一天设计出来的而是一层层叠加出来的。我见过不少朋友在 .NET Framework 项目里用ComponentDispatcher、HwndSource、RegistryKey这些类写的时候没觉得有什么问题一旦想换平台才发现这些 API 的“老家”都在 Windows 的系统 DLL 里。跨平台不是编译一次换个后缀名那么简单它意味着整个框架层的“地基”都要换。2. 挣脱的先行者Mono 把“不可能”拉到“可能”2.1 Mono 的起点ECMA 标准是那把钥匙在 .NET Core 之前“.NET 跨平台”这个命题不是没人做过最著名的就是 Mono。2001 年Ximian 发起 Mono 项目目标是在 Linux 上提供一个独立于微软实现的 .NET 运行时。它之所以能启动关键不是因为微软大发慈悲而是因为微软把 C# 语言和公共语言基础架构CLI提交到了 ECMA也就是后来的 ECMA-334 和 ECMA-335。ECMA 标准公开之后第三方依据标准文档实现自己的 CLR 和编译器就成了合法且可行的事。Mono 的意义在当年非常大。它让 Linux 桌面应用有能力使用 C# 开发GNOME 桌面里好几个核心工具就是 Mono 写的。后来的 Unity 游戏引擎也是把 Mono 作为脚本运行时带到了无数游戏里。可以说Mono 是第一个证明“托管代码可以脱离微软亲儿子运行环境”的项目。它提前给社区埋下了一颗种子原来 .NET 的江湖不是只有微软一家。但 Mono 也背负着沉重的历史包袱。它要兼容的是 .NET Framework 的庞杂 API而这些 API 里有一大堆是 Windows 专属的。Mono 团队选择用各种方式“补兼容”能实现的实现不能实现的就抛异常或者给个空壳。这种“尽力兼容”的思路在小项目里很奏效碰到大型企业项目就力不从心。我们今天回头看Mono 不是输在技术不行而是输在“它要复刻的对象本身就是一座 Windows 专属的大厦”。2.2 Mono 的历史贡献让跨平台从“绝对不行”变成“看情况行”如果说 .NET Framework 的历史枷锁是把锁链完全焊死在 Windows 上那 Mono 就是拿凿子把锁链敲松了一点。至少从它开始社区明确知道 .NET 是可以用另一个运行时跑起来的只是兼容层会受伤。Mono 能跑通不少控制台程序、类库、网络服务但 WPF、WCF 服务端、完整 IIS 管线这些大家都绕不过去。实践中最常见的问题是开发机 Windows 上编译好好的 Web 项目放到 Mono 环境里因为某个System.Drawing底层依赖跑不起来或者是数据库驱动、加密组件内部走了 P/InvokeLinux 上没有对应的 native 库整个服务直接崩掉。我当时排查过不少这类问题最后多半都是绕路换 API而不是真正解决问题。所以说Mono 打破了“不可能”的绝对化但它并没有打通一条系统性的官方路径。它更像是江湖侠客靠个人武艺开路真正的官方队要等到很多年后 .NET Core 出现才进场。3. .NET Core 诞生的导火索云计算的倒逼与老后端的拖累3.1 2014 年的微软转身为什么要亲手拆掉 Windows 绑定Mono 奋斗了十几年微软一直按兵不动但到了 2014 年前后形势变了。云计算兴起之后服务器端的大量工作负载从 Windows Server 转向 Linux企业采购开始更多依赖开源技术栈。如果微软继续把 .NET 锁在 Windows 上那 .NET 在服务器端的市场份额只会越来越小。阿里、亚马逊、谷歌的云上跑着海量 Linux 实例开发者想用 .NET 都没地方放这是很现实的问题。所以微软做了一系列转向开放 .NET 官方实现源码、成立 .NET Foundation、把 Roslyn 编译器、CoreCLR、CoreFX 放到 GitHub 上。这一步的意义很直接微软从“把 .NET 当作 Windows 生态的一部分”转变成“把 .NET 当作微软云上一种主流开发工具”。工具可以跨 Windows 和 Linux才能真正适应混合云、多平台部署的节奏。这在当时被看作“微软拥抱开源”的标志性事件但在我看来本质是商业利益驱动的架构松绑。这件事给开发者的冲击很大。尤其对中小企业来说以前要跑 .NET 网站必须买 Windows Server 授权运维成本比 Linux 高不少。很多创业团队选型时直接把 .NET 排除掉不是语言不好而是平台成本太高。.NET Core 开源并跨平台之后同样一套代码可以部署到便宜得多的 Linux VM 或容器里这才是它能重新获得关注的根本原因。3.2 老框架的结构性难题安装式更新、GAC 和 IIS 的绑架既然要重写一个跨平台运行时就得先清算老框架的历史包袱。.NET Framework 最典型的问题有三个每一个都够让人头疼。第一是“机器级安装”模型。.NET Framework 的运行时是操作系统级别安装的升级也是系统级升级。你在自己机器上装一个新版 .NET 补丁可能会影响同一台机器上的所有老应用。企业环境里不同项目依赖不同 .NET 修补版本的情况非常常见一个应用升级导致另一个应用挂掉简直是运维噩梦。第二是 GAC也就是全局程序集缓存。程序集装进 GAC 之后所有应用共享看起来省空间实际上版本冲突让人头大。你想让两个应用用不同版本的同一个第三方库GAC 模式下很容易互相踩。这种共享依赖的更新方式放到现代容器化部署里完全行不通。第三是 System.Web 与 IIS 的深度耦合。老 ASP.NET 的请求生命周期是嵌在 IIS 里的进程管理、线程调度、管道事件全跟 IIS 绑在一起。IIS 是 Windows 专属服务所以虽然理论上 CLR 有移植可能只要 Web 框架这层不动跨平台就是空谈。想从根上解决只能把 Web 框架也拆掉重写这就是为什么 ASP.NET Core 没有沿用 System.Web 的老模型。我印象特别深的是 .NET Framework 时代部署网站发布完往往还要在 IIS 管理工具里手动配应用程序池、权限、身份认证。而到了 .NET Coredotnet run起来了Kestrel 自己监听端口想折腾就套一层 Nginx跨平台自然就顺了。这背后不是运气而是结构设计变了。4. 拆掉“锁链”的核心.NET Core 背后的架构手术4.1 从“单一大包”到“模块组件”CoreCLR 与 CoreFX.NET Core 能跨平台根本原因是微软没有再走“一个大而全的 Framework”老路而是把运行时和基础库拆成可独立分发的模块。CoreCLR 负责 JIT、GC、类型系统这些运行时核心CoreFX 提供System.*命名空间下的大部分基础库实现两者都能随应用一起发布不依赖操作系统预装。这套模型的直接好处是你的应用可以自己带一份运行时部署到任意支持的操作系统上。不需要在目标机器上先安装特定版本的 .NET Framework也不用怕系统补丁把运行时改掉。这种“app-local runtime”的模式在 Node.js、Go 和 Python 虚拟环境里已经非常成熟.NET Core 把它吸收过来等于把历史包袱甩掉一大半。同时模块化也让平台专属 API 显形了。像 Windows 注册表、事件日志、服务控制被抽到独立的 NuGet 包里只有目标平台是 Windows 时才会使用。跨平台代码默认不引用这些包这就从源头上避免了“我明明写跨平台项目却顺手调了个 Win32 函数”的尴尬。4.2 .NET Standard 与兼容层老项目迁移的“体检清单”对老 .NET Framework 项目来说直接跳到 .NET Core 不现实所以微软还搞了一个 .NET Standard 作为中间契约。简单理解它就是一套跨平台 API 的公共子集。如果你写的库只用到 .NET Standard 里的 API那么这个库可以被 .NET Framework、.NET Core、Xamarin 等多个运行时共用。这不是魔法而是把历史 API 里真正平台无关的部分提炼出来做成一个大家都认的“普通话”。当然.NET Standard 不可能解决所有兼容问题。老项目里常见的 Windows 专属依赖表格里列的比较清楚历史包袱跨平台影响.NET Core 后的处理WinForms / WPF仅限 Windows 桌面在 .NET Core 3.0 中继续支持但仍是 Windows-onlySystem.Web / ASP.NET WebForms依赖 IIS 管线不兼容需要改用 ASP.NET CoreAppDomain 动态加载平台相关能力过大用 AssemblyLoadContext 替代更可控Windows 注册表 / 服务 / 事件日志调用 Windows 专属 API独立 NuGet 包仅 Windows 启用System.DrawingGDI 底层 Windows 化跨平台场景建议用 ImageSharp 等替代老项目迁移的时候我建议先把所有项目依赖用 API Portability Analyzer 扫一遍看看到底有没有踩不能跨平台的 API。这一步能省掉后面大量部署时才发现问题的痛苦。别指望 .NET Standard 帮你“自动跨平台”它只是给你划了一条安全线越线的事还得自己处理。4.3 服务器层解绑Kestrel 替代 IIS跨平台的最后一根铁链在服务器层。老 ASP.NET 的宿主是 IISIIS 又是 Windows 专属所以早期换平台根本无从谈起。ASP.NET Core 直接把 Kestrel 作为内置的跨平台 Web 服务器Kestrel 是纯托管实现的可以在 Windows、Linux、macOS 上直接监听端口处理 HTTP 请求。生产环境里你觉得 Kestrel 裸奔不放心就可以在前面放 Nginx 或 Apache 做反向代理静态文件、负载均衡、HTTPS 终结这些都可以交给代理层。这个变化让 .NET 真正进入了 Linux 部署的主流阵营。我身边好几个开源项目包括之前折腾过的那个“跨平台音乐管理系统 v2.0 源码”后端就是用 ASP.NET Core 写的跑在 Linux 小主机上用 Nginx 反代配合 SQLite 存储稳定性和部署体验都很好。放到五年前这种组合是不可能想象的。所以为什么说历史枷锁被拆掉了因为从运行时到基础库再到 Web 服务器三层全面换血。底层不再是 Windows 系统调用的“附庸”服务器层也不再被 IIS 独占。剩下的第三方库生态中真正卡你跨平台的已经不多大多是能用替代方案绕过去的。5. 给老项目迁移者的三条大实话最后不做什么宏大总结就说我在实际折腾迁移过程中最真实的几条感受也许比抽象地讲历史更有用。第一条不要指望自动化工具“一键迁移”。就算用了 .NET Upgrade Assistant老项目里的 Windows 专属依赖还是得自己一个个决定是替换、抽象还是放弃。特别是System.Web相关的代码越早重写越省心留到后面只会更痛。第二条尽量把跨平台边界画在“项目依赖”而不是“代码技巧”上。我见过很多项目写着写着就从 NuGet 里引了Microsoft.Win32.Registry原因只是某台 Windows 机器上原来用了注册表做配置。到了 Linux这个依赖就得换。最好的做法是开始设计时就明确哪些功能是 Windows-only用接口隔离出来别让它混进核心业务逻辑。第三条体验一次 Linux 容器部署比读十篇文章都管用。拿一个 ASP.NET Core 的空项目放到 Docker 的mcr.microsoft.com/dotnet/aspnet镜像里跑起来再挂个 Nginx 反代你会真正体会到跨平台的红利在哪。容器化加上自包含发布之后.NET 应用和 Go、Node 的应用已经没有本质区别构建一次到处运行。我个人反而很喜欢这段历史。它不是“微软突然就跨平台了”的爽文而是先被 Windows 绑了十几年被 Mono 撬开一道缝被云计算逼到墙角最后才靠拆掉原有架构换来的自由。下篇我会继续聊聊真正的“自由之路”CoreCLR 从零开始的设计取舍以及跨平台之后 .NET 生态失去了什么、得到了什么。如果你恰好也在纠结老项目的去处欢迎先把历史看懂再动手。