扩展方法的本质是什么,详细见此文 C#扩展方法，爱你在心口难开
重点如下:
扩展方法使您能够向现有类型“添加”方法，而无需创建新的派生类型、重新编译或以其他方式修改原始类型。扩展方法是一种特殊的静态方法，但可以像扩展类型上的实例方法一样进行调用。对于用 C# 和 Visual Basic 编写的客户端代码，调用扩展方法与调用在类型中实际定义的方法之间没有明显的差异。
虽然扩展方法通过实例方法语法进行调用的，但是他们却被定义为静态方法。从定义中我们可以看到，它们的第一个参数指定该方法作用于哪个类型，并且该参数以 this 修饰符为前缀。
扩展方法与其扩展的类之间并没有什么本质的联系，只是编译器跟我们玩的把戏罢了，最终编译器还是将扩展方法转化成静态类的静态方法调用，所以扩展方法不能访问相应类的私有字段和私有方法；至于为什么使用静态类的静态方法，我考虑可能是这样效率相对较高，同时扩展方法作为其他类的扩展，本身类的实例化没有什么意义.
综上进行总结
扩展方法不改变被扩展类的代码，不用重新编译、修改、派生被扩展类
扩展方法不能访问被扩展类的私有成员
扩展方法会被被扩展类的同名方法覆盖，所以实现扩展方法我们需要承担随时被覆盖的风险
扩展方法看似实现了面向对象中扩展对修改说不的特性，但是也违背了面向对象的继承原则，被扩展类的派生类是不能继承扩展扩展方法的，从而又违背了面向对象的多态性。
在我们稳定的引用同一个版本的类库，但是我们没有该类库的源代码，那么我们可以使用扩展方法；但是从项目的可扩展、可维护和版本控制方面来说，都不建议使用扩展方法进行类的扩展。
************************************************************************************
那么现在谈谈我对扩展方法的理解:
我认为扩展方法是对现实世界一种常见范式的模拟，这种方式违背了面向对象的一些基本原则，但是这也是C#走向动态语言的一大步。
本质上来说： 扩展方法是破坏原来的层次结构，通过网络结构加快业务逻辑处理.
举例来说：
public class 手电筒
{
public void 照射()
}
村里的老刘是个电子爱好者，他从商场购买的手电筒只能照射用，他买回来改装后，这手电筒还能做喇叭用，他将改装的手电筒在村里卖。
public static class 改装室 //扩展方法实现
{
public static void 喇叭叫(this 手电筒 手电筒1)
{ }
}
public class 新手电筒: 手电筒 //继承实现
{
public void 喇叭叫(){}
}
村里不少人都买了，他们拿着手电筒，知道这个手电筒不仅能照射,还能喇叭叫
手电筒1.照射()
手电筒1.喇叭叫()
这种方式扩展和继承都能实现，但是在使用时，继承方式引入了新的变量体，可以认为继承会使得调用时，整个事务逻辑更复杂。
当我们确定先前的手电筒被完全密封不可见时，继承方式更适合，而当手电筒一直可见时，使用扩展方法可以减少一个新类的概念体。
对于.NET中一些常见类，String,Dictionary,List,Random
我们可能都会对他们进行一些特殊的调用，一般情况下，
我们可能会用继承：StringME,DictionaryME,ListME,RandomME
也可能直接调用对象: ME.str(String sone),ME.dic(Dictionary<> done),ME.str(List<> lone)
上面的两种方式都意味着你不仅需要知道String,Dictionary,List,Random,还需要知道新的StringME,DictionaryME,ListME,RandomME或者ME.str(String sone),ME.dic(Dictionary<> done),ME.str(List<> lone).
从事务逻辑说: 每次处理时需要处理的信息量已经增大一倍。
而如果我们使用扩展方法后，通过String,Dictionary,List,Random的实例对象,即可调用。这降低了处理一个问题时所需要汇聚的信息量，所以回归到整个问题的本质，扩展方式的优势使得我们处理一些问题时能消耗更少的注意力。但是扩展方法可能和原来的方法以及继承类有冲突，存在调用的安全性问题，所以大项目一般不会采用。而小项目则可以快速开发应用。
更多的应用见c# 扩展方法奇思妙用。