这是编译期重载决议失败，因多个候选函数参数完全匹配导致无法选出唯一最优解，常见于自定义函数与std::max/abs等同名且使用using namespace std;引发命名空间污染。
这是编译期重载决议失败，不是语法错误，也不代表代码写错了——而是你写的调用方式，恰好让编译器在多个候选函数间无法选出唯一最优解。
为什么 abs(5) 或 max(1, 2) 会歧义
常见于和标准库函数名冲突，比如你自己写了 max 或 abs，又用了 using namespace std;。编译器看到 max(1, 2)，既找到了你定义的 max，也找到了 std::max，两者参数完全匹配，它不猜，直接报错。
- Qt、MSVC、某些 MinGW 版本对
std::max的可见性处理更激进，容易暴露这类问题；GCC 有时“侥幸”通过，不代表安全 -
abs尤其危险：<cstdlib></cstdlib>提供int abs(int)，<cmath></cmath>可能带入long long abs(long long)和double fabs(double)，但误用abs处理浮点时就可能触发多版本匹配 - 不加
::前缀、不显式限定命名空间，等于把选择权扔给编译器
怎么快速定位是哪个函数在打架
看报错信息里的 note: 行——编译器一定会列出所有它认为“可行”的候选函数，包括来自哪些头文件、模板实参推导结果、甚至迭代器类型全名（比如 __gnu_cxx::__normal_iterator<int std::vector>></int>）。
- 如果看到两个
copy候选，一个来自你写的copy模板，一个来自<algorithm></algorithm>或<stl_algobase.h></stl_algobase.h>，那就是命名空间污染 - 如果看到
abs(int)、abs(long)、abs(long long)全部列为候选，说明你包含了多个头文件（比如同时引了<cstdlib></cstdlib>和<cmath></cmath>），且没约束调用上下文 - 用
g++ -E预处理源码，搜abs或max定义位置，能快速确认冲突源头
最稳妥的修复方式
不靠删头文件、不靠赌编译器行为，从调用端明确指定意图。
- 用作用域解析符：
::abs(5)调用全局作用域的abs，std::abs(5.0)明确走<cmath></cmath>版本 - 避免
using namespace std;，尤其在头文件或全局作用域；改用using std::vector;这类精细引入 - 自定义函数改名：把
max改成my_max，把copy改成lk_copy，一劳永逸避开标准库名 - 如果必须重载整型参数（如
void func(int)和void func(long)），优先用long long统一接收，或改用模板 +std::enable_if<:is_integral_v>></:is_integral_v>
容易被忽略的平台差异点
size_t 在 32 位系统常为 unsigned int，64 位下常为 unsigned long。如果你写了 func(size_t) 和 func(unsigned long)，同一份代码在不同平台可能一个编译过、一个报歧义。
同理，std::vector::size_type、std::string::size_type 的底层类型随平台浮动，拿它们做重载参数时，务必搭配 static_cast 或统一转成 std::size_t 再传入，别依赖隐式转换路径。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
