內聯不是萬能藥：代碼膨脹的代價
內聯以**代碼復制**換取**調用開銷消除**。若函數體執行時間 ≫ 調用開銷，收益微乎其微；若到處內聯大函數，指令緩存未命中率飆升，反而**降低性能**。
四大不宜內聯場景
- 函數體較長：超過 10-20 行，編譯器通常拒絕，強制內聯會嚴重膨脹代碼；
- 包含循環/遞歸/複雜控制流：執行時間主導，內聯收益極低；
- 構造/析構函數：隱含基類/成員構造析構調用，實際體積遠大於可見代碼，**極易誤判**；
- 虛函數：動態分發本質上無法內聯（除非編譯器去虛擬化成功）。
編譯器拒絕內聯的連鎖災難
現象：頭文件定義 inline void Foo() { for(...) ... }，多 .cpp 包含
- 編譯器拒絕內聯 → 生成普通函數代碼；
- 每個編譯單元生成一份拷貝；
- 舊編譯器：隱式視為
static，各自可見，鏈接通過但留下多份拷貝（代碼膨脹、調試混亂）；
- 新標準 (C++11+)：要求單一定義，鏈接報錯「多重定義」；
- 結果：性能未提升，編譯/鏈接時間增加，可執行文件變大。
維護噩夢：接口變更引發全量重編譯
- 內聯函數修改 → 所有包含頭文件的 .cpp **必須重新編譯**；
- 非內聯函數修改 → 僅重新編譯實現 .cpp，**僅需重新鏈接**；
- 大型專案中，核心頭文件的內聯函數變更 = 全量重建 = 數十分鐘浪費。
調試體驗下降
- 內聯函數無調用幀，**無法設置斷點、無法單步進入、變量觀察困難**；
- 優化建構下變量被優化掉，調試信息不全。
編譯器智能化：別與編譯器搶活
- 現代編譯器 (GCC/Clang/MSVC) 基於 **Profile-Guided Optimization (PGO)**、**Link-Time Optimization (LTO)** 自動決定內聯；
- 人工標記
inline 往往不如編譯器全局視野決策優；
- 建議：僅在**極小、頻調、非虛、無循環**函數上保留
inline，其餘交給編譯器。
強制內聯：最後手段
// MSVC
__forceinline void critical_func() { ... }
// GCC/Clang
__attribute__((always_inline)) void critical_func() { ... }
// 僅在極少數經 Profile 證實的熱點使用，濫用必反。
結語
**內聯函數不是性能銀彈**。理解其代價（膨脹、編譯依賴、調試困難）、編譯器拒絕行為、維護成本，**養成「默認不加 inline，熱點經測試再加」的習慣**。現代 C++ 依賴 -O2/-O3 -flto -fprofile-generate/use 讓編譯器全局優化，遠勝手工微調。
