模板ABI不稳定源于其实例化机制，需通过非模板基类+模板外壳实现稳定：核心逻辑下沉至无虚函数/RTTI的C风格基类，模板仅作类型安全包装层，共享同一份机器码。
编译器对模板结构的转换本身不具备天然稳定性，关键在于模板是否暴露为对外接口。模板在编译期展开，不同参数生成的符号、内存布局、调用约定都可能不同，这直接破坏二进制兼容性（ABI）。所以稳定性不是编译器“保证”的，而是由代码组织方式决定的。
模板实例化导致ABI不稳定的根源
每个模板实例（如 List<int></int> 和 List<:string></:string>）会被编译器生成独立的函数符号和类型信息。这些符号经过名称修饰（name mangling）后互不兼容，且虚表布局、内联策略、异常处理帧等都可能因模板参数变化而改变。一旦作为动态库接口导出，升级模板参数就会引发运行时崩溃或链接失败。
稳定 ABI 的实现路径：非模板基类 + 模板外壳
把核心逻辑下沉到非模板类中，仅保留类型安全包装层使用模板：
- Link_base 和 List_base 是纯C风格结构与函数，无模板、无虚函数、无RTTI，符号固定、布局可控
-
List
只负责 new Link 、static_cast 类型转换、转发调用，不参与核心逻辑实现 - 所有 List
实例共享同一份 List_base::add_front 机器码，避免代码膨胀
模块化不能自动解决模板ABI问题
即使使用 C++20 模块（import），若模块导出的是模板定义而非实例化结果，各翻译单元仍可能生成不一致的模板特化版本。尤其当涉及虚继承、静态数据成员或 constexpr 初始化顺序时，跨模块模板实例仍存在布局冲突风险。模块只约束依赖可见性，不约束实例化行为。
编译器差异加剧不稳定性
Clang、GCC、MSVC 对模板实例化的优化深度、内联阈值、vtable 填充顺序均不相同。例如：
- MSVC 在 /O2 下可能将小函数全量内联，而 GCC 保留独立符号
- Clang 对递归模板展开更激进，容易触发不同深度的实例化链
- 同一份模板代码，在不同编译器+不同标准库组合下，
sizeof(List<int>)</int>都可能不同
不复杂但容易忽略
