显式模板实例化通过编译期提前生成并共享模板代码来减少链接器去重开销。它需配对使用extern template声明与唯一显式定义，适用于高频标准容器、确定业务类型及编译耗时模板，但要求类型完全一致且避免ODR违规。
显式模板实例化本身不加速链接，它让链接器少干活——通过提前把重复代码合并掉，避免链接期去重开销。
为什么链接慢？因为链接器在“擦屁股”
当你把模板实现全塞头文件里，20 个 .cpp 都用 std::vector<int></int>，编译器就生成 20 份一模一样的 std::vector<int></int> 机器码。链接器最后得扫描所有目标文件，找出这 20 份重复符号，再合并成一份。项目越大，这个“找+验+删”的过程越耗时。
显式实例化把这件事提前到编译期：只在一个 .cpp 里写 template class std::vector<int>;</int>，其他地方用 extern template class std::vector<int>;</int> 告诉编译器“别生成，去别处找”。结果是：目标文件里只有 1 份定义，链接器直接拿过去用，跳过去重流程。
必须配对使用 extern template 和显式定义
只加 extern template 不提供定义，链接时会报 undefined reference；只加显式定义不加 extern，其他编译单元照旧生成副本，白忙活。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
-
vector_fwd.h（头文件）：声明extern template class std::vector<int>;</int> -
vector_inst.cpp（唯一源文件）：定义template class std::vector<int>;</int> - 所有使用
std::vector<int></int>的.cpp都先包含vector_fwd.h
注意：extern template 必须出现在使用点之前，且不能和定义在同一翻译单元。
哪些类型值得显式实例化？
不是所有模板都适合。重点盯住三类：
- 高频使用的标准容器/算法，比如
std::vector<int></int>、std::string、std::unordered_map<:string int></:string> - 项目内封闭接口中确定的业务类型，如
Buffer<float></float>、Serializer<jsonnode></jsonnode> - 编译耗时大户，比如带大量 SFINAE 或 constexpr 计算的模板，显式实例化能省下重复解析时间
泛型工具类、仅内部临时使用的模板，没必要动——维护成本高，收益低。
容易踩的坑
最常被忽略的是“一致性”：
- 显式实例化的类型必须和实际使用完全一致，
std::vector<int></int>和std::vector<const int></const>是两个不同实例 - 如果用了自定义分配器，
std::vector<int myalloc></int>必须单独显式实例化，不会被std::vector<int></int>覆盖 -
extern template声明必须和定义的签名一字不差，包括调用约定、noexcept、模板参数默认值等 - 不要在头文件里写显式定义，否则多个
#include触发 ODR 违规，链接时报multiple definition
显式实例化不是银弹——它把编译期压力转移到了工程组织上：你得准确预判哪些类型会被用，还得确保定义只出现一次、声明处处到位。一旦漏掉某个常用组合，链接错误就回来了。
