根本原因是多个动态库将同名符号声明为全局可见并导出；应通过编译期 -fvisibility=hidden 默认隐藏，再用 API_EXPORT 宏精准标记需导出的接口，配合命名空间仅用于避免修饰后符号名冲突。
动态库导出符号重名时，链接器报 multiple definition 怎么办
根本原因不是“名字重复”，而是多个动态库（或主程序）把同名符号（比如 log_message、init_config）都声明为全局可见并导出了。Linux 下用 nm -D 或 objdump -T 一看就能确认——只要两个 .so 里都有同一个 T 或 D 符号，运行时就可能冲突，尤其在 dlopen + RTLD_GLOBAL 场景下。
解决思路不是“改名字”，而是控制“谁能看到它”。关键操作有两层：编译期隐藏 + 链接期显式导出。
- 默认情况下，C++ 全局函数/变量是
extern "C"风格的全局符号，GCC/Clang 不加干预就会导出 -
static只能解决单文件内联问题，对跨编译单元无效，且无法用于类成员 - 真正可控的方式是：用
__attribute__((visibility("hidden")))关闭默认导出，再用__attribute__((visibility("default")))精确标记要暴露的接口
如何用 visibility 属性精准控制导出范围
直接在源码里逐个加属性太容易漏，推荐统一开关 + 白名单模式：
- 编译时加
-fvisibility=hidden，让所有符号默认不导出（包括类、函数、变量） - 在头文件中定义宏：
#define API_EXPORT __attribute__((visibility("default"))) - 只在真正要对外暴露的声明前加这个宏，例如：
API_EXPORT void start_service(); - 类也要显式标注：
class API_EXPORT ConfigLoader { ... };，否则整个类的 vtable 和 inline 成员都不会导出
注意：如果用了 extern "C" 块，visibility 属性仍生效，但需写在函数声明上，不能只写在块外。
namespace 能解决导出冲突吗？什么时候有用
命名空间本身不改变符号可见性，它只影响 C++ 编译期的名称修饰（mangling），生成的符号名仍是 _Z12log_messagev 这种带命名空间前缀的形式。所以：
- 两个不同
namespace下的同名函数，导出后符号名不同，天然不冲突 —— 这是它唯一起作用的场景 - 但如果两个库都用了
namespace utils { void init(); }，导出符号仍是_Z5utils4initv，依然会撞 - 别指望靠嵌套命名空间（如
mylib::v2::utils）规避问题，链接器只看最终符号名，不解析命名空间语义 - 真正该用命名空间的地方，是组织内部实现，配合
visibility=hidden把整块实现封死，只留顶层入口
常见陷阱：模板、内联函数和 STL 类型导出问题
模板函数默认不实例化，不生成符号；一旦显式实例化（比如 template class API_EXPORT std::vector），就必须确保其所有依赖类型（如分配器）也可见，否则运行时报 undefined symbol。
- 不要导出
std::string或std::vector的实例 —— 它们底层实现可能随 STL 版本变化，ABI 不稳定 - 内联函数（
inline或constexpr）加了API_EXPORT也没用，编译器会忽略 visibility 属性，它们本就不生成独立符号 - 虚函数表（vtable）和 RTTI 信息受 visibility 控制：类加了
API_EXPORT，其 vtable 才会导出；否则即使对象能传出去，dynamic_cast或typeid会失败
最易被忽略的是头文件包含顺序和宏定义时机：如果 -fvisibility=hidden 没在第一个被编译的 .cpp 文件中生效，或者某个第三方头文件提前定义了 __attribute__ 相关宏，可能导致部分符号意外导出。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
