构造函数重载的参数匹配规则与普通函数完全相同，编译器不因其特殊性而改变重载解析逻辑，而是对每个实参独立进行类型匹配。
构造函数重载的参数匹配规则和普通函数完全一致，编译器不特殊对待构造函数——它只是名字特殊（与类同名）、调用时机特殊（对象创建时隐式或显式触发），但重载解析逻辑一模一样。
构造函数重载匹配按形参类型逐个比对
编译器不会看“这是构造函数”就放宽规则；它把每个重载构造函数当作普通函数处理，对每个实参独立执行类型匹配。比如：
struct S {
S(int) { std::cout << "int\n"; }
S(double) { std::cout << "double\n"; }
S(const char*) { std::cout << "cstr\n"; }
};
那么 S{42} 匹配 S(int)（精确匹配），S{3.14f} 匹配 S(double)（float → double 是提升匹配），S{"abc"} 匹配 S(const char*)（字面量类型就是 const char[4]，退化为 const char*，属精确匹配）。
- 每个实参单独参与匹配，不“整体权衡”
- 数组到指针、函数到指针这类退化（decay）属于精确匹配范畴，不是转换
- 引用绑定（如
const T&接收T）也算精确匹配，不触发拷贝构造
初始化列表里传 const char[] 为什么有时不匹配 const char*
看似是字符串字面量，但若你写了 S s{"hello"}; 却报错“no matching constructor”，很可能是构造函数声明为 S(std::string) 而非 S(const char*)——此时需要用户定义转换（const char[] → std::string），优先级低于精确匹配。
立即学习“C++免费学习笔记（深入）”；
-
"hello"类型是const char[6]，可精确匹配const char*（退化），但不能精确匹配std::string - 若只声明了
S(std::string)，则必须调用std::string的构造函数，属于“用户定义转换”，优先级排第四 - 若有
S(const char*)和S(std::string)同时存在，"hello"会选前者，因为精确匹配 > 用户定义转换
带默认参数的构造函数容易引发二义性
默认参数不改变重载解析的基本流程，但会让多个构造函数在相同实参下都“可行”，从而触发歧义错误。
struct T {
T(int = 0) {}
T(double = 0.0) {}
};
T t{} 或 T t; 都会失败：两个构造函数都接受零实参（靠默认值补全），且匹配等级相同（都是精确匹配空参数列表），编译器无法选唯一最佳。
- 默认参数让形参“可省略”，但不降低该构造函数的匹配权重
- 哪怕只有一个实参，如
T{5L}（long），也可能同时匹配T(int)和T(double)（long → int和long → double都是标准转换，权重相同）→ 二义性 - 用
explicit可阻止隐式转换参与匹配，但不影响显式构造调用
委托构造函数不影响外层匹配过程
委托构造函数（如 S() : S(42) {}）只是语法糖，不参与外层重载解析。编译器先决定调用哪个顶层构造函数，再由它内部决定是否委托。
- 写
S s;时，编译器只看有哪些无参构造函数可用，委托关系完全不暴露给调用点 - 委托目标本身仍要满足匹配规则：若
S(int)是explicit，而你写S s = 42;，即使有委托构造函数，也会因隐式转换被禁用而报错 - 委托链中任意一环若匹配失败（如参数类型不兼容），错误位置指向委托语句，而非最终被委托的构造函数
真正容易被忽略的是：构造函数的匹配发生在对象生命周期起点，所有转换成本（尤其是用户定义转换）都会被严格计分；一旦出现两个同等“好”的候选，编译直接失败——它不会帮你猜意图，也不会退而求其次。
