命名空间声明应放在头文件中用namespace包裹，定义在对应.cpp文件中同名namespace内；避免头文件中using namespace std;，推荐显式std::前缀或窄范围using声明。
命名空间声明和定义写在哪
命名空间不是类，也不需要头文件专门“导出”，但位置错会导致链接错误或符号未定义。namespace 块可以出现在全局作用域，也可以嵌套，但不能在函数内部定义（C++11 起允许匿名命名空间在局部作用域，但非常规用法）。
- 头文件中用
namespace包裹声明（如函数原型、类定义），避免污染全局命名空间 - 对应 .cpp 文件里用相同名字的
namespace包裹实现，否则链接器找不到MyLib::do_something() - 不要在头文件里写
using namespace std;—— 它会把整个std泄露给所有包含该头的文件，引发意外重定义
using 指令和 using 声明的区别与风险
using namespace X; 是“全盘导入”，using X::func; 是“精准引入”。前者省事，后者可控。工程里混用容易踩名冲突坑。
-
using namespace std;放在函数体里相对安全，但放在全局作用域（尤其头文件）等于埋雷 -
std::vector和自定义vector类名冲突时，using namespace std;会让编译器报reference to 'vector' is ambiguous - 现代项目推荐显式写
std::前缀，或只用using std::string;这类窄范围声明
匿名命名空间替代 static 全局变量
C++ 中 static 修饰全局变量/函数已不推荐，改用匿名命名空间更符合语言演进逻辑，语义也更清晰：它声明的符号仅在当前翻译单元可见。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 旧写法：
static void helper() { ... }→ 新写法：namespace { void helper() { ... } } - 匿名命名空间里的内容仍受 ODR（One Definition Rule）约束，不能在多个 .cpp 里重复定义同名函数
- 注意：匿名命名空间不能跨文件共享，也不能被
extern "C"影响
嵌套命名空间和 inline 命名空间（C++11/C++17）
多级模块化时，嵌套命名空间比长前缀更易读；inline namespace 主要用于 ABI 兼容升级，普通业务代码极少需要。
立即学习“C++免费学习笔记（深入）”；
- 写
namespace A { namespace B { namespace C { ... } } }等价于namespace A::B::C { ... }（C++17 起支持） -
inline namespace v2 { ... }让其中的符号自动“提升”到外层命名空间，方便版本切换而不改调用点 - 别为了“看起来高级”滥用
inline—— 它改变的是符号可见性规则，调试时容易绕晕自己
命名空间本身不产生运行时开销，但过度嵌套会让 IDE 补全变慢、错误信息变长；最常被忽略的是头文件中误用 using 导致的隐式依赖传播——一个头文件悄悄拉进整个 boost，下游编译就可能莫名其妙变慢。
