看这里（抽象类设计）：http: //msdn.microsoft.com/en-us/library/ms229047.aspx
它说：
(1) 不要在抽象类型中定义公共或受保护的内部（Visual Basic 中的受保护的朋友）构造函数。
在 C# 中，我们无法实例化抽象类。那么，在 C# 中为抽象类定义公共构造函数是否仍然重要？或者因为语义而不为抽象类编写公共构造函数？
它还说：
(2) 一定要在抽象类中定义一个受保护的或内部的构造函数。
定义内部构造函数？？在 (1) 中，它告诉我们不定义内部受保护构造函数是因为“具有公共或受保护内部可见性的构造函数适用于可以实例化的类型”。为抽象类定义内部构造函数不会违反 (1) 中的规则吗？
提前致谢。:)
让我们看一下每个案例。
protected - 最明显的情况 - 所有子类都可以调用构造函数，无论它们驻留在哪个程序集中（只要抽象基类本身对它们可见）。
internal - 当您希望抽象类型公开可见但不能公开继承时很有用。在这种情况下，您可能希望创建所有非私有构造函数internal。只有与抽象基类相同的程序集中的子类才能调用构造函数——实际上，只有它们能够继承。另一个用例是，如果您想要一个“特殊”构造函数，它应该只对相同程序集的子类可见。
private - 主要用于抽象类的其他构造函数在使用构造函数链接时作为目标的“脏工作”构造函数。当所有构造函数都是私有的时，唯一的其他用途是只允许嵌套类的子类化，这些嵌套类确实可以访问包含类型的私有成员。
public - 没用，行为与protected. 无论如何，只有子类可以调用构造函数，因为基类是抽象的。
受保护的内部- 这也与protected. 可protected internal访问性级别意味着受保护的 OR 内部，而不是受保护的 AND 内部。但是，internal这里的修饰符没有任何作用——它不会阻止位于程序集之外的子类调用构造函数（假设抽象基类是公共的），因为它们可以依赖protected访问，也不允许相同的程序集类型不是调用它的子类（类型是抽象的）。
这里的关键点是private抽象类中的每个非构造函数充其量 protected都已经是. vanilla -internal修饰符加强了对谁可以调用构造函数的限制。public并且protected internal没有完成任何事情，因为它们似乎削弱了限制，但并没有真正成功地做到这一点。
n C#，我们无法实例化抽象类。那么，在 C# 中为抽象类定义公共构造函数是否仍然重要？或者不为抽象类编写公共构造函数是因为语义？
确切地。您不希望用户看到可访问的构造函数，但是当他们调用它时，会出现编译错误。
定义内部构造函数？？在 (1) 中，它告诉我们不定义内部受保护构造函数是因为“具有公共或受保护内部可见性的构造函数适用于可以实例化的类型”。为抽象类定义内部构造函数不会违反 (1) 中的规则吗？
我相信规则 1 是关于public，protected internal规则 2 是关于protectedand internal。所以两者之间没有交集。
多年过去了。我想我现在对这个问题有了更好的理解。因此，除了 Ani 的出色答案之外，我还想添加更多输入。
在 C# 中，我们无法实例化抽象类。那么，在 C# 中为抽象类定义公共构造函数是否仍然重要？
这对编译器无关紧要，但对代码阅读器却很重要。抽象类型中的公共构造函数会误导代码阅读者（他们可能认为它们可以被实例化）。
定义内部构造函数？？在 (1) 中，它告诉我们不定义内部受保护构造函数是因为“具有公共或受保护内部可见性的构造函数适用于可以实例化的类型”。为抽象类定义内部构造函数不会违反 (1) 中的规则吗？
如果我们希望抽象类只能被同一个程序集中的子类继承，显然我们不能使用protected（否则它可以在程序集之外被继承）。现在我们有一些选项可供选择：
public - 如上所述，public会误导代码阅读者。不要使用它。
private - 我们希望抽象类可以被同一个程序集中的子类继承，而不仅仅是嵌套的子类，所以private不会工作。
protected internal - 我们永远不需要它，因为它与protected.
internal - 它会误导代码阅读器，但我们别无选择。我认为这是一种权衡。