模板函数实例化发生在编译期而非链接期，编译器仅在遇到具体调用（如add(1,2)）时，才根据实际类型生成对应函数代码；若定义不在头文件中，因翻译单元不可见会导致链接失败。
模板函数实例化发生在编译期，不是链接期
编译器看到 template<typename t> T add(T a, T b)</typename> 这种声明时，不会生成任何机器码；只有当它在某个 .cpp 文件里遇到 add(1, 2) 或 add<double>(1.0, 2.0)</double> 时，才根据当前类型“现场生成”一份具体函数（比如 int add(int, int)）。这个生成动作必须在该 .cpp 文件的编译阶段完成。
如果把 add 的定义写在 add.cpp 里，那么 main.cpp 只能看到声明、看不到实现，编译器就无法生成 int 版本的代码——它不会去“跨文件查找实现”，也不会把生成任务留给链接器。结果就是：编译通过，链接失败，报 undefined reference to 'add<int>'</int>。
头文件是让定义“对每个翻译单元可见”的最直接方式
把模板函数的声明和定义都放进 my_math.hpp，再在 main.cpp 里 #include "my_math.hpp"，预处理器会把整个定义文本原样插入到 main.cpp 编译前的内容中。这样编译器在处理 main.cpp 时，就天然拥有了生成实例所需的全部信息。
常见组织方式包括：
立即学习“C++免费学习笔记（深入）”；
- 全放在一个
.hpp文件里（最简单，适合中小型项目） - 声明在
.hpp，实现写在同目录下的.tpp，并在.hpp末尾加#include "my_math.tpp"（逻辑更清晰，仍满足“可见性”要求） - 避免用
.inl后缀——它容易被 IDE 或构建系统误判为非源文件而忽略
显式实例化能绕过头文件限制，但代价明确
你可以在 add.cpp 里写 template int add<int>(int, int);</int> 和 template double add<double>(double, double);</double>，这样编译器就会为这两个类型生成代码并导出符号。其他文件只要声明不实现，也能链接成功。
但要注意：
- 所有要支持的类型必须提前写死，用户无法用
add<mycustomtype></mycustomtype> - 如果某处用了未显式实例化的类型（比如
add<long long></long>），依然会链接失败 -
extern template声明可配合使用，减少重复实例化开销，但不能解决泛型需求
别信“export template”，它早已被主流编译器放弃
C++98 曾引入 export 关键字试图支持模板分离编译，但因实现复杂、编译器支持差、性能不可控，GCC 从 3.9 起移除，Clang 从未支持，MSVC 也从未完整实现。现在所有标准文档和编译器手册都视其为废弃特性。把它当真，只会浪费调试时间。
真正需要隐藏实现细节时，应考虑非模板接口封装（如 PIMPL）或编译期多态替代方案（如 std::function + lambda），而不是强求模板定义进 .cpp。
