C++原生不支持命名参数，因其破坏重载解析、模板推导和ABI稳定性；常用模拟方案有结构体指定初始化（C++20）和Builder模式，二者兼顾可读性与类型安全，无需宏或黑魔法。
为什么C++原生不支持命名参数
C++标准至今没引入命名参数语法（比如 Python 的 func(a=1, b=2)），根本原因是它在编译期做静态类型检查和函数重载解析，而命名参数会破坏参数位置与形参声明的严格对应关系，影响重载决议、模板推导和 ABI 稳定性。所以所有“模拟”方案都是在语法糖层面做文章，本质仍是位置传参或构建中间对象。
用结构体 + 默认成员初始化实现最简模拟
这是最轻量、无依赖、兼容 C++11 起的写法，适合参数少且不频繁变更的场景。核心是定义一个具名字段的结构体，每个字段带默认值，再让函数接受该结构体：
struct HttpRequestOpts {
std::string url = "";
int timeout_ms = 5000;
bool follow_redirects = true;
std::string user_agent = "cpp-client/1.0";
};
void send_request(const HttpRequestOpts& opts) {
// 使用 opts.url, opts.timeout_ms 等
}
调用时可只设置关心的字段：send_request({.url="https://api.example.com", .timeout_ms=3000});（C++20 指定初始化）或老式写法 send_request({"https://...", 3000, true, ""});。注意：C++20 指定初始化要求字段顺序与定义一致，否则编译失败；C++11/14 只能靠构造函数或赋值方式模拟，略繁琐。
用 Builder 模式支持链式调用和部分参数覆盖
当参数多、组合复杂、或需复用配置时，Builder 更灵活。它把参数设为私有成员，提供返回 *this 的 setter 方法：
立即学习“C++免费学习笔记（深入）”；
struct HttpRequestBuilder {
std::string url_;
int timeout_ms_ = 5000;
bool follow_redirects_ = true;
HttpRequestBuilder& url(const std::string& u) { url_ = u; return *this; }
HttpRequestBuilder& timeout(int ms) { timeout_ms_ = ms; return *this; }
HttpRequestBuilder& follow_redirects(bool v) { follow_redirects_ = v; return *this; }
void send() const {
// 实际发送逻辑，使用 url_, timeout_ms_, etc.
}
};
调用：HttpRequestBuilder().url("https://...").timeout(2000).send();。优势是语义清晰、可读性强、易于扩展；但要注意：每个 setter 返回引用，不能用于临时对象绑定到 const 引用（如 const auto& b = HttpRequestBuilder().url(...); 是悬垂引用），且 builder 对象本身不带状态校验，错误参数可能到 send() 才暴露。
宏或模板技巧的局限与风险
网上有些用宏（如 MAKE_NAMED_ARGS）或模板参数包展开来“伪造”命名语法，例如 call_with_named_args(func, _url="...", _timeout=2000)。这类方案通常依赖预处理器拼接或 SFINAE 推导字段名，实际效果差：
- 调试困难：宏展开后错误信息指向生成代码而非原始调用行
- IDE 支持弱：跳转、补全、重命名几乎失效
- 无法处理同名字段冲突（比如两个结构体都有
id） - C++20 后
requires和auto参数虽可增强约束，但依然无法真正实现语言级命名绑定
除非嵌入式等极端受限环境且团队完全掌控工具链，否则不建议在生产项目中引入这类黑魔法。
真正关键的不是“怎么写得像命名参数”，而是“怎么让调用者一眼看懂每个参数含义、默认值和约束”。结构体初始化和 Builder 已足够覆盖绝大多数需求；过度追求语法拟真反而增加维护成本。C++ 的强类型和编译期检查，本就更适合用明确的命名类型来承载意图，而不是靠调用时的伪关键字。
