sealed 关键字不支持“只允许指定子类继承”的白名单控制，仅提供彻底禁止继承（类）或终止重写（成员）的黑名单机制；需通过 internal 构造器、程序集边界或工厂模式等设计手段实现受限继承。
sealed 类不能被继承，但 sealed 成员允许有限继承
直接说结论：sealed 关键字本身**不支持“只允许指定子类继承”这种白名单式控制**。C# 的 sealed 是“黑名单”逻辑——加在类上就彻底禁止所有继承；加在方法或属性上则要求重写它的子类必须用 sealed 终止进一步重写。它没有 allowedSubclasses = [A, B] 这种语法。
想实现“仅允许 A 和 B 继承 C”，得靠设计约束而非语言关键字
常见做法是把基类设为 internal + 抽象，并配合友元程序集或构造器限制。例如：
public abstract class CoreService
{
internal CoreService() // 外部程序集无法 new，也无法继承（因为构造器不可访问）
{
}
}
然后在同一个程序集内定义 class A : CoreService 和 class B : CoreService。外部项目即使看到 CoreService，也无法继承它——编译器报错 'CoreService' does not contain a constructor that takes 0 arguments（因为 internal 构造器对外不可见）。
- 这个方案依赖程序集边界，不是运行时保护，但足够应对大多数模块化场景
- 如果必须跨程序集，可用
InternalsVisibleTo指定可信的子类所在程序集 - 不要试图用
sealed类 + 反射绕过——那破坏了封装意图，且 .NET 8+ 对反射创建 sealed 类实例已有更严格限制
误用 sealed 导致编译错误的典型现象
开发者常以为给类加 sealed 就能“选择性放行”，结果遇到这些错误：
-
'D' cannot inherit from sealed class 'C'：哪怕 D 是你写的唯一子类，只要 C 是sealed，这条继承语句就立刻失败 -
'C' is inaccessible due to its protection level：把构造器设为private或internal后，子类在错误作用域里尝试继承 - 单元测试里 mock sealed 类失败：Moq 不支持 mock sealed 类，得改用
virtual方法 +sealed override组合来控制可测性
替代方案：用抽象基类 + 工厂 + 静态断言更可控
如果真需要运行时确保“只有 A/B 能实例化某能力”，可以放弃继承，改用组合：
public interface IService { }
public class A : IService { }
public class B : IService { }
<p>public static class ServiceFactory
{
public static IService Create(Type type)
{
if (type != typeof(A) && type != typeof(B))
throw new InvalidOperationException("Only A and B are allowed");
return (IService)Activator.CreateInstance(type);
}
}</p>
这种方式把控制点从编译期移到运行期，但胜在明确、可调试、不依赖程序集可见性规则。继承不是银弹，有时显式工厂加类型检查反而更贴近真实约束。
真正难处理的是需要多层继承链又想卡死分支的情况——这时候往往该反思是不是设计过度耦合了。sealed 本身是终结符，不是门禁卡。
