命名空间声明需完全匹配才能合并，拼写或大小写错误会创建独立命名空间；using 指令禁用于头文件；匿名 namespace 提供内部链接；C++17 inline namespace 支持跨文件共享嵌套命名空间定义。

namespace 声明和定义要匹配，否则会意外创建多个独立命名空间

很多人以为连续写两个 namespace foo { ... } 就是“续写”，其实不是。C++ 允许在不同位置多次声明同一命名空间，但每次大括号内的内容是**合并**进去的——前提是名字完全一致（包括嵌套路径）。一旦拼错、大小写不一致或加了多余限定，就会新建一个同名但互不相干的命名空间。

• namespace mylib { void init(); } 和 namespace mylib { void cleanup(); } → 合并为一个 mylib
• namespace MyLib { void init(); } → 这是另一个命名空间，和 mylib 无任何关系
• namespace mylib::v2 { void init(); } → 是嵌套命名空间，不自动包含外层 mylib 的内容

using 指令要慎用，尤其不能放在头文件里

using namespace std; 写在源文件（.cpp）顶部看似方便，但会把整个 std 名字拉进当前作用域，可能掩盖你自己的同名函数或引发 ADL（参数依赖查找）歧义。更危险的是，如果把它写进头文件（.h），所有包含该头的翻译单元都会被动污染。

• 只在 .cpp 文件局部作用域用 using std::vector; 或 using namespace std::literals; 这类窄范围引入
• 绝对避免在头文件中出现任何形式的 using 指令或声明
• 模板代码中尤其注意：ADL 可能因 using 导致调用到意料之外的重载版本

匿名 namespace 等价于 static，用于限制链接性

在 C++ 中，namespace { int x = 42; } 定义的 x 具有内部链接（internal linkage），效果等同于 C 风格的 static int x = 42;。它不会出现在符号表中，也不会与其他编译单元的同名变量冲突。

• 适用于工具函数、配置常量、测试桩等仅本文件需要的实体
• 注意：匿名 namespace 内的类型定义（如 struct Helper {};）仍是唯一类型，即使多个文件都定义了相同结构，它们也互不兼容
• 不要试图在匿名 namespace 外通过 extern 声明来引用其内容——这是非法的

嵌套 namespace 要用 C++17 的 inline 修饰才能跨文件共享定义

C++17 引入 inline namespace 主要解决库版本兼容问题，但它也让嵌套命名空间的跨文件定义变得安全。比如你希望 mylib::v2::util 在多个 .cpp 中分别定义部分函数，又不想被当作多个独立命名空间处理，就得加 inline：

namespace mylib {
inline namespace v2 {
    void log(const char* msg);
}
}

这样，哪怕你在另一个文件再写一遍 namespace mylib { inline namespace v2 { void debug(int x); } }，它们仍属于同一个逻辑命名空间。没有 inline，两次定义会被视为两个不同的 v2，导致链接失败或 ODR 违反。

实际项目中，嵌套过深（如 a::b::c::d::e）容易让开发者迷失上下文，建议控制在 2–3 层以内，并确保每层都有明确语义边界。命名冲突真正难解的地方，往往不在技术细节，而在团队对模块边界的共识是否清晰。