命名空间决定函数可见范围、调用方式与链接行为，影响代码组织与协作安全；编译器按作用域层级查找函数；using指令需谨慎使用；命名空间保障odr一致性；嵌套与别名提升可维护性；无运行时开销但影响编译与维护成本。
函数声明所在的命名空间，直接决定该函数的可见范围、调用方式和链接行为，不改变函数本身逻辑，但深刻影响代码组织与协作安全。
决定函数的可见性与查找路径
编译器在解析函数调用时，会按作用域规则逐层查找：局部 → 外层函数 → 当前命名空间 → 外层命名空间 → 全局命名空间。若函数声明在 namespace A 中，未加限定或未引入，则仅在 A 内或通过 A::func() 可见。
- 同一文件中，using namespace A; 后可直接调用 func()，但可能引发名称冲突
- 仅写 using A::func; 更安全，只导入该函数，不影响其他同名标识符
- 头文件中应避免 using namespace，防止污染包含它的所有翻译单元
影响跨文件链接与ODR一致性
函数声明（尤其带定义）放在命名空间内，意味着其链接属性受该命名空间限定。多个文件中声明同一命名空间下的同名函数，只要签名一致，就属于同一逻辑实体，遵守一次定义规则（ODR）；若分散在不同命名空间，则视为完全不同的函数。
- 例如 ns1::foo() 和 ns2::foo() 可共存，互不干扰
- 若两个.cpp都定义了 ns::bar() { return 1; }，链接器不会报错，它们被视作同一符号
- 但若一处定义在全局，另一处在命名空间，则构成重定义错误
支持嵌套与别名，提升大型项目可维护性
深层嵌套如 core::net::http::request 明确表达模块层级；为长命名空间起别名（namespace cn = core::net;）可简化使用，又不牺牲语义清晰度。
- 嵌套命名空间无需一次性写出全部层级，可分段定义：namespace core { namespace net { ... } }
- 匿名命名空间内声明的函数具有内部链接，等效于 C 的 static，仅本文件可见
- 模板函数、内联函数在命名空间中声明时，其实例化也绑定到该命名空间上下文
不改变运行时性能，但影响编译与维护成本
命名空间本身不生成额外运行时开销——所有解析都在编译期完成。但过度嵌套或滥用 using namespace 会延长名称查找时间，增加编译负担，并提高维护难度。
- 推荐在实现文件（.cpp）中谨慎使用 using namespace，头文件中禁用
- 优先用作用域解析符（::）显式调用，尤其在接口层或库代码中
- 命名空间名宜具描述性（如 graphics::vulkan），避免过短（如 n）或泛化（如 util）
