内联命名空间用inline namespace声明，核心作用是将其成员自动提升至外层命名空间作用域，实现无缝访问（如lib::process()），同时保留自身命名空间独立性，主要用于版本控制与ABI兼容。
内联命名空间怎么声明和基本作用
内联命名空间用 inline namespace 关键字声明，核心作用是让其成员自动“提升”到外层命名空间作用域中，同时保留自身命名空间的独立性。这在版本控制、ABI 兼容或接口演进中很实用。
- 必须显式写
inline，不能省略（C++11 起支持） - 内联命名空间可以嵌套，但只有最外层的
inline修饰才生效 - 外层命名空间中未被遮蔽的内联命名空间成员，可直接通过外层名访问
namespace lib {
inline namespace v2 {
void process();
int version = 2;
}
}
// 可以直接调用 lib::process()，不用写 lib::v2::process()
// 也可以显式写 lib::v2::process() —— 两种写法都合法
为什么不能把所有版本都设成 inline
多个内联命名空间共存时，若同名符号冲突（比如两个 v1 和 v2 都定义了 process()），编译器会报错：「redefinition」或「ambiguous lookup」。
- 同一外层命名空间下，最多只能有一个内联命名空间提供某个符号的定义
- 常见做法是只让最新版为
inline，旧版保持普通命名空间，避免污染
namespace lib {
namespace v1 {
void process(); // 不 inline
}
inline namespace v2 { // 当前默认版
void process(); // OK：覆盖 v1 的可见性
void helper();
}
}
// lib::process() 指向 v2::process()
// lib::v1::process() 仍可显式调用，但不会参与 ADL 或 using 声明的自动提升
内联命名空间和 using 声明混用的坑
using namespace 引入内联命名空间时，行为和普通命名空间不同：它会把内联命名空间的 内容（而非命名空间本身）带进来，容易引发意料外的符号冲突。
-
using namespace lib;等价于把lib::v2（当前 inline 版）的所有名字拉到当前作用域 - 如果你又写了
using namespace lib::v1;，而 v1 和 v2 有同名函数，就会触发重定义错误或调用歧义
常见错误现象：
立即学习“C++免费学习笔记（深入）”；
- 编译失败提示
"process" is ambiguous - 某些头文件包含顺序变化后，
process()突然调用到了旧版实现
建议做法：
- 避免对含内联命名空间的外层命名空间做
using namespace - 显式限定调用，如
lib::process()或lib::v2::process() - 若必须导入，优先用
using lib::process;单个符号导入
模板特化和内联命名空间的兼容性问题
模板声明必须在主模板所在命名空间中进行；如果主模板在内联命名空间里，特化也得在同一个内联命名空间（或外层命名空间中显式指定完整路径），否则编译器可能找不到匹配。
- 错误写法：
template<> void lib::v1::MyClass<int>::foo() { ... }</int>（v1 不是 inline，而主模板在 v2 中） - 正确写法：要么在
lib::v2中特化，要么用完整限定template<> void lib::v2::MyClass<int>::foo() { ... }</int>
另外注意：
- 类模板的显式实例化（
template class lib::v2::MyClass<double>;</double>）必须和定义在相同内联层级 - ADL（参数依赖查找）会沿内联链向上搜索，所以传入
lib::v2::Type对象时，lib::process(Type)可能被找到，即使它定义在lib顶层
内联命名空间不是语法糖，它的提升规则和查找逻辑会影响符号可见性、链接行为甚至 ABI，改的时候务必确认上下游是否依赖隐式提升路径。
