c++命名空间必须用::嵌套，禁用点号；优先用嵌套声明或c++17的namespace a::b；避免头文件中using namespace；推荐匿名命名空间替代static；命名空间别名需显式声明且作用域限定。
命名空间名不能用点号，只能用双冒号嵌套
很多人写 mylib.utils 试图直接定义带点的命名空间名，编译器会报错：「expected identifier before ‘.’ token」。C++ 的命名空间层级必须用 :: 分隔，且每个段都得是合法标识符——中间不能有 .、- 或数字开头。
正确做法是用嵌套声明：
namespace mylib {
namespace utils {
void log(const char* msg);
}
}等价于单行写法：namespace mylib::utils（C++17 起支持，但老项目慎用）。
- 如果目标是兼容 C++11/14，坚持用大括号嵌套，别图省事写
mylib::utils在顶层声明外 - 嵌套后调用必须写全限定名，比如
mylib::utils::log("hi")；不加using就不会污染全局作用域 - 别在头文件里写
using namespace mylib::utils——头文件被多处包含时，等于悄悄把符号倒进别人代码里
using 声明和 using 指令混用容易引发二义性
常见错误是头文件里写了 using namespace std;，又在同一个翻译单元里用了 using std::string; 和自定义的 string 类型，结果编译器报 reference to 'string' is ambiguous。
立即学习“C++免费学习笔记（深入）”；
using namespace X 是“指令”，把整个命名空间拉进来；using X::Y 是“声明”，只引入单个名字。后者可控，前者危险。
- 在 .cpp 文件里，优先用
using std::vector;这类精确引入，避免意外覆盖 - 绝不在头文件中写
using namespace——哪怕只是std，下游包含你头文件的模块可能因此编译失败 - 如果真要简化长名（如
boost::asio::ip::tcp），用别名：namespace tcp = boost::asio::ip::tcp;，它不引入任何符号，只建映射
匿名命名空间替代 static，但链接属性细节不同
旧代码常用 static void helper() { ... } 限制函数作用域，现在更推荐匿名命名空间：namespace { void helper() { ... } }。表面看效果一样，但底层机制不同：前者是“内部链接”，后者是“无名命名空间 + 外部链接”。
关键区别在于模板实例化和内联行为。比如你在匿名命名空间里定义了一个 inline 函数，它仍可被其他 TU 内联展开；而 static inline 函数在某些旧编译器上可能被当作多个独立副本处理。
- 所有仅用于本文件的辅助函数、常量、类型，一律放匿名命名空间里
- 不要给匿名命名空间起名（比如
namespace detail_），那就不是“匿名”了，也失去了隐藏意图 - 匿名命名空间里的变量仍遵守 ODR（One Definition Rule）——如果在多个 .cpp 里定义同名匿名命名空间变量，链接时不会报错，但它们是各自独立的实例
命名空间别名解决长路径，但不能跨文件复用未声明的别名
写 namespace fs = std::filesystem; 很方便，但有人把它写在 .cpp 里，然后在另一个 .cpp 里直接用 fs::path，结果报 'fs' was not declared in this scope。
命名空间别名不是宏，不参与预处理，也不自动传播。它只在声明它的作用域内有效，且必须在使用前声明。
- 如果多个文件都要用同一组别名，统一放到一个
common_ns.h头文件里，并确保每个用到的地方都包含它 - 别名可以嵌套引用：
namespace net = mylib::network::v2;，但不能反向推导（比如声明了v2别名，不代表mylib::network自动可用） - 避免别名遮蔽：如果已有
namespace json { ... }，就别再写namespace json = nlohmann::json;，否则自己写的json::parse可能被覆盖
嵌套深、别名多、头文件依赖杂的时候，命名空间很容易变成“谁也不知道哪个符号从哪来”的状态。最稳妥的做法是：该写全名时就写全名，别名只用在高频、确定无歧义的场景。
