内联命名空间通过inline关键字声明，非靠名称识别；其核心作用是使成员“透出”并支持API平滑升级，依赖编译期名字查找规则自动回溯内联命名空间。
内联命名空间怎么声明和识别
内联命名空间不是靠名字特殊，而是靠 inline 关键字显式标记。它和普通命名空间语法几乎一样，唯一区别就是多了这个关键字。
- 必须写
inline，漏掉就只是普通嵌套命名空间，不会触发内联行为 - 内联命名空间可以嵌套，但只有最外层的
inline起作用；内部再套一个inline也没额外效果 - 头文件里声明时，
inline namespace和namespace可以混用，但语义不同：前者让成员“透出”，后者完全隔离
namespace v1 {
inline namespace stable {
void do_work();
}
} // 这时调用 do_work() 不需要写 v1::stable::do_work()
为什么能用来平滑升级 API
核心在于“名字查找规则”：当编译器在某个命名空间里找不到符号时，会自动向上递归查找其内联命名空间里的同名符号。这相当于给旧代码悄悄铺了一条通往新实现的隐式路径。
- 升级时把新版本函数放进新的
inline namespace，老版本保留在非内联命名空间里（或直接移除） - 用户代码不改调用方式，链接器/编译器自动选中当前内联的那个版本
- 库作者可随时切换哪个命名空间是
inline的，用户无感
常见错误现象：undefined reference to 'xxx' —— 很可能是因为你改了内联状态，但没重新编译所有依赖该头文件的源文件，导致符号可见性不一致。
容易踩的坑：ADL、模板特化和 using 声明
内联命名空间对 ADL（参数依赖查找）影响很大，这是最容易翻车的地方。
- 如果函数参数类型定义在内联命名空间里，ADL 会自动把该命名空间加入查找集，哪怕你没显式写命名空间前缀
- 模板特化必须写全特化所在命名空间，不能因为它是内联的就省略；否则编译器认为是另一个特化
-
using namespace X会把内联命名空间的内容也拉进来，但using X::func只认非内联路径，除非你明确指向内联子空间
inline namespace v2 {
struct Data {};
void process(Data);
}
// 下面这行会触发 ADL，找到 v2::process
process(Data{}); // OK，不用写 v2::process
ABI 兼容性和链接时陷阱
内联命名空间本身不改变符号修饰名（mangling），但会影响符号的“归属命名空间”，进而影响链接行为。
- 同一个函数在不同内联命名空间里，生成的符号名不同（因为命名空间路径参与 mangling）
- 动态库升级时，如果把函数从
v1移到inline namespace v2，老二进制仍能运行，但调用的是旧版符号；新编译的代码才会绑定新版 - 静态库场景下，务必确保所有源文件看到的头文件中，内联命名空间状态一致；否则同一符号可能被定义多次，链接时报
multiple definition
关键点：内联命名空间不是宏替换，也不是运行时机制。它完全在编译期决定名字查找路径，一旦头文件被包含，行为就固定了。改完 inline 标记后，所有用到它的源文件都得重编译。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
