namespace本质是作用域隔离而非文件划分工具；可跨文件定义、单文件多定义；需用A::f()调用，禁在头文件用using namespace；匿名namespace比static更通用；using易引发命名冲突；第三方库撞名应使用别名而非宏。
namespace 本质是作用域隔离，不是文件划分工具
很多人以为 namespace 是为了“把不同模块的代码分开写在不同文件里”，其实它只管名字查找时的可见性。同一个 namespace 可以跨多个文件定义，编译器会自动合并；反过来，一个文件里也能定义多个 namespace，互不干扰。
常见错误现象：error: 'xxx' was not declared in this scope，往往是因为用了 using namespace std; 后又自己定义了同名函数，或者嵌套 namespace 里漏写了作用域限定。
- 定义时用
namespace A { void f(); }，调用时必须写A::f()或在局部加using A::f;（不推荐using namespace A;） - 避免在头文件里写
using namespace xxx;—— 它会污染包含该头的所有翻译单元 - 嵌套命名空间如
namespace A { namespace B { int x; } }，C++17 起可简写为namespace A::B
匿名 namespace 和 static 的区别在哪
两者都限制符号链接性（linkage），但机制不同：匿名 namespace 中的名称具有内部链接（internal linkage），而 static 在 C++ 中对函数/变量也起同样作用，但对类型（如 class）无效。
使用场景：实现文件（.cpp）里定义仅本文件使用的辅助函数、常量或类型时，优先用匿名 namespace，语义更清晰，且能包裹类型定义。
立即学习“C++免费学习笔记（深入）”；
-
static int helper = 0;和namespace { int helper = 0; }效果等价（对变量/函数） - 但
static class Helper {};是非法的；必须用namespace { class Helper {}; } - 匿名
namespace里的内容仍可被同一编译单元内其他函数访问，只是不能被其他 .o 文件引用
using 声明和 using 指令的风险点
using 看似方便，实则是命名冲突高发区，尤其在模板或重载场景下容易触发意料外的匹配。
典型错误现象：error: call of overloaded 'swap(int&, int&)' is ambiguous，往往源于某个头文件里写了 using namespace std;，导致 ADL（参数依赖查找）和 using 指令双重曝光了多个 swap 版本。
- 只在函数体内用
using std::vector;这类声明，缩小作用域 - 绝对不在头文件或全局作用域写
using namespace std; - 如果要用
std::string频繁，宁可重复写std::，也不要图省事加using - 注意
using声明不会继承父namespace的嵌套结构 ——using ns::A;不会让A::B自动可用
第三方库命名空间撞车怎么办
两个库都叫 json 或都用 util 做顶层命名空间？这不是设计缺陷，而是现实常态。C++ 没有模块级重命名机制，只能靠别名 + 显式限定解决。
性能影响几乎为零，但可读性和维护成本会上升 —— 关键是让团队约定好缩写规则，并在文档里明确标注来源。
- 用
namespace json11 = json11::json11;给长名起别名，比using namespace json11::json11;安全得多 - 项目级统一前缀，比如所有自研模块用
myorg::core::，第三方封装层再套一层myorg::ext::nlohmann_json:: - 不要试图用宏替换命名空间名（
#define json nlohmann_json），宏会破坏 IDE 导航和调试信息
namespace 的合并规则、using 的作用域穿透性、以及第三方命名空间的别名粒度——这三个地方最容易在重构或集成时突然暴露问题，而且错误信息往往不直接指向根源。 
