内联命名空间需显式声明为 inline Namespace name，使成员直接暴露于外层命名空间并参与adl和重载决议；其符号mangled名仍含路径，导出/链接时须注意一致性，且仅最外层inline生效。
内联命名空间怎么声明和识别
内联命名空间不是“自动内联”的函数，而是带 inline 关键字的命名空间，作用是让它的成员**直接暴露到外层命名空间中**，同时保留自身作用域。编译器靠这个关键字做符号合并，而不是靠名字是否相同。
常见错误是只写 namespace v2 { ... } 却忘了加 inline，结果版本切换完全没效果；或者在头文件里反复定义同名内联命名空间，引发 ODR 违规。
- 必须显式写
inline namespace v2，不能靠命名约定（比如叫v2就自动内联） - 一个命名空间只能有一个
inline子命名空间被激活（即未被namespace v1 { inline namespace v2 { ... } }嵌套遮蔽） - 内联命名空间可以嵌套，但只有最外层的
inline生效；中间层即使标了inline也不起作用
用内联命名空间做 ABI 兼容的版本升级
核心逻辑是：把新接口放进新的内联命名空间，老接口保留在旧命名空间（非内联），然后通过 using namespace 或别名控制默认可见性。这样链接时符号名不变，但源码可选新旧行为。
典型场景是动态库升级：用户代码不改，仍调 lib::process()，但实际链接到 lib::v2::process() 的实现——前提是 v2 是内联的，且 lib 命名空间里没其他同名 process 冲突。
立即学习“C++免费学习笔记（深入）”；
- 老版本头文件：
namespace lib { void process(); } - 新版本头文件：
namespace lib { inline namespace v2 { void process(); } }，同时保留老版定义（或用[[deprecated]]标记） - 用户代码无需改
lib::process()，编译器自动解析到v2版本，因为内联后lib::process等价于lib::v2::process
链接和符号导出时容易踩的坑
内联命名空间不影响符号的 mangled name，lib::v2::process() 和 lib::process() 在目标文件里是两个不同符号。如果只导出 lib::v2::process，但用户代码调的是 lib::process（且头文件没内联），就会报 undefined reference。
更隐蔽的问题是 windows DLL 导出：MSVC 默认不导出内联命名空间里的符号，除非显式用 __declspec(dllexport) 标在定义上，或者用模块定义文件（.def）列出完整符号名（含内联命名空间路径）。
- 检查符号是否存在：用
nm -C libname.so | grep process（linux）或dumpbin /symbols libname.lib（Windows） - 确保头文件和实现文件的内联声明严格一致，否则 ODR 违规，链接可能成功但运行时行为错乱
- 静态库场景下，如果多个翻译单元用了不同版本的内联命名空间（比如一个包含
v1，一个包含v2），链接器不会报错，但行为不可预测
和 using-declaration、别名命名空间的区别
using namespace v2 是作用域引入，影响查找路径但不改变符号归属；namespace v2 = v1 是别名，所有引用都转成 v1；而 inline namespace v2 是语义合并——它让 v2 的名字“升格”为外层命名空间的直系成员，且参与 ADL 和重载决议。
比如 std::String 在 c++11 后实际是 std::__cxx11::string（GCC 实现），靠内联命名空间透出，所以用户代码不用改就能用新 ABI 的 string；换成 using 就做不到这点，因为 ADL 不会跨 using 查找。
- 要支持 ADL（比如自定义
operator），必须用 <code>inline，不能用using - 别名命名空间（
namespace v2 = v1）无法解决模板实参推导问题，而内联命名空间可以 -
inline是编译期机制，不影响运行时开销；但错误使用会导致头文件膨胀或 ODR 风险，比using更难调试
内联命名空间的关键不在“内联”二字，而在它如何重塑名字查找和符号可见性。一旦漏掉 inline 关键字，或在头文件与实现文件中不一致，版本切换就彻底失效，而且错误往往延迟到链接甚至运行时才暴露。