除了其他答案之外……

我发现它们可以作为重构神类的垫脚石。如果一个类有多个职责(特别是如果它是一个非常大的代码文件)，那么我发现为每个职责添加1x个部分类作为组织和重构代码的第一步是有益的。

这非常有帮助，因为它可以帮助使代码更具可读性，而不会实际影响执行行为。它还可以帮助确定何时易于重构某个职责，或者何时与其他方面紧密纠缠在一起。

然而，需要明确的是，这仍然是糟糕的代码，在开发结束时，您仍然希望每个类有一个职责(而不是每个分部类)。这只是一块垫脚石:)

服务引用是另一个例子，其中部分类用于将生成的代码与用户创建的代码分开。

您可以在更新服务引用时“扩展”服务类，而不必覆盖它们。

分部类的主要用途是生成代码。如果你看看WPF (Windows Presentation Foundation)网络，你用标记(XML)定义你的UI。该标记被编译成部分类。您可以用自己的部分类填充代码。

另一个用途是分割不同接口的实现，例如:

partial class MyClass : IF3
{
    // main implementation of MyClass
}


partial class MyClass : IF1
{
    // implementation of IF1
}

partial class MyClass : IF2
{
    // implementation of IF2
}

作为预编译器指令的替代方案。

如果您使用预编译器指令(即# If DEBUG)，那么您最终会看到一些看起来粗糙的代码与实际的Release代码混合在一起。

你可以创建一个单独的分部类来包含这些代码，或者将整个分部类包装在一个指令中，或者省略该代码文件，使其不被发送给编译器(实际上是做同样的事情)。

除了其他答案之外……

我发现它们可以作为重构神类的垫脚石。如果一个类有多个职责(特别是如果它是一个非常大的代码文件)，那么我发现为每个职责添加1x个部分类作为组织和重构代码的第一步是有益的。

这非常有帮助，因为它可以帮助使代码更具可读性，而不会实际影响执行行为。它还可以帮助确定何时易于重构某个职责，或者何时与其他方面紧密纠缠在一起。

然而，需要明确的是，这仍然是糟糕的代码，在开发结束时，您仍然希望每个类有一个职责(而不是每个分部类)。这只是一块垫脚石:)