我非常喜欢函数上的隐式泛型参数。例如，如果您有：

public void DoStuff<T>(T value);

与其这样称呼它：

DoStuff<int>(5);

你可以：

DoStuff(5);

它将根据参数的类型计算出泛型类型。

如果您通过反射调用方法，则这不起作用。我记得Mono出现了一些奇怪的问题。

对象初始化器中的集合初始化器：

MailMessage mail = new MailMessage {
   To = { new MailAddress("a@example.com"), new MailAddress("b@example.com") },
   Subject = "Password Recovery"
};

可以在单个表达式中初始化整个树。

同样有用，但不常用：约束执行区域。

BCL团队博客中的一句话：

受限执行区域（CER）存在以帮助开发人员编写代码以保持一致性。CLR不能保证开发商代码正确，但CLR正确提升所有运行时引发的故障点（即异步异常）在代码运行之前，或在它完成之后。与…结合对开发人员能力的限制加入CER，这是一种有用的方法对是否执行代码。CER的准备得很好，这意味着当我们看到一个时，我们会迫不及待地JIT在其中找到的任何代码静态可发现的调用图。如果CLR的主机关心堆栈溢出，我们将探测一些数量堆栈空间（尽管可能没有足够的堆栈空间任意方法*）。我们也会延迟线程中止，直到CER已完成运行。

当以原子方式编辑数据结构的多个字段时，它非常有用。因此，对对象进行事务处理是有帮助的。

而且CriticalFinalizerObject似乎是隐藏的（至少是那些没有编写不安全代码的人）。CriticalFinalizerObject保证垃圾收集将执行终结器。分配后，终结器及其调用图将提前准备好。

好不要使用它，但很多人不知道C#支持邪恶的后藤：）

static void Example()
{
    int i = 0;
top:
    Console.WriteLine(i.ToString());
    if (i == 0)
    {
        i++;
        goto top;
    }
}

泛型和奇怪的递归模板模式确实有助于一些静态方法/属性声明。

假设您正在构建类层次结构：

class Base
{
}

class Foo: Base
{
}

class Bar: Base
{
}

现在，您需要在类型上声明静态方法，这些方法应该采用相同类型的参数（或返回值）或相同类型的静态财产。例如，您需要：

class Base
{
    public static Base Get()
    {
        // Return a suitable Base.
    }
}

class Foo: Base
{
    public static Foo Get()
    {
        // Return a suitable Foo.
    }
}

class Bar: Base
{
    public static Bar Get()
    {
        // Return a suitable Bar.
    }
}

如果这些静态方法基本上都做相同的事情，那么您手中就有大量重复的代码。一种解决方案是在返回值上删除类型安全，并始终返回Base类型。但是，如果您希望类型安全，那么解决方案是将Base声明为：

class Base<T> where T: Base<T>
{
    public static T Get<T>()
    {
        // Return a suitable T.
    }
}

你Foo和Bar是：

class Foo: Base<Foo>
{
}

class Bar: Base<Bar>
{
}

这样，他们将自动获得静态方法的副本。

将Singleton模式封装在基类中也很神奇（我知道下面的代码不是线程安全的，这只是为了证明一点）：

public class Singleton<T> where T: Singleton<T>, new()
{
  public static T Instance { get; private set; }

  static Singleton<T>()
  {
    Instance = new T();
  }
}

我意识到这迫使您在单例子类上使用一个公共的无参数构造函数，但是如果没有where T:protected new（）构造，在编译时就无法避免这种情况；然而，可以使用反射在运行时调用子类的受保护/私有无参数构造函数来实现这一点。

我能想到的一对：

[field: NonSerialized()]
public EventHandler event SomeEvent;

这将防止事件被串行化。“field:”表示属性应应用于事件的支持字段。

另一个鲜为人知的功能是重写添加/删除事件处理程序：

public event EventHandler SomeEvent
{
    add
    {
        // ...
    }

    remove
    {
        // ...
    }
}