using namespace std; 在头文件中是危险操作，因头文件被多处包含时会将整个 std 名字空间“泼”入各翻译单元全局作用域，导致符号冲突。
namespace 本身不会冲突，真正出问题的是你没管住名字的暴露方式和链接行为。命名空间只是编译期的名字修饰前缀，它不自动解决链接层符号重复、头文件误用或 using namespace 滥用带来的实际冲突。
为什么 using namespace std; 在头文件里是危险操作
这不是风格问题，是工程事故高发点：
- 头文件被多个 .cpp 文件包含时，using namespace std; 会把整个 std 名字“泼”进每个翻译单元的全局作用域
- 若某处定义了 vector 或重载了 operator，就可能和 std::vector 或 std::operator 发生 ADL 冲突或重定义
- 编译器报错位置往往远离源头（比如在第三方库头文件里突然爆红），排查成本极高
- 替代方案：只在 .cpp 文件底部、函数内部或局部作用域用 using std::string; 这类精确声明
动态库中 namespace 为何“失效”
因为链接器看不见 namespace，它只认修饰后的符号名。常见踩坑点：
- extern "C" 导出的函数完全绕过命名空间，两个库都导出 init() 就直接冲突
- 忘加 -fvisibility=hidden，导致所有 MyLib::foo() 都变成全局可见符号，哪怕写了 namespace MyLib
- inline 函数在头文件中定义，若未加 static 或未设为 hidden，会在每个链接单元生成强符号，引发 ODR 违反
- 正确做法：统一用 __attribute__((visibility("default"))) 显式标记导出接口，并确保它们全在命名空间内
嵌套 namespace 和 inline namespace 的关键区别
别把它们当成“写得深一点就好”，用途完全不同：
- 嵌套 namespace A { namespace B { void f(); } } 是逻辑分组，调用必须写 A::B::f()，适合模块化组织（如 std::filesystem::path）
- inline namespace v1 { void api(); } 是 ABI 兼容设计：它的成员会“透出”到外层空间参与重载和 ADL，但定义仍可独立维护；升级时新增 inline namespace v2，用户代码不用改就能切换版本
- 容易忽略的细节：内联命名空间不能有显式模板特化，特化必须写在外层命名空间中；且和命名空间别名混用时，ADL 查找顺序不是直觉上的文本展开
真正难处理的从来不是怎么写 namespace，而是控制名字何时暴露、向谁暴露、以什么形式暴露——尤其当代码要跨编译单元、跨动态库、跨团队复用时，namespace 只是起点，不是终点。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
