namespace不能直接解决动态库导出符号重名问题，因其仅在编译期生效，链接器处理的是name mangling后的C风格符号（如_Z1fiv），同签名函数即使位于不同namespace仍可能冲突；若使用extern "C"导出，namespace完全失效；真正有效的是-fvisibility=hidden配合显式__attribute__((visibility("default")))标记导出符号，辅以符号前缀或version-script控制。
动态库导出符号重名时，namespace 为什么不能直接解决问题
因为 C++ 的 namespace 只在编译期起作用，链接器看到的是经过 name mangling 后的 C 风格符号名（如 _Z1fiv），而不同库中同名函数即使在不同 namespace 下，mangled 名仍可能冲突——尤其当函数签名完全相同时。更关键的是，若某个库用 extern "C" 导出函数，namespace 完全失效，符号直接以原始名称导出。
所以单纯靠 namespace 隔离，对导出符号无效；它只能防止源码内未导出的定义冲突。
__attribute__((visibility("hidden"))) 是实际有效的第一道防线
默认 GCC/Clang 编译的符号是 default 可见性，所有带定义的非内联函数都可能被导出。必须显式关闭无关符号的导出能力：
- 编译时加
-fvisibility=hidden，让所有符号默认不可见 - 仅对真正需要导出的函数/类，用
__attribute__((visibility("default")))显式标记 - 头文件中配合宏定义，避免手动重复写属性：
#define API_EXPORT __attribute__((visibility("default"))) - 注意：模板实例化、内联函数、静态成员函数默认不导出，但若在头文件中显式实例化（如
template class API_EXPORT std::vector<int>;），会触发导出，需谨慎
真正解决重名冲突，得靠符号前缀或版本命名空间
当多个动态库必须导出同名接口（比如都叫 init()、process()），且无法协调统一改名时，必须人为制造符号隔离：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- 用
-Wl,--def（Windows）或-Wl,--version-script（Linux）控制导出符号列表，把内部符号全部过滤掉，只留带前缀的（如mylib_init、mylib_process） - 在源码中用宏自动加前缀：
#define MYLIB_INIT() mylib_init()
，再用API_EXPORT标记该封装函数 - 避免用
namespace套整个 API 函数——它不改变导出名；但可用来组织内部实现，比如mylib::detail::do_work()配合visibility(hidden) - 如果使用 CMake，推荐用
set_target_properties(... PROPERTIES POSITION_INDEPENDENT_CODE ON)和target_compile_options(... PRIVATE -fvisibility=hidden)统一管控
运行时加载时的符号冲突（dlopen + RTLD_GLOBAL）怎么避
两个动态库都导出了同名符号，又都被 dlopen(..., RTLD_GLOBAL) 加载，第二个库的同名符号会覆盖第一个——这不是编译问题，是运行时符号表污染。
- 优先用
RTLD_LOCAL：每个库的符号彼此不可见，最安全 - 若必须共享符号（如插件需调用主程序函数），改用
RTLD_DEEPBIND（Linux）让库优先绑定自身依赖，减少外部覆盖风险 - 检查是否误用了
extern "C" { void init(); }——这种写法会让init成为全局 C 符号，比 C++ mangling 更容易撞车 - 用
nm -D libxxx.so或objdump -T实际查看导出表，确认有没有意外导出的辅助函数（比如日志回调、类型信息等）
导出符号的命名权不在 namespace 手里，在链接器手里；想稳住它，得从编译选项、导出控制脚本、加载方式三处同时卡死。漏掉任何一环，重名就可能在某个环境里突然冒出来。
