inline函数不一定会被内联，编译器是否内联取决于优化等级、函数复杂度、调用上下文及LTO等条件；其主要作用是满足ODR而非强制内联。
inline 函数到底会不会被内联？
C++ 标准只把 inline 当作一个“建议”和链接属性标记，不是强制指令。编译器（如 GCC、Clang、MSVC）是否真正展开函数，取决于优化等级、函数体大小、调用上下文、是否跨 TU（translation unit）等。比如 -O0 下几乎不内联，而 -O2 或 -O3 下编译器会主动内联小函数——哪怕没写 inline 关键字。
- 即使加了
inline，函数体含循环、递归、虚函数调用、try/catch，大概率被忽略 - 模板函数隐式 inline，但实例化后仍受相同规则约束
- 跨源文件调用时，若未启用 LTO（Link-Time Optimization），
inline仅影响定义可见性，不保证内联
什么时候该手动加 inline？
手动加 inline 的主要价值不在“催促内联”，而在解决 ODR（One Definition Rule）违规：头文件中定义的非模板函数，必须声明为 inline，否则多个 TU 包含它会导致链接重复定义错误。
- 类内定义的成员函数（包括
operator==、get()等简单访问器）自动隐式inline，无需显式写 - 头文件里的自由函数（如工具函数
clamp()、is_power_of_two()）必须加inline才能安全包含 - 不要为了“性能”在大函数上硬加
inline，反而可能阻碍编译器的更优决策
代码膨胀怎么查？怎么压？
内联过度最直接后果是目标文件体积增大、指令缓存压力上升，尤其在嵌入式或热路径密集场景下影响明显。检查方法：
- GCC/Clang 可用
-fopt-info-vec-optimized或-fopt-info-inline输出内联决策日志 - 查看汇编输出：
g++ -S -O2 foo.cpp，搜索函数名是否还以 call 指令出现 - 使用
size或nm --print-size观察符号尺寸变化
压制策略：
立即学习“C++免费学习笔记（深入）”；
- 对确定不热的路径，用
[[gnu::noinline]]（GCC/Clang）或__declspec(noinline)（MSVC）明确阻止 - 启用
-fno-inline-small-functions或-finline-limit=N（N 过小会适得其反） - 更可靠的做法是信任编译器默认行为，只在 profile 确认 hot path 存在调用开销时，再针对性加
inline或用[[likely]]辅助分支预测
模板 + inline 容易踩的坑
模板函数天然 inline，但若在头文件中只声明不定义，或定义分散在多个头里，容易触发 ODR 违规或静默链接失败。
- 错误写法：
template声明在头文件，定义在 .cpp → 链接时报 undefined referencevoid foo(T); - 正确做法：模板声明与定义全放在头文件，并确保所有使用点都能看到完整定义
- 若需分离，可用
export template（C++03 已废弃，现代 C++ 不支持）或显式实例化（template void foo）+(int); extern template组合控制膨胀
真正难的是平衡：加太少，hot path 多余 call；加太多，cache miss 上升、构建变慢、调试信息混乱。实际项目里，先关掉所有手写 inline，跑 perf + size 分析，再动刀。
