ADL触发需同时满足：一是未限定函数调用（如foo(x)），二是至少一个实参为用户定义类型；内置类型单独出现不触发ADL。
ADL 查找触发的两个必要条件
ADL 不是“自动开启”的名字查找，它只在特定条件下被激活：一是调用形式必须是「未限定函数调用」（即不带作用域前缀，如 foo(x) 而不是 ::foo(x) 或 ns::foo(x)）；二是至少一个实参的类型属于用户定义类型（class、struct、union 或枚举），内置类型（如 int、double）单独出现不会触发 ADL。
常见错误现象：std::vector 能工作，但 int a, b; swap(a, b); 会编译失败——因为 int 是内置类型，ADL 不启动，而全局作用域又没声明 swap。
- 只有「未限定调用 + 至少一个用户定义类型实参」才触发 ADL
- 多个实参时，ADL 会合并所有实参关联的命名空间（包括类定义所在命名空间、其外围命名空间等）
- 如果实参是类模板特化（如
std::string），关联命名空间包含std；但std::vector的关联命名空间仍是std，不是std::vector（后者不是命名空间）
关联命名空间（associated namespaces）怎么确定
ADL 不是“查实参类型的命名空间”这么简单。对每个实参类型 T，编译器会收集一组「关联命名空间」，规则有明确优先级：
- 若 T 是类类型，直接包含其定义所在的命名空间（含嵌套类的外围命名空间）
- 若 T 是类模板特化（如
MyVec），还加入模板定义所在命名空间 - 若 T 是内建指针或引用（如
T*、T&），递归检查T的关联命名空间 - 若 T 是数组（
T[N]），也递归检查T - 枚举类型则取其定义所在命名空间（C++11 起支持枚举参与 ADL）
示例：namespace N { struct X {}; void f(X) {} } N::X x; f(x); 成功，因为 X 的关联命名空间是 N，f 在其中可见。但 void g(N::X) {} 放在全局作用域，则 g(x) 仍失败——ADL 不看调用点附近，只看实参类型能“拉出哪些命名空间”。
立即学习“C++免费学习笔记（深入）”；
ADL 和普通作用域查找（unqualified lookup）谁先谁后
两者不是“先后顺序”，而是「并行收集 + 合并重载集」。编译器先做普通未限定查找（从调用点逐层向外找），再做 ADL（收集关联命名空间中的候选），最后把两批函数合并成一个重载集合，再统一进行重载解析。
关键影响：如果普通查找已找到函数，ADL 找到的同名函数仍会参与重载；但如果普通查找找到了非函数（比如变量 int foo;），整个查找就失败，ADL 根本不启动。
-
void foo(int); namespace N { struct S {}; void foo(S); } void bar() { foo(42); }—— 只调用foo(int)，N::foo不参与，因为int不触发 ADL -
int foo; namespace N { struct S {}; void foo(S); } void bar() { foo(S{}); }—— 编译错误，因为普通查找先找到变量foo，名字已绑定为非函数，ADL 被跳过 - ADL 找到的函数可能比普通查找的更匹配，最终胜出（这是
std::swap专用化的基础）
为什么 std::cout 能工作，但自己写流操作符要放对地方
operator 是典型的 ADL 依赖场景。标准库中，std::ostream& operator 定义在 std 命名空间里，而 std::string 的关联命名空间就是 std，所以 std::cout 触发 ADL 并找到它。
你自己定义 operator 时，如果把它放在全局作用域，而实参类型（比如 MyType）定义在 namespace M 中，ADL 就找不到它——因为 MyType 的关联命名空间只有 M，不包含全局作用域。
- 正确做法：把
operator 定义在MyType所在的命名空间M内（哪怕它是友元函数） - 错误做法：定义在全局、或另一个无关命名空间，即使函数签名完全匹配，ADL 也视而不见
- 别试图用
using M::operator 拉到调用点——这只能帮普通查找，对 ADL 无效
最易忽略的一点：ADL 不跨命名空间“推导”，它只信任实参类型明确定义的归属；你不能靠“逻辑相关”让编译器猜，它只按标准白纸黑字收集合。
