内联命名空间必须用inline namespace显式声明，其成员自动提升至外层作用域并支持隐式查找；嵌套时仅最内层inline生效；同一作用域只能有一个激活的内联命名空间，否则引发ODR违规。
内联命名空间怎么声明和嵌套
内联命名空间必须用 inline namespace 显式声明，不能省略 inline 关键字；它和普通命名空间的区别在于：其成员会自动“提升”到外层命名空间作用域中，且支持隐式查找。
常见错误是写成 namespace inline N { ... }（顺序错）或漏掉 inline 导致失去版本透传能力。
- 内联命名空间可以嵌套，但只有最内层的
inline起作用；外层即使标了inline也不影响内层非 inline 命名空间的隔离性 - 同一作用域下只能有一个内联命名空间被“激活”，否则引发 ODR 违规（例如两个
inline namespace v1和inline namespace v2同时存在且都定义了同名函数） - 头文件中定义内联命名空间时，要确保所有包含该头的 TU（translation unit）看到的内联结构一致，否则可能触发未定义行为
namespace library {
inline namespace v2 {
void process(); // 可直接用 library::process()
}
namespace v1 {
void process(); // 不可直接用 library::process()，需显式 library::v1::process()
}
}如何用 inline namespace 实现 ABI 兼容的版本升级
核心思路是把旧版符号放进非内联命名空间，新版放进 inline namespace，再用 using 或别名导出关键接口。这样既保留旧符号路径，又让新代码默认使用新版实现。
注意：仅靠内联无法解决函数签名变更（如参数增减）带来的 ABI 断裂，必须配合重载、默认参数或 wrapper 函数。
立即学习“C++免费学习笔记（深入）”；
- 用户调用
library::do_work()时，链接器优先绑定到v2::do_work()（因为内联），但library::v1::do_work()仍可显式调用 - 若需切换默认版本，只需修改
inline修饰的目标（比如从v2改为v3），不改调用点代码 - 动态库发布时，不同内联版本的符号在 so/dylib 中实际是独立的（
_Z7do_workvvs_Z7do_workv@v2等），需确保符号版本脚本或visibility设置正确
namespace widget {
namespace v1 {
class Renderer { /* old impl */ };
}
inline namespace v2 {
class Renderer { /* new impl, different layout */ };
// 提供兼容构造函数或转换函数
Renderer(const v1::Renderer& old);
}
}链接与模板实例化时的陷阱
内联命名空间会影响模板实参依赖查找和符号弱定义行为。典型问题是：同一个模板在不同内联版本中实例化，会被视为不同特化，导致重复定义或链接失败。
错误现象包括 LNK2005（MSVC）或 “multiple definition of…”（GCC/Clang），尤其在头文件中定义模板并跨 TU 使用时。
- 避免在内联命名空间内定义非内联函数模板（即没加
inline或static的函数模板定义），应只放声明，实现在 .cpp 中 - 类内定义的成员函数默认是
inline，所以在内联命名空间中定义类，其成员函数天然具有内联语义，但要注意 ODR —— 所有 TU 必须看到完全一致的类定义 - 显式模板实例化声明（
extern template）必须和定义位于同一内联命名空间层级，否则编译器可能找不到匹配项
和 C++20 module 的协作注意事项
模块接口单元（.ixx）中使用内联命名空间没问题，但导出规则不会自动穿透内联层级：必须显式 export namespace library::v2 或 export inline namespace library::v2，否则即使内联，外部模块也无法访问其内容。
更隐蔽的问题是模块分区（module partition）之间若用了不同内联版本，而主模块未统一导出策略，会导致符号不可见或 ODR 违反。
- 模块中不要依赖“隐式提升”来访问内联命名空间成员；始终用完整限定名导入或导出，提高可读性和可控性
-
import某个模块后，其内联命名空间是否生效，取决于该模块的导出声明，而非当前翻译单元的命名空间结构 - 跨模块调用时，若一个模块导出
v2::func()，另一个模块在v1内联下也定义了func()，则链接器不会自动合并 —— 它们是不同符号
内联命名空间不是语法糖，它是编译器参与的符号组织机制。真正难的是在大型项目中维持所有 TU 对“哪个版本是 inline”的共识，以及确保动态库符号版本控制与之同步。稍有疏忽，调试时看到的 mangled name 和实际调用的实现就可能对不上。
