FlowingDev

C# Playground 详解：把整个 .NET 运行时塞进你的浏览器

探索 WebAssembly 是如何将真正的 Roslyn 编译器和 .NET 运行时带到浏览器中的，从而把 Web 变成原生的 C# 游乐场。

试用工具: C# Playground

一句话解释

利用 WebAssembly，把 C# 语言、Roslyn 编译器和 .NET 运行时的全部功力，直接“传送”到你的 Web 浏览器里——让你无需安装好几个 G 的 IDE，就能编写、执行代码，甚至编译出真正的 DLL 文件。

它解决了什么问题

从历史上看，C# 开发绝对是“重金属”级别的。作为微软在 2000 年代初对标 Java 给出的优雅答卷，C# 曾被死死地锁在 Windows 生态系统里。如果你只是想写个快速的 C# 脚本，或者测试某个具体的 LINQ 查询是怎么跑的，你可没法直接开个终端搞定。你必须启动 Visual Studio（加载启动画面时刚好够你去泡杯咖啡），新建一个项目，随便起个诸如 ConsoleApp42 这种日后必后悔的名字，苦等 NuGet 包还原，写下区区 5 行代码，运行它，最后再默默把整个文件夹删掉。

后来微软开源了 .NET，让它跨平台，还搞出了 .NET CLI，这确实是一场革命。但即便如此，为了编译一个简单的 "Hello, World"，你仍然需要下载并安装一个庞大的 SDK。

作为开发者，我们极度渴望即时的反馈循环。我们想零摩擦地验证算法原型、测试语法和复现 Bug。我们需要一个沙盒。但对于 C# 这种静态类型的编译型语言，想要在 Web 上建一个真正的沙盒，传统做法是：把代码发给远程后端服务器，在那边编译，扔进 Docker 容器里运行，然后再把文本输出传回浏览器。这种方法慢、服务器托管贵，而且还必须时刻联网。

C# Playground 彻底干掉了服务器，完美解决了这个问题。它直接把编译器和运行时端到了客户端，把你的浏览器变成了一个用完即走、极速狂飙的开发环境。

揭秘底层原理

在浏览器里原生跑 C# 听起来像黑魔法，但这其实是两大工程奇迹的优雅结合：WebAssembly 和 Roslyn 编译器。

WebAssembly 运行时

WebAssembly (Wasm) 是一种二进制指令格式，旨在作为 Web 的可移植编译目标。它能让 C、C++ 和 Rust 等语言在浏览器中以接近原生的速度运行。

为了让 C# 能在浏览器里跑起来，微软可没有用 JavaScript 把 C# 重写一遍。相反，他们拿来了 .NET 运行时（历史上是 Mono 运行时，现在统一为 .NET Wasm），把它 C/C++ 的核心编译成了 WebAssembly。当你加载 C# Playground 时，浏览器会下载 dotnet.wasm。这可是个功能完备的 .NET 虚拟机，直接跑在你浏览器的 V8 引擎（或者 SpiderMonkey、JavaScriptCore）里面。

Roslyn：编译器即服务 (Compiler as a Service)

在 .NET 运行时执行你的代码之前，必须先把人类可读的 C# 编译成微软中间语言（MSIL，或者简称为 IL）。

这时候 Roslyn 就登场了。老式编译器就像个黑盒（源代码丢进去，可执行文件吐出来），但 Roslyn 完全是用 C# 从零打造的，还提供了一套丰富的 API。它是所谓的“编译器即服务”。因为 Roslyn 是用 C# 写的，而我们现在又有了通过 Wasm 在浏览器里跑的 .NET 运行时，所以我们实际上可以把 Roslyn 编译器直接跑在浏览器里。

执行管线 (Execution Pipeline)

当你在 Playground 里敲下代码并点击运行时，下面这些过程会完全在你机器的内存里上演：

  1. 解析 (Parsing)： 浏览器里的 Roslyn 编译器将你的纯文本代码解析成语法树 (Syntax Tree)。
  2. 编译 (Compilation)： Roslyn 把语法树编译成内存中的程序集（IL 字节码）。
  3. 执行 (Execution)： 浏览器里的 .NET Wasm 运行时加载这个内存里的程序集，并执行 IL 指令。标准输出（比如 Console.WriteLine）会被拦截，并打印到你的屏幕上。

导出 DLL

因为 Roslyn 做的是货真价实的标准编译，最终生成的内存程序集，在功能上和你桌面上的 .dll 文件完全一致。Playground 只需抓取内存里的这串 byte array，然后触发浏览器下载就行了。你下载的绝不是什么“模拟”的 DLL，而是由官方引擎编译出来的标准 .NET 库，随时可以丢进服务器、Unity 游戏或者桌面应用程序里跑。

真实世界的使用场景

“这玩意儿能编译过吗？”之争

两个老哥正在对 PR (Pull Request) 进行极限拉扯。一个坚称，这里混用 C# 12 的模式匹配和 switch 表达式一定会报“代码不可达”的编译错误；另一个发誓这绝对是合法语法。谁也不想切换上下文，stash 掉本地的 Git 更改再去开个新分支测试。于是，他们把代码片段复制进浏览器里的 C# Playground。不到 3 秒，代码编译成功，输出了预期结果，瞬间终结了赌局。 经验之谈： 终结语言语义争论最快的办法，就是一个即时、零摩擦的反馈循环。

简单粗暴的 DLL 搓造机

一位顾问在使用客户提供的一台权限被锁死的笔记本电脑，没管理员权限，装不了 .NET SDK。他急需写个小工具函数来解析私有日志格式，以便给主应用程序（支持直接拖拽 DLL 插件进去）使用。与其提交 IT 工单苦等三天来安装 Visual Studio，这位顾问直接打开了 C# Playground，写好解析逻辑，导出编译好的 DLL，然后一把扔进了应用程序的插件文件夹里。 经验之谈： 当浏览器内置了真正的编译器，它就变成了一个完美可用的构建服务器，能帮你直接绕过本地机器的权限限制。

沙盒面试

一位技术 Lead 正在进行远程技术面试。他没有逼着候选人屏幕共享那个笨重的 IDE 环境，也没去忍受远程桌面的高延迟，而是俩人一起登录了一个共享的 C# Playground 会话。候选人可以轻松构建复杂的 LINQ 查询，测试面向对象的数据结构，享受实时反馈，在毫无环境配置压力的情况下秀出真实力。 经验之谈： 一个纯净、免环境配置的沙盒，能把开发者最硬核的编码能力从繁琐的系统运维技能中剥离出来。

常见的坑与雷区

  • 以为自己有真正的文件系统： 你确实能用 System.IO 里的类，但你交互的是 WebAssembly 环境提供的一个虚拟、临时的文件系统。如果你把文件写到 C:\temp\log.txt，它只会活在浏览器内存里，你一刷新页面它就灰飞烟灭了。
  • 调用操作系统原生库： 试图用平台调用服务 (P/Invoke) 去调诸如 [DllImport("user32.dll")] 这种原生 Windows API？那只会翻车翻得很滑稽。你现在的操作系统是 Web 浏览器，这里根本不存在什么桌面原生库。
  • 把它当成高性能集群： WebAssembly 确实快，但它被浏览器沙盒限制得死死的，在内存和线程能力上通常受限。Playground 拿来测试逻辑绝佳，但要是想跑个 Parallel.ForEach 并发处理 2GB 的数据集，那体验绝对糟透了。
  • async void 的陷阱： 写快餐脚本时，很容易忘记如果在 Main 里面 await 操作，那它必须得返回 async Task。在沙盒里用 async void，会导致运行时在异步任务真正跑完之前就把执行上下文给关了，最终引发静默报错。
  • 忘记程序集引用： 如果你打算导出 DLL，记住你的代码是基于沙盒提供的基础类库编译的。要是你依赖了某些外部的第三方 NuGet 包，而它们又没被加载到 Playground 的 Roslyn 上下文里，那代码是绝对编译不过的。

为什么你应该关注它

每当启动完整 IDE 带来的精神或物理开销超过了手头的任务时，你就该打开 C# Playground 了。想不升级本地工具链就“试水”新语言特性（比如探索最新 C# 版本里的主构造函数或集合表达式），它绝对是完美神器。

它也是分享可复现示例的无价之宝。如果你在开源库里发现了 Bug，或者想去 StackOverflow 提问，丢一个能即时复现确切行为的 Playground 链接，绝对比贴一大坨代码然后祈祷对方环境配置正确要管用一万倍。最后，能毫不费力地导出真正的 .dll，让它成为一个强大的、免安装的编译工具，随时随地信手拈来地生成轻量级插件和辅助库。

深入探索

理论搞定，动手试试吧——100% 在你的浏览器中运行。

试用工具: C# Playground