inline函数必须在每个使用它的编译单元中可见，即完整定义需置于头文件中；其本质是解决定义可见性与ODR容错性，而非强制内联或性能开关。
inline 函数必须在每个使用它的编译单元里可见
内联函数不是靠 inline 关键字“强制内联”的，而是给编译器一个建议；真正起作用的前提是：定义（不只是声明）必须对调用者可见。如果只在 .cpp 文件里写 inline void f() { ... }，其他文件调用时会链接失败——因为别的编译单元根本没见过这个函数体。
- 最稳妥的做法：把
inline函数完整定义（含函数体）放在头文件中，比如utils.h - 不能只在头文件里写
inline void f();声明，然后在 .cpp 里定义——这样定义不可见，链接时报undefined reference to 'f()' - 如果函数体太长或依赖复杂头文件，放头文件可能拖慢编译；这时得权衡：要么放弃 inline，要么拆出核心小逻辑做 inline
重复定义不会导致 ODR 违规
普通函数在多个编译单元里定义会触发 ODR（One Definition Rule）错误，但 inline 函数例外：只要所有定义完全一致（包括返回类型、参数、函数体），就可以在多个 .cpp 中包含同一个头文件并各自编译出一份副本。
- 这意味着你可以在
a.cpp和b.cpp都 #include "math_utils.h"，而其中的inline int square(int x) { return x * x; }不会报重定义 - 但如果两个头文件里定义了同名
inline函数，且函数体有细微差异（比如一个用int、另一个用long），行为未定义，编译器通常不报错但结果不可靠
什么时候加 inline 反而有害
现代编译器（GCC/Clang/MSVC）基本忽略 inline 建议，自己决定是否内联。盲目加 inline 可能带来副作用：
- 函数体过大（比如含循环、多层 if、调用其他函数）时，强行标记
inline不会内联，却让头文件膨胀，拖慢整体编译 - 调试时，
inline函数可能无法单步进入，堆栈上也看不到调用帧，排查逻辑问题更困难 - 如果函数实际被频繁调用但体积小（如 getter），不加
inline编译器通常也会内联；加了只是多一层冗余声明
模板函数默认就是 inline 的
函数模板（包括显式特化）的定义天然满足“多处定义且一致”的要求，所以不需要、也不应该手动加 inline——编译器已按 inline 规则处理。
立即学习“C++免费学习笔记（深入）”；
- 写
template<typename t> T max(T a, T b) { return a > b ? a : b; }</typename>就够了，加inline是多余甚至错误的（C++20 起某些上下文会报错） - 类内定义的成员函数（包括构造函数、operator 等）自动隐式
inline，无需再写关键字 - 只有非模板、非类内定义的自由函数，才需要你主动考虑是否加
inline并确保定义可见
inline 的本质是解决定义可见性 + ODR 容忍性的机制，不是性能开关。最容易被忽略的是：它和头文件组织强绑定，而不是贴个标签就完事。
