重载函数调用失败主因是参数类型歧义：char、0、整数字面量等在多组重载间存在多个可行但不可比的转换路径，导致编译器无法选出唯一最佳匹配，从而报错ambiguous。
重载函数调用失败，往往不是因为写错了函数名，而是参数类型“太像”——编译器在 char、int、double、nullptr 这些类型之间找不到唯一最优解。
为什么 print('A') 会编译失败？
当存在 void print(int) 和 void print(double) 两个重载时，传入字符字面量 'A'，编译器会尝试匹配：
-
char → int是提升匹配（promotion），属于第二优先级 -
char → double是标准转换（conversion），属于第三优先级
但问题在于：C++ 标准规定，char 到 int 和 char 到 double 的转换路径**不构成可比优劣**——因为两者都不是精确匹配，且提升和标准转换属于不同类别，编译器不会跨类比较“哪个损失更小”。结果就是：两个都可行，但无法选出唯一最佳，报错 call to 'print' is ambiguous。
print(0) 为何可能匹配 int* 和 const char*？
整数字面量 0 在 C++98/03 中是 int，但它也满足 nullptr 的历史等价性（尤其在未启用 -std=c++11 或更高标准时）。如果同时定义了：
void print(int*)void print(const char*)
那么 print(0) 就可能被解释为 int*（0 隐式转空指针）或 const char*（0 作字符串字面量空指针），两者都是标准转换，权重相同 → 歧义。
现代写法应显式用 nullptr 或 static_cast<const char>(0)</const> 消除歧义，避免依赖 0 的双重身份。
float/double 重载组合最容易踩坑
声明 void func(float) 和 void func(double) 看似合理，但实际调用时：
-
func(3.14)→ 匹配double（字面量默认是double） -
func(3.14f)→ 匹配float -
func(3)→int → float和int → double都是标准转换，无法区分
这种组合几乎必然在整数或未标注字面量场景下触发歧义。更安全的做法是只保留一个浮点版本（如 double），或用模板 + std::enable_if 限制输入类型。
const 引用 vs 值参数的匹配优先级陷阱
考虑：
void f(int)void f(const int&)
调用 f(5) 会选择 int 版本，而非引用版——因为值传递是精确匹配，而绑定到 const 引用需一次“左值转换”，优先级略低。但若把第一个改成 void f(long)，f(5) 就变成 int → long（标准转换） vs int → const int&（精确匹配的引用绑定），这时反而会选引用版。
这种微妙差异意味着：**加 const 引用重载不等于“兜底”，它可能意外抢走本该给值参数的调用**，尤其在有类型提升或转换链时。
真正难处理的不是“看不懂规则”，而是多个重载函数在边界输入（'x'、0、42、3.14f）上同时具备可行转换路径。一旦出现歧义，编译器不会猜测你的意图，只会报错。最稳妥的方式，是在设计重载集时主动砍掉易冲突的组合，而不是靠调用方加 static_cast 补救。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
