在设计基础库或跨平台框架时，一个反复出现的问题是：如何构建抽象层。
典型场景包括：
-
GUI 框架（Windows / macOS / Linux）
-
图形 API（OpenGL / DirectX / Vulkan）
-
数据库访问接口
-
图像处理框架
-
操作系统适配层
这些系统具有一个共同特征：底层实现差异明显，但上层应用希望使用统一接口 。
因此我们往往需要构建一层抽象。然而实践很快会遇到一个经典困境：
-
如果抽象取功能交集，接口往往过于贫弱
-
如果抽象取功能并集，接口又会迅速膨胀
这个问题在跨平台架构中非常普遍。
经过长期工程实践，可以将一种常见的解决方式总结为一种结构模式：三层抽象结构（Three-Layer Abstraction Structure） 。
这一结构是一种在许多成熟系统中反复出现的设计形态。
一、核心抽象（Core Abstraction）
第一层是系统的核心抽象。
这一层只包含：
-
语义稳定的操作
-
几乎所有实现都能支持的能力
-
使用频率最高的功能
例如在 GUI 系统中，核心抽象可能只包含：
Window
Button
ScrollBar这些对象通常只暴露最基础的行为，例如：
Show
Hide
Resize
SetText核心抽象的目标并不是完整表达底层系统能力，而是提供一个稳定且可预测的接口集合。
在实践中，一个经验原则是：
只有当某个能力同时满足"平台普遍支持、使用频率高、语义稳定"时，才进入核心抽象。
核心抽象的设计目标通常是解决 大多数常见问题，而不是所有问题。
二、能力扩展（Capability Extension）
现实系统中总会存在一些能力：
-
只有部分平台支持
-
但在某些场景下十分重要
例如：
-
Windows 的 OwnerDraw 控件
-
GPU 加速能力
-
特定窗口管理策略
如果这些能力全部加入核心抽象，接口很快会变得庞大而不稳定。
因此一种常见做法是：将这些能力放入扩展层。
扩展层通常以"能力接口"的形式出现，例如：
IOwnerDrawButton
IHardwareAccelerated
IHighDPISupport具体实现可以根据平台选择性支持这些能力。
调用方可以通过能力检测使用扩展功能：
if(button supports IOwnerDrawButton)
...核心接口保持稳定，而平台特性通过能力扩展暴露。
扩展层的作用是：在不破坏核心抽象稳定性的前提下，逐步引入系统能力。
三、原生逃逸（Native Escape Hatch）
即使存在扩展层，抽象仍然无法覆盖所有需求。
当开发者需要：
-
调用平台特有 API
-
使用特殊功能
-
进行性能优化
抽象层必须允许访问底层系统。
因此许多框架都会提供一种"逃逸通道"，例如：
GetNativeHandle
GetPlatformObject通过这种方式，开发者可以在必要时直接调用底层 API。
这种设计是对一个重要事实的承认：
任何非平凡抽象都会在某些情况下泄漏底层细节。
这一观点被称为 Leaky Abstraction 定律。
因此成熟框架往往不会试图完全隐藏底层系统，而是允许在必要时突破抽象。
四、三层抽象结构
综合上述三个层级，可以得到一种常见的抽象结构：
Core Abstraction
↓
Capability Extension
↓
Native Escape Hatch三层各自承担不同职责：
|------------------|------------|
| 层级 | 作用 |
| Core | 提供稳定、通用的接口 |
| Extension | 暴露平台能力 |
| Escape Hatch | 允许直接访问底层系统 |
这种结构并不依赖某个特定设计模式，但在实现时通常会结合多种模式，例如：
-
Bridge：分离抽象层与实现层两个维度
-
Adapter：接入不同平台 API
-
Abstract Factory：创建组件族
这些模式共同支撑整个抽象体系。
五、为什么这种结构会反复出现
复杂系统中的抽象，本质上是一种信息压缩。
假设我们面对多个底层系统：
System A
System B
System C每个系统都包含各自的能力集合：
A = a1 a2 a3
B = a1 a2 b3
C = a1 c2 c3当我们构建统一抽象时，实际上是在做一件事：
将多个系统的能力压缩到同一个接口集合中。
如果只保留交集
a1抽象会变得过于贫弱，难以满足实际需求。
如果直接保留并集：
a1 a2 a3 b3 c2 c3抽象又会变得庞大且难以实现。
因此，在长期工程实践中，人们逐渐形成一种折衷策略：
-
将稳定且普遍存在的能力沉淀为核心抽象
-
将具有平台差异的能力通过扩展方式逐步暴露
-
同时保留一种机制，使系统在必要时仍然能够访问底层实现
从这个角度看，所谓"三层抽象结构"并不是人为设计出来的模式，而更像是一种在复杂系统中自然演化出的结构形态。
它的本质是：在压缩系统复杂度的同时，仍然保留访问原始信息的能力。
正因为这个问题在许多系统中都会出现，所以类似的结构在不同框架中不断重复出现。
结语
抽象层设计的难点不在于接口形式，而在于抽象边界的确定。
"三层抽象结构"提供了一种讨论边界的共同语言：当我们设计抽象层时，可以先明确哪些能力属于 Core （长期稳定、跨平台一致）、哪些应该放进 Extension （可选能力、按需暴露差异）、以及哪里需要保留 Escape Hatch（承认泄漏、允许突破）。
把这三个层级说清楚，很多争论就会从"该不该加一个接口"转变为"这个能力应该落在哪一层"。将其作为设计词汇，我们就能在讨论系统抽象时，从更高的起点表达架构意图，并更快达成一致。