命名空间无法阻止动态库符号冲突，因其仅作用于编译期名称解析，不改变链接器看到的修饰后符号；同名函数即使在不同命名空间中，若被显式导出（如visibility("default")或dllexport），仍可能因修饰名重复或C调用方无视命名空间而引发冲突，必须配合extern "C"封装、唯一前缀、-fvisibility=hidden等导出控制手段才能真正隔离。
动态库导出符号重名冲突不能靠命名空间“自动解决”——namespace只影响编译期名称解析，不改变链接器看到的底层符号名。真正起作用的是名称修饰（name mangling）后的符号，而多个库中同名函数即使在不同命名空间里，也可能生成冲突的导出符号（比如都导出 _ZN5MyLib7processEv）。必须配合可见性控制或接口封装才能落地。
为什么 namespace 本身无法阻止动态库符号冲突
C++ 编译器对 MyLib::process() 和 YourLib::process() 会分别生成不同的修饰名，但前提是这两个函数**没有被显式导出为动态库的全局符号**。一旦你用 __declspec(dllexport) 或 __attribute__((visibility("default"))) 导出了它们，链接器就会把修饰后的符号放进动态库的导出表。问题在于：如果两个库都导出了各自命名空间下的 process，而主程序又同时链接了二者，链接器仍可能因加载顺序或优先级规则选错实现——尤其是当修饰名意外相同（如模板实例化撞名、内联函数展开后符号合并）时。
更关键的是：C 语言调用方（如 Python ctypes、C# P/Invoke）根本看不到命名空间，它们只认导出的 C 风格符号名。所以仅靠 namespace，对外暴露的接口仍是裸名。
真正有效的 namespace 隔离实践方式
不是不用 namespace，而是要让它和导出控制协同工作：
立即学习“C++免费学习笔记（深入）”；
- 所有类、函数默认放在私有命名空间下（如
namespace mylib_v2 { ... }），避免污染全局作用域 - 导出接口必须是
extern "C"的纯 C 函数，且加唯一前缀，例如：extern "C" __declspec(dllexport) void mylib_v2_process(int x); - 若需导出类实例，用工厂函数封装：
extern "C" __declspec(dllexport) mylib_v2::Processor* mylib_v2_create_processor(); - 禁用默认导出：编译时加
-fvisibility=hidden（GCC/Clang）或设项目属性“隐藏未标记符号”（MSVC），再仅对明确需要的 C 接口加visibility("default")
常见错误：误以为 static + namespace 就安全
很多人写这样的代码，以为能彻底隔离：
namespace MyLib {
static void helper() { /* ... */ }
void public_api() { helper(); }
}
这其实无效：static 只让 helper 不导出，但 public_api 若被 __declspec(dllexport) 标记，它仍会导出，且其修饰名仍含 MyLib 命名空间信息——可被其他 C++ 模块按名调用，一旦另一库也导出同名 public_api，冲突照旧。更糟的是，这种写法容易让人误判“已隔离”，反而放松对导出列表的审查。
真正该做的是：把 public_api 改成带前缀的 C 接口，并确保它不依赖任何非 C 兼容类型（如引用、std::string）。
排查时优先检查导出符号表，而非源码结构
别只看头文件有没有 namespace，直接查动态库实际导出了什么：
- Linux：
nm -D libmylib.so | c++filt | grep process - Windows：
dumpbin /exports mylib.dll | findstr process - macOS：
nm -DY libmylib.dylib | c++filt | grep process
如果看到多个库都导出了无前缀的 process 或 create_instance，哪怕它们在不同命名空间里，冲突风险就已存在。此时修复点不在改 namespace，而在收缩导出接口、加前缀、或改用 extern "C" 封装。
最易被忽略的一点：C++ 模板的显式实例化如果被导出，会生成带完整类型名的符号，极易与其他库撞名——这类符号往往不会出现在常规头文件声明里，却悄悄进了导出表。
