作者：By Vance Morrison – 2007
原文链接：https://github.com/dotnet/coreclr/blob/master/Documentation/botr/intro-to-clr.md
翻译：dontpanic
什么是公共语言运行时（Common Language Runtime, CLR）？简单来说就是：
公共语言运行时（CLR）是一套完整的、高级的虚拟机，它被设计为用来支持不同的编程语言，并支持它们之间的互操作。
啊，有点绕口，同时也不太直观。不过这样的表述还是 有用的 ，它把 CLR 的特性用一种易于理解的方式分了类。由于 CLR 实在太过庞大和复杂，这是我们理解它的第一步——犹如从万米高空俯视它，我们可以了解到 CLR 的整体目标；而在这之后，我们就可以带着这种全局观念，更好地详细了解各个子模块。
CLR：一个（很少见的）完备的编程平台
每一个程序都有大量的运行时依赖。当然，一个程序需要由某种特定的编程语言编写而成，不过这只是程序员把想法变成现实的第一步。所有有意义的程序，都免不了需要与一些 运行时库 打交道，以便能够操作机器的其他资源（比如用户输入、磁盘文件、网络通讯，等等）。程序代码还需要某种变换（翻译或编译）才能够被硬件直接执行。这些依赖实在是太多了，不仅种类繁多还互相纠缠，因此编程语言的实现者通常都把这些问题交由其他标准来指定。例如，C++ 语言并没有制定一种 “C++可执行程序” 格式；相反，每个 C++ 编译器都会与特定的硬件架构（例如 x86）以及特定的操作系统（例如 Windows、Linux 或 macOS）绑定，它们会对可执行文件的格式进行描述，并规定要如何加载这些程序。因此，程序员们并不会搞出一个 “C++可执行文件”，而是 “Windows X86 可执行程序” 或 “Power PC Mac OS 可执行程序”。
通常来说，直接使用现有的硬件和操作系统标准是件好事，但它同样也会把语言规范与现有标准的抽象层次紧密捆绑起来。例如，常见的操作系统并没有支持垃圾回收的堆内存，因此我们就无法用现有的标准来描述一种能够利用垃圾回收优势的接口（例如，把一堆字符串传来传去而不用担心谁来删除它们）。同样，典型的可执行文件格式只提供了运行一个程序所需要的信息，但并没有提供足够的信息能让编译器把其他的二进制文件与这个可执行文件绑定。举例来说，C++
程序通常都会使用标准库（在 Windows 上叫做 msvcrt.dll），它包含了大多数常用的功能（例如 printf），但只有这一个库文件是不行的。程序员如果想使用这个库，必须还要有与它相匹配的头文件（例如 stdio.h）才可以。由此可见，现有的可执行文件格式标准无法同时做到：1、满足运行程序的需求；2、提供使程序完整所必须的其他信息或二进制文件。
CLR 能够解决这些问题，因为它制定了一套非常完整的规范（已被 ECMA 标准化）。这套规范描述了一个程序的完整生命周期中所需要的所有细节，从构建、绑定一直到部署和执行。例如，CLR 制订了：
- 一个支持 GC 的虚拟机，它拥有自己的指令集（叫做公共中间语言，Common Intermediate Langauge），用来描述程序所能执行的基本操作。这意味着 CLR 并不依赖于某种特定类型的 CPU。
- 一种丰富的元数据表示，用来描述一个程序的声明（例如类型、字段、方法等等）。因此编译器能够利用这些信息来生成其他程序，它们能够从“外面”调用这段程序提供的功能。
- 一种文件格式，它指定了文件中各个字节所表达的意含义。因此你可以说，一个 “CLR EXE”并没有与某个特定的操作系统或计算机硬件相捆绑。
- 已加载程序的生命周期语义，即一种 “CLR EXE 引用其他 CLR EXE” 的机制。同时还制订了一些规则，指定了运行时要如何在执行阶段查找并引用其他文件。
- 一套类库，它们能够利用 CLR 所支持的功能（例如垃圾回收、异常以及泛型）来向程序提供一些基本功能（例如整型、字符串、数组、列表和字典），同时也提供了一些与操作系统有关的功能（例如文件、网络、用户交互）。
，并使用C#作为主要逻辑的实现语言。这为我们修改游戏逻辑创造了相当好的条件。
），可能还会更多。
