命名空间声明需完全匹配才能合并，拼写或大小写错误会创建独立命名空间；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：
本文档主要讲述的是Python之模块学习；python是由一系列的模块组成的，每个模块就是一个py为后缀的文件，同时模块也是一个命名空间，从而避免了变量名称冲突的问题。模块我们就可以理解为lib库，如果需要使用某个模块中的函数或对象，则要导入这个模块才可以使用，除了系统默认的模块（内置函数）不需要导入外。希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看
立即学习“C++免费学习笔记（深入）”；
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 层以内，并确保每层都有明确语义边界。命名冲突真正难解的地方，往往不在技术细节，而在团队对模块边界的共识是否清晰。
