extern template 声明需与唯一 .cpp 中的非 extern 显式实例化成对出现，仅适用于类模板和函数模板全特化，用于减少高频、大体积模板的重复实例化；定义须置于单个 .cpp 文件中以防 ODR 违规。
显式模板实例化声明（extern template）怎么写才生效
它不是“告诉编译器别实例化”，而是“告诉编译器：这个模板的某次实例化，我保证在别的 TU 里有定义，你这次跳过”。必须成对出现——声明用 extern template，定义处必须有不带 extern 的显式实例化语句。
-
extern template class std::vector<int>;</int>只在头文件或 .cpp 开头写，且仅当该 TU 确实不需生成std::vector<int></int>的代码时才加 - 对应定义必须出现在**某个且仅一个** .cpp 文件里：
template class std::vector<int>;</int>（无extern） - 如果头文件中已有
std::vector<int></int>的隐式实例化（比如调用了.size()），再加extern声明会触发链接错误——编译器跳过了，但没人提供定义 - 不能对函数模板的偏特化或变量模板（C++14）做
extern template，只支持类模板和函数模板的全特化
哪些模板适合显式实例化？看使用频次和体积
不是所有模板都值得显式实例化。重点盯两类：高频使用 + 代码膨胀明显的。
- 标准容器常见特化：如
std::vector<int></int>、std::string、std::unordered_map<:string int></:string>—— 它们在多个 .cpp 里被包含、构造、调用，每次隐式实例化都重复生成大量内联函数 - 项目自定义工具模板：如
Result<t></t>、Optional<t></t>，若T是固定几种类型（int、std::string、MyError），就值得集中实例化 - 避开泛型算法模板：像
std::sort这种按需内联的，实例化意义小；而std::regex这种模板类，一旦用到就生成几百 KB 代码，是重点目标 - 注意：显式实例化后，该特化版本的符号变成外部链接，调试时可能看不到内联展开细节，但不影响行为
显式实例化定义放哪儿？为什么不能放头文件
定义（不带 extern 的那行）必须且只能出现在一个 .cpp 文件里，否则违反 ODR（One Definition Rule）。
- 常见错误：把
template class MyContainer<double>;</double>写在头文件里 → 每个包含它的 .cpp 都生成一份，编译时间没降，链接时还报重定义 - 正确做法：新建一个
template_instantiations.cpp，集中写所有显式实例化定义；确保它被链接进最终产物（即参与构建，不被误删） - 如果项目用 CMake，记得把
template_instantiations.cpp加进对应 target，否则定义丢失，只剩extern声明 → 链接失败，报undefined reference to 'MyContainer<double>::size()'</double> - 注意：模板定义本身（比如
template<typename t> class MyContainer { ... };</typename>）仍需保留在头文件中，显式实例化不替代模板定义
和预编译头（PCH）/模块（C++20 modules）比，显式实例化有什么不可替代性
它解决的是“同一模板在多个 TU 中重复生成代码”的问题，而 PCH 解决的是“重复解析同一堆头文件”的问题；模块解决的是“头文件文本包含带来的依赖爆炸”，三者逻辑正交，能叠加使用。
立即学习“C++免费学习笔记（深入）”；
- PCH 对
std::vector无效：它缓存的是头文件解析结果，但每个 TU 仍会各自实例化模板，代码体积和编译耗时照涨 - 模块（
import std;）能减少解析开销，但不阻止模板实例化——除非你把模板定义也封装进模块并控制导出，但这要求整个生态支持模块，现实项目中难落地 - 显式实例化是目前最直接、最低侵入、编译器支持最稳的方式，GCC 4.7+、Clang 3.3+、MSVC 2015+ 全支持，且无需改构建系统
- 容易被忽略的一点：它对 LTO（Link Time Optimization）友好——因为符号已明确导出，LTO 能更早识别冗余代码并裁剪
