FileStream 和 Directoryinfo 是 sealed，因其封装了操作系统句柄、缓存策略与生命周期管理等底层契约，继承易破坏资源释放顺序或绕过校验；微软借此保障 api 演进自由、提升 jit 性能，并引导组合优于继承的设计实践。
为什么 FileStream 和 DirectoryInfo 是 sealed？
因为它们不是为继承设计的——不是限制你，而是防止你误用。这些类封装了操作系统句柄、缓存策略、生命周期管理等底层契约，一旦被继承，子类极可能破坏资源释放顺序或绕过关键校验。
比如 FileStream 内部持有 SafeFileHandle，它的 Dispose 逻辑和异步 I/O 状态机深度耦合；若允许继承，子类重写 Write 却忘了同步内部缓冲区标记，就会出现数据静默丢失。
- 所有密封类都实现了完整的资源管理闭环，没有预留「钩子」（如虚方法）给子类干预
-
Path、Directory、File这些静态类更激进：连实例化都不允许，因为它们只是纯函数式工具箱 - 想扩展行为？用组合，不是继承——包装一个
FileStream到你自己的类里，加日志、加重试、加 CRC 校验都行
FileInfo 为什么没被 sealed，但几乎没人继承它？
它确实没加 sealed 关键字，但它的构造函数是 internal，且所有关键方法（OpenRead、MoveTo）都依赖私有字段 _name 和 _isNormalized，这些字段只在内部通过严格路径解析逻辑初始化。
如果你强行继承并调用基类构造器，传入非法路径（比如含 ../ 或空格），FileInfo 会在构造时直接抛 ArgumentException，根本不会让你走到实例方法那步。
- 它的非 sealed 是历史遗留（早期 .NET Framework 兼容性考虑），不是开放扩展接口
- 所有公开属性（
Length、LastWriteTime）都是 get-only，且背后调用的是Win32Native.GetFileAttributesEx，无法被子类拦截或修饰 - 试图重写
ToString()没问题，但改不了任何 I/O 行为——它不参与实际读写
密封类对 API 演进的实际影响
密封让微软能放心重构内部实现，不用考虑子类兼容性。比如 .NET 6 中 MemoryMappedFile 的创建逻辑从 Win32 CreateFileMapping 切换到更细粒度的页表控制，如果它可继承，就不得不保留一堆废弃的虚方法供子类调用，徒增维护负担。
另一个现实好处：JIT 编译器对 sealed 类的方法调用可做去虚拟化（devirtualization），把虚调用转成直接调用——尤其在高频路径如 Path.Combine 内部的字符串拼接逻辑中，这点微优化会累积出可观差异。
- 你写的泛型约束
where T : Stream在运行时仍要查虚表；但where T : FileStream不可能成立，因为它是 sealed，编译器直接报错 - 反序列化库（如 System.Text.json）遇到 sealed 类型时，跳过「找无参构造器 + 属性赋值」流程，改用 Unsafe.AsRef 直接内存拷贝，速度更快
- 第三方 Mock 框架（如 Moq）无法 mock sealed 类——这不是缺陷，是提示你：这里该测集成行为，而不是隔离打桩
什么时候真该自己写 sealed 类？
当你封装了一个明确的、不可分割的资源操作单元时。比如你写了个 AtomicFileWriter，内部用临时文件 + File.Replace 保证写入原子性，并在 Dispose 中强制刷新磁盘缓存——这个类一旦被继承，子类随便重写 Write 就可能打破原子性保证。
别为了“看起来严谨”而加 sealed；但如果你的类里有 SafeHandle、TaskCompletionSource、或依赖特定的 finalizer 顺序，那就 seal 它，顺便把构造函数设为 private，只暴露静态工厂方法。