符号导出数量直接影响动态库加载速度，因动态链接器需遍历导出符号完成重定位和解析，符号越多则.dynsym越长、哈希查找越慢甚至退化为线性扫描，实测减少导出符号可显著降低加载延迟。
为什么符号导出数量直接影响动态库加载速度
动态链接器（如 Linux 的 ld-linux.so）在加载 .so 文件时，必须遍历所有导出符号来完成重定位和符号解析。导出符号越多，.dynamic 段越大，哈希表查找越慢，甚至触发线性扫描——尤其当多个库共存、符号名相似时，冲突概率上升，查找开销呈非线性增长。
实测显示：导出符号从 12,458 降至 1,203 后，链接时间从 3.8 秒减至 1.9 秒，二进制体积也下降约 17%。这不是编译期“看起来更干净”的问题，而是运行时真实可测的延迟源。
用 -fvisibility=hidden 默认隐藏所有符号
GCC/Clang 默认导出全部全局符号，这是最常见却最容易被忽略的性能陷阱。启用该标志后，只有显式标记为 default 的符号才会出现在动态符号表中。
- 在 CMake 中统一启用：
set(CMAKE_CXX_VISIBILITY_PRESET hidden)或直接加编译选项：target_compile_options(your_lib PRIVATE -fvisibility=hidden) - 必须配合
__attribute__((visibility("default")))显式导出对外接口，否则调用方会报undefined reference - Windows 不适用此法（默认不导出），但可用
__declspec(dllexport)替代；跨平台项目建议封装宏，如#define API_EXPORT __attribute__((visibility("default")))
头文件里别漏掉 extern "C" 和 visibility 控制
C++ 名称修饰（name mangling）本身不增加加载耗时，但若导出函数未用 extern "C" 声明，又没加 visibility 属性，会导致两个问题：一是 C++ 符号名过长，增大符号表体积；二是其他语言（Python/C#）调用时无法正确解析。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- 导出纯 C 接口时，头文件中必须包裹：
extern "C" { ... }，并在实现文件中用API_EXPORT标记函数 - 避免在头文件里直接写
__attribute__—— 这会让所有包含该头的翻译单元都受其影响；应只在定义处（.cpp）标注 - 模板函数不建议导出（除非显式实例化），否则每个使用点都可能生成重复符号，膨胀导出列表
用 nm -D 和 readelf -d 验证实际导出效果
优化不是靠猜。改完编译后，必须用工具确认是否真正减少了导出符号数，否则可能白忙一场。
-
nm -D libyour.so | wc -l查看动态符号总数（注意排除U类未定义符号） -
readelf -d libyour.so | grep NEEDED确认依赖库数量是否合理——过多依赖也会放大符号查找压力 - 发现意外导出？用
objdump -t libyour.so | grep "g.*F"定位未隐藏的全局函数，再回代码检查是否遗漏API_EXPORT或误用了static以外的 linkage
最容易被忽略的是：CMake 的 add_library(... SHARED) 默认不启用 -fvisibility=hidden，哪怕你在源码里写了 __attribute__，若没在编译选项里设默认策略，大量内部辅助函数仍会悄悄导出。这一步必须显式配置，不能依赖“写了属性就生效”。
