命名空间通过编译期逻辑分区解决重名问题，使a::foo与b::foo互不干扰；头文件中禁止using namespace，cpp文件中如需使用应限定在函数内部。
namespace 怎么解决变量/函数重名问题
命名空间的核心作用就是隔离同名符号，让 foo 在 A::foo 和 B::foo 中互不干扰。它不是“加前缀”的语法糖，而是编译期的逻辑分区——链接器看到的是 _ZN1A3fooE 和 _ZN1B3fooE 这类不同符号名。
常见错误是直接在全局作用域写 using namespace std; 后又定义 string 或 count，结果编译失败或行为异常。尤其在头文件里写这句，等于把整个 std 泄露给所有包含它的翻译单元。
- 头文件中禁止使用
using namespace，只用std::vector这种显式限定 - cpp 文件里若要用，放在函数内部（如
void f() { using namespace std; cout ），缩小作用域 - 别用
using std::string引入单个名字后，再自己定义string类型——哪怕在另一个 namespace 里，也可能触发 ODR 违规
嵌套 namespace 和 inline namespace 的实际用途
嵌套不是为了炫技，而是对应模块分层。比如 mylib::network::http::Client 比 mylib_network_http_Client 更易读、更易组织头文件路径（mylib/network/http/client.h）。
inline namespace 是 ABI 兼容的关键工具：当你升级库，把旧版 v1::parse() 移到 v2::parse()，但又不想让老代码改调用，就可以这样：
立即学习“C++免费学习笔记（深入）”；
namespace mylib {
inline namespace v2 {
void parse();
}
namespace v1 {
void parse(); // 旧实现，仍可被显式调用
}
}此时未加限定的 mylib::parse() 自动绑定到 v2::parse()，而 mylib::v1::parse() 仍可用。
- 嵌套过深（如四层以上）会增加打字负担，建议配合
namespace alias：namespace http = mylib::network::http; -
inline只能用于直接子 namespace，不能跨级；且一个 namespace 内最多一个 inline 子空间 - 不要在 inline namespace 里放模板特化——特化必须和主模板在同一个逻辑 namespace 下，否则编译器找不到
匿名 namespace 和 static 的区别到底在哪
两者都限制链接性，但机制完全不同：static 是 C 风格的“内部链接”，而匿名 namespace 是 C++ 推荐方式，它本质是生成一个唯一名称的命名空间（如 namespace __xyz123 { ... }），所有内容自动具有内部链接属性。
关键差异在于类和模板：
- 在匿名 namespace 中定义的
class X，每个 TU 里都是独立类型，不能互相转换（哪怕定义完全一样） -
static void f()和namespace { void f(); }对函数效果一致，但后者可包含类型定义、模板、静态成员等，static不行 - 模板在匿名 namespace 中定义时，每个 TU 会实例化一份，无法跨 TU 共享特化；若需共享，得提到外层命名空间
using 声明和 using 指令的危险边界
using std::swap; 是安全的——它只引入一个名字，且 ADL 通常也依赖它；但 using namespace boost; 在头文件中等于埋雷。
真正容易出问题的是“部分引入”场景：比如你写了 using std::string;，又在同作用域写了 typedef char* string;，有些编译器报错，有些静默覆盖——这不是标准行为，而是实现相关。
- 函数重载时，
using声明会把基类或父 namespace 的重载版本带进来，可能改变 overload resolution 结果 - 在模板中慎用
using引入依赖名字：若该名字在实例化时才可见（如依赖模板参数），可能因 ADL 失效而编译失败 - 用
clang -Xclang -ast-dump看 AST，能直观确认某个foo到底解析到了哪个 namespace 下——比猜强得多
命名空间不是越深越好，也不是越多越安全。最常被忽略的是：跨 namespace 的友元声明、模板特化位置、以及头文件中不经意的 using 泄露——这些地方出问题，往往要花几小时翻符号表才能定位。
