命名空间必须定义在全局作用域或嵌套于其他命名空间中，不可在函数、类定义体（非嵌套）或控制结构内；否则编译报错“namespace definition not allowed here”。
namespace 声明和定义要写在全局作用域，不能在函数里
很多人第一次写 namespace 时，会把它塞进 main() 或某个函数里，结果编译报错：error: namespace definition not allowed here。C++ 标准规定命名空间只能在全局作用域或嵌套在其他命名空间中，不能在函数、类内部（类内可以声明别名，但不能定义新命名空间）。
正确做法是：把 namespace 放在所有函数之外，通常紧挨着头文件包含之后：
#include <iostream><p>namespace mylib {
int version = 1;
void hello() { std::cout </p>
<p>int main() {
mylib::hello(); // 必须加作用域解析符
}</p></iostream>
- 如果漏掉
mylib::直接调用hello()，编译器找不到这个函数 - 命名空间名不加引号，不是字符串；它不占用运行时内存，纯编译期机制
- 重复定义同名命名空间是合法的（合并），但内容不能冲突（比如同一命名空间里不能有两个同名变量）
using 指令和 using 声明的区别很关键
想少打几个 ::，容易想到用 using。但 using namespace std; 和 using std::cout; 行为完全不同，混用可能引发隐藏冲突。
using namespace std; 把整个 std 里的所有名字都拉进当前作用域，后续若自己定义了 max、swap 等常见名，就可能和 std::max 冲突，编译器不一定立刻报错，但行为不可控。
- 推荐只用
using std::cout;这种“using 声明”，显式引入单个符号 - 在头文件里绝对不要写
using namespace xxx;，否则污染所有包含它的源文件 - 在 .cpp 文件里，如果只是临时用一两个符号，
using std::vector;是可接受的；但大型项目建议始终用全名，避免歧义
匿名命名空间替代 static，但仅限于翻译单元内
C++ 里想让一个函数或变量只在当前 .cpp 文件可见，老写法是加 static。现在更推荐用匿名命名空间：
namespace {
int helper_count = 0;
void helper_init() { /* ... */ }
}
<p>void public_api() {
helper_init();
}</p>
效果等价于 static int helper_count;，但语义更清晰——它表示“这些符号属于本编译单元独有的匿名空间”，且能用于类型定义（static 不能修饰类型）。
- 匿名命名空间里的内容无法被其他 .cpp 文件通过
extern或任何方式访问 - 每个 .cpp 文件的匿名命名空间都是独立的，即使名字相同也不互通
- 注意：不能在头文件里写匿名命名空间，否则每个包含它的 .cpp 都会生成一份副本，导致 ODR 违规风险
嵌套 namespace 要么用 C++17 的 inline，要么手动拆开写
想表达层级结构，比如 graphics::opengl::shader，直接连写会很啰嗦：
namespace graphics {
namespace opengl {
namespace shader {
void compile();
}
}
}
C++17 引入了内联命名空间语法，大幅简化：
namespace graphics::opengl::shader {
void compile();
}
但要注意：只有 C++17 及以上才支持。如果项目必须兼容 C++11/14，就得老老实实嵌套写，或者用宏包装（不推荐）。
- 内联命名空间（
inline namespace）有特殊用途，比如版本控制，普通嵌套不用加inline - 嵌套过深（比如四层以上）会影响可读性，考虑是否真需要这么多层级，还是该拆成独立库或模块
- IDE 对嵌套命名空间的支持参差不齐，某些跳转或补全可能失效，遇到时优先检查语言标准设置
实际项目里最常踩的坑，是把 using namespace 当作省事手段塞进头文件，或者在跨编译单元共享数据时误用匿名命名空间——它根本不会被其他文件看到。命名空间本身不难，难的是在协作规模变大后，谁该暴露、谁该隐藏、谁该合并，得靠团队约定和代码审查来守住边界。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
