宏是预处理文本替换，存在优先级错误、多次求值、无类型检查等隐患；inline函数在编译阶段处理，类型安全、可调试、支持重载与IDE功能，应优先替代宏。
宏定义是预处理阶段的无脑文本替换，inline函数是编译阶段的类型安全函数——这不是风格偏好问题，而是是否能编译通过、是否产生隐蔽 bug 的分水岭。
宏展开导致运算符优先级错误和多次求值
宏不经过语法解析，只做字面替换，#define SQUARE(x) x * x 看似简单，但 SQUARE(3 + 2) 展开为 3 + 2 * 3 + 2，结果是 11 而非 25；更危险的是副作用： #define MAX(a, b) ((a) > (b) ? (a) : (b)) 遇到 MAX(++x, 10) 时，++x 会被执行两次。
而 inline int square(int x) { return x * x; } 和 inline int max(int a, int b) { return a > b ? a : b; } 中，参数只求值一次，表达式按正常语义计算，无需手动加括号防坑。
- 宏必须手动为每个参数和整个表达式加括号，漏一个就可能出错
- inline 函数天然规避优先级和副作用问题，编译器按 C++ 规则求值
- 宏在复杂表达式（如位运算、自增/自减）中极易翻车，inline 不会
宏没有类型检查，inline 函数强制类型匹配
宏对传入的任何东西照单全收：MAX(5, "hello") 在预处理后变成字符串字面量与整数的比较，编译器报错位置指向展开后的代码行，而非宏调用处，排查困难；而 max(5, "hello") 直接在调用点报错：无法将 const char* 转换为 int。
立即学习“C++免费学习笔记（深入）”；
- 宏的“灵活性”实为隐患，它绕过所有类型系统
- inline 函数参与重载决议，支持模板实例化，可被 IDE 正确识别签名
- 类内
inline成员函数能访问private/protected成员，宏做不到
宏无法调试，inline 函数可以设断点和单步
调试器看不到宏——它在源码到达编译器前就被替换了。你在 LOG("value = %d", x) 上打不了断点，错误栈里也不会出现宏名；而 inline void log(const char* fmt, int val) 在未开启优化时，完全支持断点、变量监视、调用栈回溯。
- 调试时宏等于“消失”，inline 函数和普通函数行为一致
- 启用
-O2后，编译器仍可能保留 inline 函数的调试信息（取决于具体实现） - IDE 的跳转、重命名、查找引用等功能对宏基本失效，对 inline 函数完全可用
inline 是建议，不是保证；宏是强制，但不可控
inline 关键字只是向编译器提出请求，是否真正展开由其自主决定：函数体含循环、递归、异常、虚函数调用，或体积过大时，编译器大概率忽略该建议，退化为普通函数调用；而宏不管上下文，只要见到就替换，哪怕生成几百行重复代码。
- 把
inline放在声明上（如inline void f();）无效，必须放在函数定义处 - 类内定义的成员函数（如
struct S { int get() { return x; } };）默认inline，无需显式写 - 宏的“高效”是假象——它可能导致严重代码膨胀，且无法被链接器去重
真正需要宏的地方极少：条件编译（#ifdef DEBUG）、字符串化（#define STR(x) #x）、assert 这类必须在预处理阶段介入且不能有副作用的场景。除此之外，凡是想用宏实现“轻量函数”的地方，都应该用 inline、constexpr 或普通函数替代。
