编译器查找标识符的默认顺序是：先当前局部作用域，再外层作用域（含全局作用域），不自动进入未显式引入的命名空间；查不到报错，查到多个则歧义。
直接看编译器怎么找名字：它不“猜”，只按固定路径查，查不到就报错，查到多个就歧义。
编译器查找标识符的默认顺序是啥？
编译器在解析 a、foo() 这类名字时，根本不管“哪个更合理”，只机械执行作用域链查找：
- 从当前最内层块（比如
{}里）开始，找有没有声明 - 没有就往外一层（比如函数体），再找
- 再到外层命名空间（含全局命名空间
::） -
跳过其他命名空间：比如你在
namespace A里写bar()，编译器不会去namespace B里翻bar，哪怕它存在
这意味着：int x = 1; 在函数内声明后，即使全局也有个 int x = 0;，函数里用的永远是局部那个——不是“覆盖”，而是“遮蔽（shadowing）”。
同名函数在不同命名空间里为啥不冲突？
因为命名空间本质是编译期加前缀，A::foo 和 B::foo 在符号表里就是两个完全不同的名字，和 foo、foo2 没区别。
- 调用必须显式限定：
A::foo(42)或先写using A::foo; -
using namespace A;是危险操作：它把整个命名空间“拉平”进当前作用域，可能意外遮蔽已有名字，尤其在头文件里滥用会引发隐晦冲突 - 无名命名空间（
namespace { int x; }）等价于static全局变量：只在本翻译单元可见，链接时不暴露
类内部和局部变量同名时怎么访问？
类成员和函数参数/局部变量同名，是最容易踩坑的场景。编译器优先选最近的作用域，所以：
-
this->x明确指向类成员x - 直接写
x—— 如果函数参数叫x，那它就遮蔽了成员x，此时x就是参数 - 构造函数初始化列表里不能用
this->，只能靠名字区分：推荐参数加前缀（如_x）或用std::move(_x)避免歧义
例如：class C { int x; C(int x) : x(x) {} }; 中，冒号后的 x(x) 第一个 x 是成员，第二个 x 是参数——靠位置和语法硬性约定，不是靠查找规则。
enum class 和普通 enum 的作用域差异在哪？
这是常被忽略的“同名但不可见”的典型：
-
enum Color { red, blue };→red直接进入外层作用域，和全局变量red可能冲突 -
enum class Status { red, blue };→red只能在Status::red中访问，Status::red和Color::red完全无关 - 想用
red简写？得using Status::red;，但这样又可能和别的red冲突——不如老老实实写全称
真正麻烦的不是“怎么写对”，而是“为什么明明定义了却说找不到”：90% 是忘了加 :: 或误用了 using 把名字拖进错误作用域。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
