当涉及到扩展方法时，类名似乎什么都不做，但提供了一个分组，这就是命名空间所做的。一旦我包含命名空间，我就会在命名空间中获得所有扩展方法。所以我的问题归结为：我可以从静态类中的扩展方法中获得一些价值吗？
我意识到将它们放入静态类是编译器的要求，但从组织的角度来看，允许在没有围绕它们的类的名称空间中定义扩展方法是合法的。以另一种方式重新表述上述问题：在某些情况下，作为开发人员，我从将扩展方法附加到类而不是附加到命名空间中获得任何实际好处或帮助？
我基本上只是想获得一些直觉、确认或洞察力——我怀疑以这种方式实现扩展方法可能是最容易的，而且不值得花时间让扩展方法以自己的名义存在——空格。
或许您会在 Eric Lippert 的博客文章为什么 C# 不实现“顶级”方法中找到满意的答案？（反过来由 SO 问题为什么 C# 不允许像 C++ 这样的非成员函数提示），从哪里来（我的重点）：
我被问到“为什么 C# 不实现功能 X？” 每时每刻。答案总是一样的：因为从来没有人设计、指定、实施、测试、记录和发布该功能。所有这六件事都是使功能发生所必需的。所有这些都花费了大量的时间、精力和金钱。功能并不便宜，鉴于我们有限的时间、精力和金钱预算，我们非常努力地确保我们只发布那些能够为我们的用户带来最大利益的功能。
我知道这样一个笼统的答案可能无法解决具体问题。
在这种特殊情况下，过去明显的用户利益不足以证明随之而来的语言复杂性是合理的。通过限制不同语言实体相互嵌套的方式，我们 (1) 将法律程序限制为通用、易于理解的样式，以及 (2) 可以定义可理解、可指定、可实现、可测试的“标识符查找”规则并且有据可查。
通过将方法体限制为始终位于结构或类中，我们可以更容易地推断调用上下文中使用的非限定标识符的含义；这样的东西始终是当前类型（或基本类型）的可调用成员。
对我来说，将它们放在课堂上就是将相关功能分组到一个类中。您可能在同一个命名空间中有许多扩展方法。如果我想为 DirectoryInfo 和 FileInfo 类编写一些扩展方法，我将在 IO 命名空间中创建两个类，称为 DirectoryInfoExtensions 和 FileInfoExtensions。
您仍然可以像调用任何其他静态方法一样调用扩展方法。我不知道编译器是如何工作的，但是如果为 .net 2 编译的输出程序集可能仍然可以由旧的 .net 框架使用。这也意味着现有的反射库可以工作并用于运行扩展方法而无需任何更改。同样，我不是编译器专家，但我认为扩展方法上下文中的“this”关键字是允许语法糖允许我们使用方法，就好像它们属于对象一样。
.NET Framework 要求每个方法都存在于程序集中的类中。一种语言可以允许在没有明确指定的封闭类的情况下声明方法或字段，将所有这些方法放在汇编中Fnord的一个名为的类中Fnord_TopLevelDefault，然后Fnord_TopLevelDefault在执行方法查找时搜索所有汇编的类；但是，必须扩展 CLS 规范才能使此功能在混合语言项目中顺利运行。与扩展方法一样，如果 CLS 不承认，这种行为可能是符合 CLS 的，因为不使用这种特性的语言中的代码可以通过拼写Foo在汇编中使用“自由浮动”方法，但是会有点难看。FnordFnord_TopLevelDefault.Foo
A more interesting question is the extent to which allowing an extension method Foo to be invoked from an arbitrary class without requiring a clearly visible reference to that class is less evil than would be allowing a non-extension static methods to be likewise invoked. I don't think Math.Sqrt(x) is really more readable than Sqrt; even if one didn't want to import Math everywhere, being able to do so at least locally could in some cases improve code legibility considerably.
他们可以在内部引用其他静态类成员。
您不仅应该考虑消费者方面，还应该考虑代码维护方面。
尽管智能感知不区分所有者类，但通过工具提示和您添加到 IDE 的任何生产力工具，信息仍然存在。这可以很容易地用于为方法提供一些上下文，否则会是一个扁平（有时很长）的列表。
消费者明智的，底线，我认为这并不重要。