构造函数重载的参数匹配规则与普通函数完全相同，编译器不因其特殊性而改变重载解析逻辑，而是对每个实参独立进行类型匹配。
构造函数重载的参数匹配规则和普通函数完全一致，编译器不特殊对待构造函数——它只是名字特殊（与类同名）、调用时机特殊（对象创建时隐式或显式触发），但重载解析逻辑一模一样。
构造函数重载匹配按形参类型逐个比对
编译器不会看“这是构造函数”就放宽规则；它把每个重载构造函数当作普通函数处理，对每个实参独立执行类型匹配。比如：
struct S {
S(int) { std::cout
<p>那么 <code>S{42}</code> 匹配 <code>S(int)</code>（精确匹配），<code>S{3.14f}</code> 匹配 <code>S(double)</code>（<code>float → double</code> 是提升匹配），<code>S{"abc"}</code> 匹配 <code>S(const char*)</code>（字面量类型就是 <code>const char[4]</code>，退化为 <code>const char*</code>，属精确匹配）。</p>
- 每个实参单独参与匹配，不“整体权衡”
- 数组到指针、函数到指针这类退化（decay）属于精确匹配范畴，不是转换
- 引用绑定（如
const T&接收T）也算精确匹配，不触发拷贝构造
初始化列表里传 const char[] 为什么有时不匹配 const char*
看似是字符串字面量，但若你写了 S s{"hello"}; 却报错“no matching constructor”，很可能是构造函数声明为 S(std::string) 而非 S(const char*)——此时需要用户定义转换（const char[] → std::string），优先级低于精确匹配。
-
"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;，即使有委托构造函数，也会因隐式转换被禁用而报错 - 委托链中任意一环若匹配失败（如参数类型不兼容），错误位置指向委托语句，而非最终被委托的构造函数
真正容易被忽略的是：构造函数的匹配发生在对象生命周期起点，所有转换成本（尤其是用户定义转换）都会被严格计分；一旦出现两个同等“好”的候选，编译直接失败——它不会帮你猜意图，也不会退而求其次。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
