两者语义一致但编译器专用：[[msvc::forceinline]]仅MSVC识别，[[gnu::always_inline]]仅GCC/Clang识别；实际常用__forceinline和__attribute__((always_inline))，且强制内联易引发代码膨胀、调试困难等副作用。
![c++的[[msvc::forceinline]]和[[gnu::always_inline]]有什么区别？ (强制内联)](https://img.php.cn/upload/article/001/431/639/176837636562387.jpg)
两者语义一致，都是要求编译器必须内联函数，但仅对各自目标编译器生效：[[msvc::forceinline]] 只被 MSVC 识别，[[gnu::always_inline]] 只被 GCC/Clang（GNU 模式）识别。
只在对应编译器下起作用，跨编译器不兼容
MSVC 完全忽略 [[gnu::always_inline]]，GCC/Clang 则无视 [[msvc::forceinline]]。如果写成：
[[msvc::forceinline]] [[gnu::always_inline]] void foo() { }
在 MSVC 下只认第一个，在 GCC 下只认第二个——但不会报错，也不会叠加效果。实际项目中常需条件编译：
- 用
_MSC_VER检测 MSVC - 用
__GNUC__或__clang__检测 GNU/Clang - 避免混用或裸写双属性，否则容易误以为“更保险”而实际失效
行为差异：MSVC 的 forceinline 更激进
MSVC 的 [[msvc::forceinline]] 会绕过大多数内联限制（如递归、含 try/catch、过大函数体），只要语法合法就尝试强制展开；而 GCC 的 [[gnu::always_inline]] 虽也尽力，但遇到某些结构（如变长数组、嵌套 lambda 捕获复杂对象）可能静默降级为普通 inline，并给出警告（-Winline 可捕获）。
立即学习“C++免费学习笔记（深入）”；
- MSVC 不警告失败，只在 /Ob3 或 /O2+ 下生效
- Clang 对
[[gnu::always_inline]]的处理更接近 GCC，但某些版本对模板实例化内联更保守 - 二者都不保证生成汇编里真的没 call 指令——最终是否内联仍取决于后端优化阶段的判断
替代方案：__forceinline 和 __attribute__((always_inline)) 更常用
标准属性是 C++20 引入的，但实际工程中仍大量使用传统关键字：
- MSVC 下直接写
__forceinline void foo() { }，比[[msvc::forceinline]]兼容性更好（支持旧版 MSVC 2015+） - GNU 系列用
__attribute__((always_inline)) void foo() { }，Clang 也完全支持，且比[[gnu::always_inline]]解析更稳定 - C++20 属性写法目前在跨平台宏封装中反而容易漏掉编译器版本检查（如 MSVC 19.29 才开始支持
[[msvc::forceinline]]）
真正要注意的不是选哪个属性，而是内联副作用
强制内联最常被忽视的问题不是语法，而是它放大了以下风险：
- 代码膨胀：一个被频繁强制内联的函数，可能使 .obj 增大数倍，L1 指令缓存压力上升
- 调试困难：GDB/WinDbg 在内联函数里设断点可能失败，堆栈回溯丢失帧
- 链接时优化（LTO）干扰：GCC/Clang 的
-flto本身会重做内联决策，此时[[gnu::always_inline]]可能被覆盖或冲突 - 模板隐式实例化：对
template，每个 T 都生成一份内联副本，而非共享一份可复用代码[[gnu::always_inline]] void bar(T)
除非 profiler 明确指出某处函数调用开销占比显著，否则别轻易加强制内联——编译器自己的 inline heuristics 在 -O2/-O3 下通常更靠谱。
