怎么使用 sealed 关键字限制特定类只能被指定的子类继承

从现在开始，我们要努力学习啦！今天我给大家带来《怎么使用 sealed 关键字限制特定类只能被指定的子类继承》，感兴趣的朋友请继续看下去吧！下文中的内容我们主要会涉及到等等知识点，如果在阅读本文过程中有遇到不清楚的地方，欢迎留言呀！我们一起讨论，一起学习！

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 本身是终结符，不是门禁卡。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《怎么使用 sealed 关键字限制特定类只能被指定的子类继承》文章吧，也可关注golang学习网公众号了解相关技术文章。