宏非类型安全，是编译前纯文本替换；模板支持类型推导与语义检查，二者抽象层级不同。宏用于头文件卫士、日志、断言等预处理场景，模板适用于泛型编程。
宏在C++里根本不是类型安全的，别拿它模拟模板
宏是纯文本替换，发生在编译前；模板是编译期类型推导，有完整语义检查。两者根本不在一个抽象层级上——用 #define 模拟 std::vector 或 std::max，等于主动放弃编译器帮你拦错的机会。
常见错误现象：MAX(a++, b) 展开后变成 ((a++) > (b) ? (a++) : (b))，a 被自增两次；而 std::max(a++, b) 编译直接报错（因为右值不能绑定到非 const 引用）或行为明确（取决于重载版本）。
- 宏不参与作用域、不支持重载、无法调试（调试器看不到宏展开后的逻辑）
- 模板能推导
const、引用、cv 限定符，宏连int*和int&都分不清 - 宏定义中写
##或#运算符容易漏空格、引号不匹配，报错信息指向“未知位置”
什么时候还必须用宏：头文件卫士、日志、断言
模板解决不了预处理阶段的问题。比如防止重复包含，#ifndef/#define/#endif 是唯一可靠方式；又比如记录文件名和行号的调试日志，__FILE__ 和 __LINE__ 只能在宏里展开。
使用场景示例：LOG_INFO("value = %d", x) 展开为 fprintf(stderr, "[INFO] %s:%d value = %d\n", __FILE__, __LINE__, x)——这里 __FILE__ 必须在调用点展开，模板函数做不到。
立即学习“C++免费学习笔记（深入）”；
-
assert依赖宏：失败时要打印触发它的源码位置，模板函数调用栈里只显示函数名，没有原始行号 - 跨平台条件编译（如
#ifdef _WIN32）无法用模板替代 - 宏可以拼接标识符（
CONCAT(foo, bar)→foobar），模板无法生成新符号名
模板特化比宏分支更安全，但要注意全特化与偏特化的规则
用宏做类型分支（#if defined(__x86_64__)）看似简单，实则绕过类型系统，容易在模板实例化后才暴露问题；而模板特化把类型约束提前到编译期检查。
参数差异关键点：template<> struct hash<MyType> 是全特化，必须显式指定所有模板参数；而 template<typename T> struct hash<T*> 是偏特化，只对指针类型生效——宏做不到这种细粒度匹配。
- 偏特化不能用于函数模板（C++17 前），只能靠重载，这点常被忽略
- 全特化必须在主模板定义之后声明，否则编译器可能选错重载
- 宏里的
#ifdef分支不会影响模板实例化结果，但可能让某些特化根本没被编译到（导致链接失败）
宏 + 模板混用的坑：#include 顺序、宏污染、延迟实例化
最典型的翻车现场：某个头文件里用 #define min(a,b) ((a)，然后你 <code>#include <algorithm> 后调用 std::min，结果宏把 std::min 的声明或定义给污染了，编译失败或行为异常。
性能影响不大，但兼容性灾难：Windows SDK 头默认定义 min/max 宏，和 STL 冲突；Qt 的 foreach 宏也会干扰范围 for 语法。
- 用
#undef min临时取消宏？危险——其他头可能依赖它，且顺序难控 - 推荐方案：在包含系统头之前加
#define NOMINMAX（Windows），或用using std::min显式拉入命名空间 - 模板的延迟实例化会让宏污染更隐蔽：宏定义在模板定义时不起作用，但在某处实例化时才触发，报错位置和源头差很远
真正难的是边界感——宏管“代码长什么样”，模板管“代码怎么运行”。混用时，得清楚哪一层该谁负责，而不是想着“都用宏搞定”或者“全换成模板就安全了”。
