I think I have an additional opinion on this. At first, I was wondering about how it makes sense to declare something to public in an internal class. Then I have ended up here, reading that it could be good if you later decide to change the class to public. True. So, a pattern formed in my mind: If it does not change the current behavior, then be permissive, and allow things that does not makes sense (and does not hurt) in the current state of code, but later it would, if you change the declaration of the class.

是这样的:

public sealed class MyCurrentlySealedClass
{
    protected void MyCurretlyPrivateMethod()
    {
    }
}

According to the "pattern" I have mentioned above, this should be perfectly fine. It follows the same idea. It behaves as a private method, since you can not inherit the class. But if you delete the sealed constraint, it is still valid: the inherited classes can see this method, which is absolutely what I wanted to achieve. But you get a warning: CS0628, or CA1047. Both of them is about do not declare protected members in a sealed class. Moreover, I have found full agreement, about that it is senseless: 'Protected member in sealed class' warning (a singleton class)

因此，在这个警告和相关的讨论之后，我决定在一个内部类中使所有内容都变得内部或更少，因为它更符合那种思维方式，而且我们不会混合不同的“模式”。

它是一样的，public方法将被标记为内部的，因为它在内部类中，但它有一个优点(正如你所说)，如果你想将类标记为公共的，你必须修改更少的代码。

在某些情况下，也可能是内部类型实现了一个公共接口，这意味着在该接口上定义的任何方法仍然需要声明为公共。

There does be a difference. In our project we have made a lot of classes internal, but we do unit test in another assembly and in our assembly info we used InternalsVisibleTo to allow the UnitTest assembly to call the internal classes. I've noticed if internal class has an internal constructor we are not able to create instance using Activator.CreateInstance in the unit test assembly for some reason. But if we change the constructor to public but class is still internal, it works fine. But I guess this is a very rare case (Like Eric said in the original post: Reflection).

I think I have an additional opinion on this. At first, I was wondering about how it makes sense to declare something to public in an internal class. Then I have ended up here, reading that it could be good if you later decide to change the class to public. True. So, a pattern formed in my mind: If it does not change the current behavior, then be permissive, and allow things that does not makes sense (and does not hurt) in the current state of code, but later it would, if you change the declaration of the class.

是这样的:

public sealed class MyCurrentlySealedClass
{
    protected void MyCurretlyPrivateMethod()
    {
    }
}

According to the "pattern" I have mentioned above, this should be perfectly fine. It follows the same idea. It behaves as a private method, since you can not inherit the class. But if you delete the sealed constraint, it is still valid: the inherited classes can see this method, which is absolutely what I wanted to achieve. But you get a warning: CS0628, or CA1047. Both of them is about do not declare protected members in a sealed class. Moreover, I have found full agreement, about that it is senseless: 'Protected member in sealed class' warning (a singleton class)

因此，在这个警告和相关的讨论之后，我决定在一个内部类中使所有内容都变得内部或更少，因为它更符合那种思维方式，而且我们不会混合不同的“模式”。

我今天真的很纠结这个问题。到目前为止，如果类是内部的，我会说方法都应该被标记为内部的，并且会认为其他任何东西都只是糟糕的编码或懒惰，特别是在企业开发中;然而，我必须子类化一个公共类并重写它的一个方法:

internal class SslStreamEx : System.Net.Security.SslStream
{
    public override void Close()
    {
        try
        {
            // Send close_notify manually
        }
        finally
        {
            base.Close();
        }
    }
}

方法必须是公共的，这让我想到，将方法设置为内部没有逻辑意义，除非它们真的必须是，就像Eric Lippert说的那样。

直到现在，我从来没有真正停下来思考过这个问题，我只是接受了它，但在阅读了Eric的帖子后，它真的让我思考，经过很多深思熟虑后，它有很多意义。