从内存泄漏到CLR底层：托管代码执行模型与程序集加载全解析

1. 从一段“诡异”的报错说起：为什么我要回头啃CLR基础

前阵子帮一个朋友排查他项目里的一个内存泄漏问题，现象很怪：一个看起来平平无奇的定时任务，跑上几个小时之后内存就缓慢上涨，最后触发OOM。他用了各种工具抓dump、看对象数量，折腾了两天没找到根因。我接手之后，把dump拉下来一看，发现大量本该被回收的对象一直挂在终结器队列里，根源是他自定义了一个类，里面持有非托管资源，但Dispose模式写得有问题，导致对象在Finalize队列里排队等待，而终结器线程又因为某个阻塞操作被卡住了。

这个问题表面上是“内存泄漏”，实际上牵扯到的是CLR的对象生命周期管理、垃圾回收机制、终结器队列、托管与非托管资源的边界这一整套底层逻辑。如果只是停留在“用using包一下”这种层面，遇到这类问题基本就是抓瞎。也正是这次经历，让我决定把CLR这套东西从头到尾系统性地梳理一遍，于是就有了这篇内容。

这篇东西适合谁看？如果你写过一段时间的C#，能熟练用Visual Studio或者Rider写业务代码，但对“代码到底是怎么跑起来的”这件事只有模糊印象，那这篇就是写给你的。我不会一上来就甩一堆IL指令或者GC代龄的数学公式，而是从概念、执行模型、托管模块、程序集、FCL这条主线，一层一层往下剥，把每个环节“为什么这么设计”讲清楚。看完之后，你至少能做到：看到一个类型定义，脑子里能大致浮现出它在编译后长什么样、运行时怎么被加载、内存里怎么布局、什么时候被回收。

2. CLR到底是什么：先把概念这层窗户纸捅破

2.1 公共语言运行时不是“虚拟机”那么简单

很多人第一次接触CLR，会把它类比成Java的JVM，这个类比方向没错，但容易让人产生一个误解，觉得CLR就是个“跑字节码的虚拟机”。实际上CLR的全称是Common Language Runtime，公共语言运行时，它的职责远不止“执行代码”这一件事。它更像是一个托管代码的操作系统，负责内存分配与回收、类型安全校验、异常传播、线程调度、代码访问安全、程序集加载、JIT编译等等一整套基础设施。

我习惯用一个类比来解释：如果把你的C#代码比作一份“食材”，那么编译器（比如Roslyn）就是负责把食材切成统一规格的“备菜员”，它把C#切成中间语言（IL）；而CLR则是那个“厨房”，它提供灶台、锅具、火候控制、清洁回收，甚至还有食品安全检查（类型安全）。你写的代码能不能跑、跑得快不快、会不会把厨房点着，很大程度上取决于这个厨房的规则。

这里有个关键点必须强调：CLR是语言无关的。C#、F#、VB.NET、甚至C++/CLI，只要编译器能把源码编译成符合CLI规范的IL，CLR就能执行。这就是“公共语言”这个词的由来。不同语言编译出来的IL可以互相调用，因为它们在CLR这一层被统一成了同一套类型系统和执行模型。这也是为什么你可以在C#项目里直接引用一个用F#写的库，编译器层面几乎无感。

2.2 CTS、CLS、CLI：三个容易混淆的缩写

在CLR的概念体系里，有三个缩写经常被混着用，但它们的边界其实很清楚。

CLI（Common Language Infrastructure）是最大的那个圈，它是一份规范文档，定义了IL指令集、文件格式、类型系统、元数据布局等等。你可以把它理解成“宪法”，规定了托管代码世界的基本法则。微软的CLR是CLI规范的一个实现，Mono、CoreCLR也是实现。

CTS（Common Type System）是CLI规范里关于类型系统的那部分。它规定了托管世界里类型可以怎么定义：值类型和引用类型怎么区分、继承规则是什么、字段和方法怎么描述、可见性怎么控制。CTS的目标是让不同语言定义的类型能够互相理解。比如C#里的int和VB.NET里的Integer，在CTS层面其实是同一个类型System.Int32。

CLS（Common Language Specification）则是CTS的一个子集，是一套“语言互操作的最低标准”。为什么需要它？因为不是所有语言都支持CTS的全部特性。比如C#支持无符号整数uint，但有些语言不支持。如果一个库想被所有CLS兼容的语言使用，那它对外暴露的公共接口就不能用uint这种“非CLS兼容”的类型。CLS就是告诉库作者：你只要遵守这些规则，你的库就是“通用”的。

我个人的经验是，日常开发里CTS和CLS的存在感不强，但一旦你要写跨语言的公共库，或者用[assembly: CLSCompliant(true)]这个特性时，它们就会跳出来提醒你。理解这三者的层次关系，对后面理解程序集和元数据非常有帮助。

2.3 托管代码与非托管代码的边界在哪里

“托管”这个词，核心在于CLR是否替你管理内存和类型安全。托管代码就是跑在CLR之上、由CLR负责内存分配回收、类型校验、异常处理的代码。非托管代码则是直接跑在操作系统之上，内存要自己申请自己释放，类型安全自己保证。

这个边界在实际开发中非常关键。比如你调用一个Windows API，或者用一个C++写的DLL，那就是跨到了非托管世界。跨边界的时候，CLR需要做封送（Marshaling），把托管世界的参数转换成非托管世界能理解的格式，反之亦然。这个过程有性能开销，也容易出问题，比如字符串编码不对、结构体布局不匹配、内存所有权不清导致泄漏。

我踩过的一个坑是：早期写代码时用DllImport调用一个非托管函数，返回一个IntPtr指向非托管内存，我直接把它转成字符串用了，结果那块内存是临时的，用完就被释放了，导致后面读到脏数据。正确做法是要么用Marshal.PtrToStringAnsi立刻拷贝一份，要么明确知道这块内存的生命周期由谁负责。这类问题的根源，就是没有搞清楚托管与非托管的边界。

3. 执行模型：你的代码从写完到跑起来经历了什么

3.1 从源码到IL：编译阶段做了什么

当你按下编译按钮，C#编译器（Roslyn）做的事情大致分几步。首先是语法分析，把源码文本解析成语法树；然后是语义分析，解析类型、检查方法调用是否合法、做类型推断；最后是代码生成，把语法树转换成IL指令，同时生成元数据表。

这里有个细节值得注意：编译器生成的IL是面向栈的。什么意思？就是IL指令操作的是一个虚拟的求值栈，比如你要算1 + 2，IL大概是这样的：

ldc.i4.1 // 把常量1压栈 ldc.i4.2 // 把常量2压栈 add // 弹出两个值相加，结果压栈

这种基于栈的设计，好处是简单、可验证、与具体硬件无关。坏处是如果直接解释执行，性能会比较差，因为频繁的栈操作和指令分发开销大。所以CLR不会直接解释IL，而是要先JIT编译成本地机器码。

编译器除了生成IL，还会生成元数据。元数据描述了程序集里有哪些类型、每个类型有哪些字段和方法、方法的签名是什么、引用了哪些外部类型等等。元数据和IL是分开存储的，但互相引用。元数据的存在，让CLR在运行时能够“反射”出类型信息，也是程序集自描述能力的基础。

3.2 JIT编译：IL是怎么变成机器码的

JIT（Just-In-Time）编译是CLR执行模型的核心。它的基本流程是：当一个方法第一次被调用时，CLR找到这个方法对应的IL，把它编译成本地机器码，然后缓存起来，后续再调用就直接执行机器码。

为什么不在安装或启动时一次性把所有IL都编译成机器码？因为那样启动会非常慢，而且很多代码可能根本不会被执行到。JIT的策略是“按需编译”，用时间换空间，同时还能根据运行时的实际情况做优化。比如JIT知道当前CPU支持哪些指令集，可以生成针对性的机器码；如果某个方法被频繁调用，JIT还可以做更激进的优化。

JIT编译的过程大致是：先根据方法签名和元数据确定要编译的范围，然后做IL验证，确保IL是类型安全的（比如不会把int当引用类型用），接着做优化，比如常量折叠、死代码消除、内联小方法，最后生成机器码并打补丁到调用点。

这里有个实际开发中会遇到的点：JIT编译是有开销的。对于启动性能敏感的场景，比如一个命令行工具，每次启动都要JIT编译大量方法，启动时间就会比较长。这时候可以考虑用ReadyToRun或者NGen提前编译，把IL预先编译成机器码，减少运行时的JIT开销。不过提前编译的机器码不能做运行时特化优化，所以峰值性能可能不如JIT。这是一个典型的权衡。

3.3 方法调用的完整链路

一个方法调用从代码层面看就是一行obj.DoSomething()，但在CLR层面，这条链路相当长。我把它拆成几个关键步骤：

第一步是方法解析。CLR需要根据对象的实际类型，找到DoSomething这个方法对应的元数据入口。如果是虚方法，还要查虚方法表（vtable）来确定实际调用哪个实现。

第二步是JIT检查。如果这个方法还没被JIT编译过，就触发JIT编译。编译完成后，调用点的地址会被替换成机器码的地址。

第三步是参数传递和栈帧建立。CLR按照调用约定把参数放到寄存器或栈上，建立新的栈帧，保存返回地址。

第四步是执行机器码。这时候就是CPU在执行了，CLR的控制权暂时交给机器码。

第五步是返回和栈帧清理。方法执行完，返回值放到约定位置，栈帧弹出，控制权回到调用方。

这条链路里，虚方法调用是最值得关注的。因为虚方法需要在运行时确定实际类型，所以不能像静态方法那样直接跳转。CLR的做法是每个对象头部有一个方法表指针（Method Table Pointer），指向该类型的方法表，方法表里存着各个虚方法的实际地址。调用虚方法时，先通过对象头找到方法表，再根据方法槽位找到实际地址。这个过程比静态调用多了一次间接寻址，所以虚方法调用通常比非虚方法慢一点点。不过现代CPU的分支预测和缓存机制，让这个差距在大多数场景下可以忽略。

3.4 异常处理在CLR层面的实现

异常处理是CLR执行模型里比较复杂的部分。C#里一个简单的try-catch-finally，在IL层面会变成异常处理子句，描述哪些指令范围对应哪个catch或finally块。

当异常抛出时，CLR的异常分发机制开始工作。它首先在当前方法的异常处理表里查找匹配的catch子句。如果找到，就跳转到对应的处理代码；如果没找到，就沿着调用栈往上找，直到找到匹配的catch或者到达栈顶。如果到达栈顶还没找到，进程就会终止。

这里有个性能相关的点：异常的开销主要在于抛出和栈展开，而不是try块本身。也就是说，如果异常不发生，try-catch几乎不带来运行时开销（JIT编译时会生成异常处理表，但不影响正常执行路径）。但一旦异常抛出，栈展开、查找处理程序、构造异常对象这些操作就比较昂贵。所以“用异常做流程控制”是明确的反模式，不是因为try慢，而是因为throw慢。

finally块的执行时机也值得注意。无论try块是正常结束、抛出异常、还是被return提前退出，finally块都会执行。CLR通过在异常处理表里标记finally范围，并在栈展开过程中插入对finally块的调用，来保证这一点。但如果进程被强制终止，或者发生了栈溢出这种严重错误，finally可能不会执行。这也是为什么不能在finally里放关键的业务逻辑，它只适合做资源清理。

4. 托管模块与程序集：代码的物理组织形式

4.1 托管模块的内部结构

一个托管模块（Managed Module）是CLR能加载的最小物理单位，通常就是一个.dll或.exe文件。它的内部结构可以分成几大块：

PE头是Windows可执行文件的标准头部，让操作系统能识别这是一个可执行文件。但托管模块的PE头里有一些特殊字段，比如CLR头部的入口，告诉操作系统“这个文件需要CLR来加载”。

CLR头是托管模块特有的，包含了一些关键信息：IL代码的入口、元数据的入口、模块的版本、强名称签名信息等。操作系统加载文件时，看到CLR头就知道要把控制权交给CLR。

元数据是描述模块内容的数据表，包括类型定义表、方法定义表、字段定义表、引用表等等。元数据是自描述的，CLR不需要额外的类型库就能知道模块里有什么。

IL代码就是编译后的中间语言指令，按方法组织。

资源是可选的，比如嵌入的字符串、图片等。

我个人的理解是，托管模块的设计核心是自描述。传统的C++ DLL需要配套的头文件和导入库才能被使用，而托管模块把所有信息都打包在文件内部，CLR直接读元数据就能知道怎么用。这也是为什么C#项目引用一个DLL时，只需要那一个文件，不需要额外的头文件。

4.2 程序集：逻辑上的部署单元

程序集（Assembly）是CLR的逻辑部署单元，它可能包含一个或多个托管模块，外加一个清单（Manifest）。清单是程序集的“目录”，描述了程序集的名字、版本、文化、强名称签名、包含哪些模块、引用了哪些其他程序集、有哪些类型对外可见等等。

为什么要有程序集这个概念，而不是直接用模块？因为模块是物理单位，程序集是逻辑单位。一个程序集可以包含多个模块，这些模块一起构成一个逻辑上的整体。比如你可以把一部分类型放在A.dll，另一部分放在B.netmodule，然后用一个程序集清单把它们组合起来。这样部署的时候可以按逻辑单元来管理版本和引用。

不过实际开发中，绝大多数情况下一个程序集就是一个模块，也就是一个.dll文件。多模块程序集比较少见，主要出现在一些需要混合语言或者特殊部署的场景。

程序集的版本控制是它的重要能力。每个程序集有版本号（主版本.次版本.生成号.修订号），CLR在加载时会根据引用信息去匹配版本。强名称程序集还有公钥签名，保证程序集的完整性和唯一性。这套机制是.NET生态里“DLL地狱”问题比传统Windows开发少很多的原因之一。

4.3 强名称签名与全局程序集缓存

强名称（Strong Name）是程序集的一个可选属性，它用私钥对程序集进行签名，生成一个唯一的公钥标记。强名称的作用有两个：一是唯一标识，不同公司或个人生成的程序集即使名字相同，公钥标记不同也能区分；二是完整性校验，CLR加载时会验证签名，防止程序集被篡改。

全局程序集缓存（GAC）是机器级别的一个程序集仓库，只有强名称程序集才能装进去。GAC的好处是多个应用可以共享同一个程序集，不用每个应用都拷贝一份。但GAC也带来了一些复杂性，比如版本冲突、部署依赖等。现代.NET开发里，GAC的使用已经大大减少，更多是用NuGet包管理依赖，每个应用有自己的依赖副本，隔离性更好。

我个人的经验是，除非你在做需要被多个应用共享的公共库，否则不建议往GAC里装东西。GAC的卸载和版本管理比较麻烦，而且一旦装错版本，排查起来很痛苦。NuGet的本地副本模式虽然占一点磁盘空间，但依赖关系清晰，升级回滚都方便。

4.4 程序集加载的时机与上下文

CLR加载程序集是按需加载的，不是启动时把所有引用的程序集都加载进来。只有当一个类型第一次被使用时，CLR才会去加载它所在的程序集。这个策略减少了启动开销，但也意味着程序集加载可能发生在运行的任何时刻。

加载程序集时，CLR需要确定从哪里加载。默认情况下，它会按照一套探测规则去找：先看应用目录，再看GAC，再看配置文件里指定的路径。这套规则在.NET Framework时代比较固定，到了.NET Core之后更加灵活，可以通过AssemblyLoadContext自定义加载逻辑。

AssemblyLoadContext是.NET Core引入的一个比较重要的概念，它允许你把程序集加载到不同的上下文里，实现隔离。比如一个插件系统，每个插件可以有自己的AssemblyLoadContext，加载自己版本的依赖，互不干扰。这在.NET Framework时代是很难做到的，因为那时候所有程序集都加载到默认的AppDomain里，版本冲突很难解决。

5. FCL：站在巨人的肩膀上写代码

5.1 FCL与BCL的关系

FCL（Framework Class Library）是.NET框架提供的类库总称，包含了成千上万个类型，覆盖了集合、IO、网络、加密、XML、LINQ、并发等等几乎所有常用功能。BCL（Base Class Library）是FCL的一个子集，指的是最基础的那部分类型，比如System.Object、System.String、System.Int32、System.Exception这些。

为什么区分FCL和BCL？因为BCL是所有.NET实现都必须提供的，是CLI规范的一部分。而FCL的其余部分，不同实现可能有差异。比如.NET Framework、.NET Core、Mono的FCL覆盖范围就不完全一样。BCL则是保证跨实现一致性的底线。

实际开发中，你用的绝大多数类型都来自FCL。理解FCL的组织方式，能帮你更快找到需要的类型。FCL的命名空间是按功能划分的，System是根命名空间，System.Collections是集合相关，System.IO是输入输出，System.Net是网络，System.Threading是线程。这个划分逻辑比较直观，用多了自然就记住了。

5.2 核心类型的设计哲学

FCL里有一些类型是整个框架的基石，理解它们的设计哲学，对写好C#代码很有帮助。

System.Object是所有类型的基类，它定义了ToString、Equals、GetHashCode、GetType这几个方法。其中Equals和GetHashCode的契约是：如果两个对象Equals返回true，它们的GetHashCode必须相同。这个契约在把对象放进哈希表（比如Dictionary）时非常关键。我见过不少bug是因为重写了Equals但没重写GetHashCode，导致字典查找失败。

System.String是不可变的，这个设计决策影响深远。不可变意味着字符串一旦创建就不能修改，所有“修改”操作实际上是创建新字符串。好处是线程安全、可以安全共享、哈希值可以缓存。坏处是频繁拼接字符串会产生大量临时对象，所以要用StringBuilder。理解不可变性，是理解很多.NET API设计的前提。

System.IDisposable接口是资源管理的核心。它只有一个Dispose方法，用来释放非托管资源。配合using语句，可以保证资源在作用域结束时被释放。但Dispose模式有个经典写法，涉及Dispose(bool disposing)虚方法和GC.SuppressFinalize调用，写错了就容易出问题。我开头提到的那个内存泄漏，根源就是Dispose模式没写对。

5.3 集合类型的选择逻辑

FCL提供了丰富的集合类型，选对了能省很多事，选错了可能带来性能问题或者bug。

List<T>是最常用的动态数组，随机访问快，尾部插入快，中间插入删除慢。Dictionary<TKey, TValue>是哈希表，查找插入删除平均O(1)，但无序。HashSet<T>是去重集合，判断存在性快。Queue<T>和Stack<T>分别是队列和栈，适合特定顺序的场景。LinkedList<T>是双向链表，中间插入删除快，但随机访问慢，实际用得比较少。

选择集合时，我通常问自己几个问题：需要按索引访问吗？需要保持顺序吗？需要去重吗？查找频繁还是插入频繁？回答完这几个问题，基本就能确定用哪个了。比如需要频繁按key查找，那Dictionary是首选；如果需要保持插入顺序又要快速查找，可以考虑Dictionary加一个List来维护顺序，或者用SortedDictionary（但它是按key排序，不是插入顺序）。

这里有个性能陷阱：List<T>的Contains方法是线性查找，O(n)。如果在一个大列表里频繁调用Contains，性能会很差。这时候应该换成HashSet<T>。我见过一个案例，一个列表有几十万条数据，每次插入前都用Contains检查是否重复，结果整个操作跑了十几分钟。换成HashSet之后，几秒钟就完成了。

5.4 异步与并发的FCL支持

现代.NET开发离不开异步和并发，FCL在这方面提供了很多工具。

Task和Task<T>是异步编程的核心，代表一个异步操作。async和await关键字让异步代码写起来像同步代码，编译器会把它转换成状态机。理解状态机的原理，能帮你写出更高效的异步代码。比如async方法里的局部变量会被提升到状态机的字段，所以不要在async方法里放太多大对象，否则会增加状态机的大小。

CancellationToken是取消异步操作的标准机制。它本身只是一个结构体，真正的取消逻辑由CancellationTokenSource控制。把CancellationToken传进异步方法，方法内部定期检查IsCancellationRequested或者调用ThrowIfCancellationRequested，就能实现可取消的异步操作。

并发集合比如ConcurrentDictionary、ConcurrentQueue，是线程安全的，适合多线程环境。但要注意，线程安全不等于“用了就没问题”，复合操作仍然需要额外同步。比如ConcurrentDictionary的GetOrAdd是原子的，但如果你先TryGetValue再Add，这两步之间可能有其他线程插入，就不是原子的了。

6. 实操中踩过的坑与排查技巧

6.1 类型加载异常排查

TypeLoadException和FileNotFoundException是程序集加载阶段最常见的两个异常。前者通常是类型定义有问题，比如引用了不存在的基类、接口实现不完整、泛型约束不满足。后者通常是程序集找不到，可能是路径不对、版本不匹配、或者依赖缺失。

排查这类问题，我通常先用fuslogvw（程序集绑定日志查看器）看CLR到底去哪里找了程序集，找到了哪个版本。.NET Core时代可以用DOTNET_环境变量开启绑定日志。另一个工具是ildasm或者ILSpy，直接看程序集的元数据，确认类型定义和引用关系。

有个常见坑是版本重定向。比如A程序集引用B的1.0版本，但实际部署的是B的2.0版本，如果没有配置绑定重定向，CLR会报找不到1.0版本。.NET Core的版本解析策略和.NET Framework不同，默认是“向上滚动”，也就是如果找不到精确版本，会尝试用更高的版本。但这个行为可以通过配置改变，所以还是要清楚当前项目的版本策略。

6.2 内存问题的排查思路

内存问题大致分两类：泄漏和碎片。泄漏是指对象不再被使用但无法被回收，碎片是指内存空间足够但没有连续的大块可用。

排查泄漏，第一步是抓dump。可以用dotnet-dump、dotnet-gcdump或者任务管理器的“创建转储文件”。拿到dump后，用dotnet-dump analyze或者Visual Studio的内存分析工具，看哪些类型的对象数量异常多、占用内存异常大。然后看这些对象的引用链，找到是谁在持有它们。

常见的泄漏原因有几个：事件订阅未取消，导致发布者持有订阅者的引用；静态集合不断添加元素，从不清理；终结器队列阻塞，导致对象无法被回收；非托管资源未释放，托管对象被回收了但非托管内存泄漏。

碎片问题比较隐蔽，通常表现为“内存总量够但分配大对象失败”。这时候要看GC的代龄分布和大对象堆（LOH）的情况。LOH默认不压缩，容易产生碎片。可以通过GCSettings.LargeObjectHeapCompactionMode手动触发一次LOH压缩，或者调整GC模式。

6.3 JIT编译相关的性能问题

JIT编译带来的性能问题主要有两个：启动慢和首次调用慢。

启动慢是因为大量方法需要JIT编译。解决办法是用ReadyToRun或者NGen提前编译。ReadyToRun是.NET Core的提前编译方案，把IL预编译成机器码，启动时直接加载，省去JIT时间。但ReadyToRun的机器码是“保守”的，不能做运行时特化优化，所以峰值性能可能略低。

首次调用慢是因为某个方法第一次执行时要等JIT编译完成。对于交互式应用，这可能导致界面卡顿。解决办法是预热，在应用启动后、用户操作前，主动调用一些关键方法，触发JIT编译。ASP.NET Core的ApplicationInitialization或者自己写一个预热逻辑都可以。

还有一个技巧是分层编译。.NET Core默认开启分层编译，方法先被快速JIT编译成不太优化的机器码，快速可用；如果方法被频繁调用，再重新JIT编译成高度优化的机器码。这个策略兼顾了启动速度和峰值性能。可以通过配置调整分层编译的行为，比如关闭它来获得更快的峰值性能，但启动会变慢。

6.4 常见问题速查表

7. 我对CLR学习路径的一点个人体会

回过头看，我学CLR的过程其实走了不少弯路。一开始是抱着《CLR via C#》硬啃，啃了几章发现概念太多、太抽象，看完就忘。后来是遇到实际问题了，带着问题去查、去实验，反而理解得深。所以我的建议是：不要试图一次性把CLR的所有细节都记住，而是先建立一个大框架，知道有哪些模块、各自负责什么，然后在实际遇到问题时，再深入到具体模块去研究。

比如你现在理解了执行模型的大致流程，知道IL、JIT、元数据、程序集这些概念的位置和关系，这就够了。下次遇到TypeLoadException，你知道要去查元数据和程序集加载；遇到内存问题，你知道要去查GC和对象生命周期；遇到性能问题，你知道要去查JIT和调用链路。有了这个框架，具体细节可以随时查文档、做实验。

另外，多动手实验比只看书有效得多。比如你可以自己写一段简单的C#代码，编译后用ILSpy看生成的IL，对照着理解编译器做了什么。你可以写一个自定义的Dispose模式，然后用dotnet-gcdump看对象的回收情况。你可以写一个虚方法调用的例子，用性能分析器看调用开销。这些实验花不了多少时间，但能让你对CLR的行为有直观的感受。

最后说一个我自己的习惯：每次遇到一个CLR相关的异常或者性能问题，解决之后我都会简单记一笔，写清楚现象、原因、解决方法和涉及的CLR知识点。积累下来，这就是一份属于自己的“CLR实战笔记”，比任何书都更贴合自己的实际需求。这个习惯坚持了几年，现在遇到大部分CLR相关的问题，我基本能凭经验快速定位方向，剩下的就是查细节和验证了。