inline是编译器内联请求而非强制指令，需定义可见于调用点；应将完整定义置于头文件中以避免ODR违规和链接错误；类内定义成员函数默认隐式inline；实际优化效果取决于编译器优化等级而非inline关键字本身。
inline 函数声明必须在所有调用点可见
内联不是强制指令，而是对编译器的请求；编译器只在函数定义（而非仅声明）可见时才可能内联。常见错误是把 inline 加在头文件中声明上，但定义放在 .cpp 文件里——这会导致链接错误或未内联。
- 正确做法：把
inline函数的完整定义（含函数体）放在头文件中 - 如果函数体太长或依赖其他翻译单元的符号，编译器大概率忽略
inline请求 - 多个翻译单元包含同一头文件时，
inline能避免 ODR（One Definition Rule）违规
不要在类定义内部随便加 inline
类内定义的成员函数默认隐式 inline，显式再写 inline 不报错但冗余。更关键的是：一旦该函数调用了尚未声明的其他函数，或用了未完全定义的类型，就可能引发编译失败。
- 例如在类 A 中定义
void f() { b.do_something(); }，但B类只前向声明、未定义，此时即使加inline也会编译失败 - 复杂逻辑、模板特化、依赖全局状态的函数，不建议塞进类体内——可读性和调试成本上升，内联收益却极低
inline 和编译器优化等级强相关
inline 关键字本身几乎不影响最终代码生成，真正起作用的是编译器优化开关（如 -O2）。关闭优化时，绝大多数 inline 请求被无视；开启后，编译器会基于函数大小、调用频率、是否递归等自动决策，甚至内联未标记 inline 的函数。
- Clang/GCC 在
-O2下会对短小函数（如 getter/setter）自动内联，无需手动加inline - MSVC 的
/Ob2才启用积极内联，/Ob1（默认）只内联显式标记的函数 - 用
__attribute__((always_inline))或[[gnu::always_inline]]可强制内联，但易导致代码膨胀，慎用
调试时 inline 函数可能“消失”
调试器通常无法在 inline 函数处设断点，或单步时直接跳过——因为函数体被展开到调用处了。这不是 bug，是内联的必然副作用。
立即学习“C++免费学习笔记（深入）”；
- 开发阶段建议先不加
inline，确认逻辑正确后再考虑性能优化 - GCC/Clang 可用
-grecord-gcc-switches保留部分内联信息，但不能恢复完整调用栈 - 若需调试，临时移除
inline或改用__attribute__((noinline))强制不内联
inline 最常被误用为“让函数更快”的银弹。它真正有价值的场景其实很窄：极短小、高频调用、无副作用的访问器，且你已通过 profiler 确认该函数是瓶颈。其余时候，交给编译器更稳妥。 
