内联命名空间必须首次定义时就加inline才生效，后续重声明无效；其“透出”仅作用于未限定查找和ADL；符号链接名含完整路径，改名即破坏ABI；迁移应采用双版本共存+using声明过渡。
内联命名空间怎么声明才真正起作用
内联命名空间不是加个 inline 就自动“透出”所有内容——它只对未限定查找（unqualified lookup）生效，且必须在首次定义时就标记为 inline，后续重声明无效。
常见错误是先定义普通命名空间，再试图用 inline namespace v2 { ... } 二次打开并加 inline，这会被编译器忽略，v2 仍是普通命名空间。
- 正确做法：从第一次定义起就写
inline namespace v2 { ... } - 如果已有非 inline 版本，必须重构头文件，不能靠重声明补救
- 内联命名空间内部可以嵌套非 inline 子空间，但只有最外层
inline标记生效
版本切换时为什么 using 声明不按预期工作
很多人以为写个 using namespace current_version; 就能统一入口，但实际中常遇到符号冲突或查找不到——根本原因是 using namespace 不参与 ADL（参数依赖查找），而内联命名空间的“透出”机制恰恰依赖 ADL 和 Koenig lookup。
典型场景：你导出一个函数 process(Data&)，放在 inline namespace v1 里；用户代码调用 process(x)，但 x 的类型定义在另一个头里，没引入 v1，这时编译器根本不会去 v1 里找 process。
立即学习“C++免费学习笔记（深入）”；
- 解决办法：确保用户包含的头文件已激活对应内联命名空间（即该头里已定义了
inline namespace） - 避免在实现文件里用
using namespace拉平版本，这会破坏 ABI 边界 - 对外头文件中，推荐用
namespace current = v2;而非using namespace v2;，前者不污染作用域，且不影响 ADL
ABI 兼容性陷阱：同一个函数名在不同内联命名空间里算不算重定义
算。C++ 标准规定：内联命名空间中的名字，其链接名（mangled name）仍包含完整嵌套路径。也就是说，inline namespace v1 { void foo(); } 和 inline namespace v2 { void foo(); } 是两个完全不同的符号，链接器眼里毫无关系。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
这既是保障，也是坑：你改了内联命名空间名，所有调用点都得重新编译，否则运行时可能报 undefined reference to 'foo'——因为旧.o 文件还在找 v1::foo，而新库只提供 v2::foo。
- 发布二进制库时，内联命名空间名应视为 ABI 的一部分，不可轻动
- 若需灰度升级，可用
extern "C"函数桥接，或在头里用#ifdef控制默认内联版本 - Clang/GCC 的
-fvisibility=hidden对内联命名空间无特殊处理，别指望它帮你“隐藏旧版”
怎么让老代码无缝迁移到新内联命名空间
不能靠宏替换整个命名空间块，那会破坏头文件的可包含性。真正可行的是“双版本共存 + 别名过渡”，核心是利用内联命名空间的“扁平可见性”和 using-declaration 的重导出能力。
例如，你想把 v1 升级到 v2，但允许用户暂时继续用 ::foo() 而不改代码：
inline namespace v2 {
void foo();
}
namespace v1 {
using ::v2::foo; // 注意：这是 using 声明，不是 using namespace
}
这样，既保留了 v1::foo 符号供旧.o链接，又让 ::foo() 直接解析到 v2::foo。
- 关键点：
using ::v2::foo必须写在非 inline 的v1里，否则无意义 - 不要在头里用
#define foo v2::foo，宏会破坏模板实例化和调试信息 - 迁移完成后，删掉
v1块即可，无需改用户代码
内联命名空间不是语法糖，它是 ABI 分层的基础设施。一旦选错层级粒度（比如把整个模块塞进一个内联空间），后期拆分代价远超预期。
