非C场景下宏（macro）与函数的功能差异及宏的局限性问询

函数可实现但宏无法支持的核心特性（除你提到的两点外） #

• 运行时动态能力：宏是预处理/预编译阶段的纯文本替换工具，完全不感知运行时逻辑。函数可以作为一等公民被封装为函数指针传递、作为回调被动态调用、实现闭包捕获运行时变量、根据运行时参数动态调整执行分支，这些能力宏完全不具备。
• 无副作用的参数求值：函数调用时会先完成所有参数的求值，再把结果传入函数内部，不管参数带多少次副作用（比如i++这类自增操作）都只会执行一次。而宏直接替换文本，若参数在宏定义中被多次引用，对应的副作用就会执行多次，完全不符合预期，比如经典的MAX(i++, j++)宏调用会导致变量被意外多自增一次。
• 独立作用域隔离：函数有独立的栈帧作用域，内部定义的局部变量完全和外部上下文隔离，不会产生命名污染。而宏展开后直接插入到调用位置的代码上下文，宏内部用到的临时变量很容易和外部同名变量冲突，引发难以排查的逻辑错误。
• 可调试性支持：函数可以直接设置断点、查看调用栈、逐行调试，编译和运行时报错都可以精确定位到函数调用位置。宏展开后会丢失原有的行号信息，编译报错只会指向展开后的代码位置，运行时也无法直接对宏设置断点，排查问题的成本极高。
• 明确的返回与控制流语义：函数有独立的控制流，内部的return只会退出当前函数，返回值的语义清晰明确。而宏内部如果使用return会直接退出宏调用所在的外层函数，也无法像函数一样处理多分支、循环等复杂控制流，很容易因为括号、上下文匹配问题产生隐蔽bug。

大型项目全量替换为宏会遇到的无解场景 #

• 跨模块动态调用完全无法实现：动态链接库的导出函数、运行时加载的逻辑都依赖函数作为独立可寻址的代码实体，宏在预处理阶段就已经展开到调用方代码中，根本无法作为独立实体跨模块传递、动态调用。
• 运行时多态分发逻辑无法实现：面向对象中的虚函数、事件驱动架构中的回调注册、运行时策略选择等逻辑都依赖运行时的函数指针调度，宏没有运行时实体，完全无法支撑这类逻辑。
• 代码体积与编译性能爆炸：每一处宏调用都会全量展开宏定义的代码，而函数是所有调用共用一份代码实现，大型项目中全用宏会导致可执行文件体积翻数倍，预处理、编译的耗时也会大幅上升。
• 类型安全体系完全失效：没有了函数的类型校验，所有参数类型匹配全靠开发者人工保证，大型项目中会产生大量隐式类型转换错误、参数不匹配错误，排查成本高到无法接受。

内容的提问来源于stack exchange，提问作者David542