内联命名空间必须显式声明 inline 关键字，C++11 起支持，用于版本控制；一个命名空间内仅允许一个 inline 子空间，不可匿名，需配合 using 重导出实现 ABI 兼容升级。
内联命名空间必须显式声明 inline 关键字
不写 inline 就只是普通嵌套命名空间，完全不具备版本控制能力。C++11 起才支持该特性，老编译器（如 GCC 4.6 之前、MSVC 2013 之前）会直接报错或静默忽略。
常见错误现象：namespace v2 { namespace util { ... } } 看起来像版本分组，但调用时仍需写全 v2::util::func()，无法实现“默认启用新版本”的效果。
- 正确写法必须是：
namespace v2 { inline namespace util { ... } } - 一个命名空间内只能有一个
inline子空间；重复声明会触发编译错误 - 内联命名空间不能是匿名的（即不能写
inline namespace { ... }）
版本升级时用 using namespace 重导出旧符号
用户代码依赖旧版接口（如 v1::String），但你希望新编译默认走 v2::String，又不能破坏二进制兼容——这时不能删 v1，而要用重导出把新类型“映射”到旧名下。
使用场景：发布 libfoo.so.2 时保持 ABI 兼容，同时让新代码默认用新版实现。
立即学习“C++免费学习笔记（深入）”；
namespace foo { inline namespace v2 { struct String { ... }; } namespace v1 { using String = v2::String; } }- 注意：这种
using只在命名空间作用域生效，不能放在函数内 - 若
v1::String原为类定义而非别名，需改为别名 + 显式特化或适配器，否则 ODR 违反
链接期符号冲突常因未隐藏内联命名空间细节
内联命名空间影响符号生成规则：编译器会把 v2::util::func 的符号名展开为类似 _Z3funv23util 的形式，但若头文件中暴露了内联结构体定义，且多个 TU 同时包含它，可能引发 ODR 违规（尤其模板实例化或 static 数据成员）。
性能/兼容性影响：符号名变长，调试信息体积略增；某些旧版链接器（如 Gold 1.10 之前）对深度嵌套 inline 命名空间解析不稳定。
- 关键原则：所有内联命名空间内的非内联函数定义，必须加
inline或置于头文件中 - 全局
static变量、constexpr变量建议移入内联命名空间内部，避免跨 TU 冗余实例 - 检查方式：
nm -C libxxx.a | grep 'v1\|v2'，确认无重复符号或意外导出
头文件中不要用 #ifdef 切换内联命名空间
有人试图用宏控制哪个版本 inline：#ifdef USE_V2 inline namespace v2 { ... } #else inline namespace v1 { ... } #endif——这会导致同一份头文件在不同编译单元中产生不一致的符号布局，链接失败或运行时崩溃。
真实需求其实是“项目级版本锚定”，不是“编译开关”。正确做法是把版本选择下沉到构建系统（CMake 的 target_compile_definitions）或单独的版本头（version_config.h）中，并确保整个项目统一。
- 禁止在公开头文件里出现条件编译决定 inline 结构
- 允许在私有实现头中用
static_assert校验当前激活的 inline 版本是否符合预期 - 若真需多版本共存（如插件系统），应通过 PIMPL 或工厂函数隔离，而非靠 inline 命名空间混用
最易被忽略的一点：内联命名空间本身不提供 ABI 隔离，它只是名字查找的快捷方式。如果你改了 v2::String 的内存布局，哪怕它被 inline 了，老二进制照样会崩——得靠版本号后缀、so 版本号、或符号版本脚本配合才行。
