默认参数必须且只能在头文件的函数声明中指定，编译期绑定，不可在定义中重复；多个默认参数须从右向左连续提供；修改头文件中的默认值会触发全量重编译，并可能引发二进制不兼容问题。
默认参数只能在头文件（声明处）指定
默认参数不是“可选配置”，而是编译期绑定的契约——它必须且只能出现在函数声明中，不能在定义（.cpp 文件里的 void func(int x = 42)）里重复写。否则会触发编译错误：default argument given for parameter。
这是因为：调用方（比如另一个 .cpp 文件）只看到头文件里的声明，编译器靠它生成调用指令；如果源文件里又写一遍，默认值就可能不一致，而且毫无意义。
- ✅ 正确做法：头文件
utils.h中写void log_message(const std::string& msg, int level = 1); - ❌ 错误写法：在
utils.cpp的定义里再写void log_message(const std::string& msg, int level = 1) { ... } - ⚠️ 特别注意：如果头文件里没写默认值，但源文件里写了，调用方根本看不到，等效于没设
多个默认参数必须从右往左连续提供
C++ 不允许跳着设默认值，比如 void foo(int a, int b = 2, int c, int d = 4) 是非法的——c 没默认值却夹在两个有默认值的参数中间。编译器无法推导调用时的参数对应关系。
实际写的时候，顺序和语义要对齐。常见误区是把“经常变化的参数”放左边、把“控制开关类参数”放右边：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- ✅ 推荐：
void send_request(const std::string& url, const std::string& method = "GET", int timeout_ms = 5000); - ❌ 难维护：
void send_request(const std::string& method = "GET", const std::string& url, int timeout_ms = 5000);—— 调用时必须显式传url，method的默认值形同虚设
头文件变更会强制所有包含它的源文件重编译
默认参数是接口的一部分。一旦你修改了头文件里的默认值（比如把 int timeout_ms = 5000 改成 3000），所有包含该头文件的 .cpp 文件都得重新编译——哪怕它们压根没调用这个函数。这是隐式依赖，容易被忽略。
更麻烦的是：如果库以二进制形式分发（只有头文件 + .lib 或 .a），而用户自己改了头文件里的默认值，运行时行为就和库作者编译时假设的不一致，可能引发难以调试的逻辑错乱。
- ? 替代方案：对关键参数，考虑用重载代替默认参数，例如额外声明
void send_request(const std::string& url);，内部转调完整版 - ? 或者用结构体封装参数：
struct RequestOpts { std::string method = "GET"; int timeout_ms = 5000; };，这样默认值在构造时控制，头文件改动影响更可控
模板函数的默认参数要格外小心
函数模板的默认参数本身合法，但和模板参数推导交互时容易出问题。例如：template<typename t> void process(T value, std::string tag = "default");</typename> 看似没问题，但如果调用 process(42)，编译器能推导出 T=int，没问题；但若写成 template<typename t> void process(T value, T tag = T{});</typename>，调用 process(42) 就会失败——T{} 要求 T 可默认构造，而 int{} 合法，但用户传 process("hello") 时，T=const char*，const char*{} 不合法，直接编译不过。
- ⚠️ 核心原则：模板函数的默认参数类型最好独立于模板参数，或至少确保对所有可能推导出的
T都有效 - ✅ 更稳健写法：
template<typename t> void process(T value, std::string tag = "default");</typename>——std::string类型固定，不随T变化
