应直接用 dumpbin /exports 查 Windows DLL 导出表，或 nm -D 查 Linux .so 动态符号表，二者均精准反映运行时可调用符号；C++ 名称需用 undname 或 c++filt 解码，且须确保 visibility 和导出声明正确配置。
直接看导出表，别试图用 GetProcAddress 逐个试——它只能查已知名字，而你连名字都还没拿到。
Windows 下用 dumpbin /exports 最快最准
这是 Visual Studio 自带工具，不依赖调试信息、不被编译器优化干扰，直接读 PE 文件的导出表：
-
dumpbin /exports mylib.dll输出三列：序号、RVA（偏移）、符号名；关键看第三列 - C++ 函数名默认是修饰态（mangled），比如
?add@Math@@YAHHH@Z，不能直接传给GetProcAddress - 想得到可读原型，得配
undname ?add@Math@@YAHHH@Z解码；或者源码里加extern "C" __declspec(dllexport)强制 C 风格导出 - 注意：
dumpbin只处理真实.dll文件，对延迟加载 DLL 或只有.lib的导入库无效
Linux 下优先用 nm -D，不是 nm -C
nm -D 查的是动态符号表（.dynsym），对应运行时 dlsym 能查到的函数；nm -C 是全符号表，包含静态链接进来的、根本不可导出的函数：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
-
nm -D libmy.so输出形如00000000000011a0 T _Z3addii，其中T表示定义在本 so 中的函数 - 若编译时用了
-fvisibility=hidden（Clang 默认开，GCC 常见），没显式加__attribute__((visibility("default")))的函数不会出现在nm -D结果里 -
c++filt _Z3addii可还原为add(int, int)；但nm -D本身不 demangle，得手动过一遍 - 看到符号类型是
U（undefined），说明它来自外部依赖，不是本库导出的
macOS 上只信 nm -D
otool -Iv 虽能列导入/导出，但格式难解析；objdump -T 在 Mach-O 上基本不可用（GNU binutils 支持有限）：
立即学习“C++免费学习笔记（深入）”；
-
nm -D libmy.dylib输出类似0000000000000f80 T __Z3addii，T同样表示本 dylib 定义的函数 - Swift 导出的符号名修饰规则完全不同（如
$s4MyLib3addyySi_SitF），c++filt无效，必须用swift-demangle - 即使加了
__attribute__((visibility("default")))，若链接时被-dead_strip等裁剪选项静默丢弃，nm -D就彻底看不到
名字修饰只是表象，真正卡住人的永远是 ABI 兼容性和符号可见性设置——nm 或 dumpbin 显示存在，不代表你能 dlsym 或 GetProcAddress 成功调用。检查点不在工具输出，而在编译参数、导出声明、链接选项这三层是否咬合。
