dumpbin /exports 和 nm -D 是唯一可靠导出符号查看方式：Windows 下 dumpbin 读 PE 导出目录，第三列名为 GetProcAddress 可用名；Linux/macOS 下 nm -D 读动态符号表，T 表示定义函数，需配合 undname/c++filt/Swift-demangle 解析修饰名。
直接看导出表，别猜函数名——dumpbin /exports 和 nm -D 是唯二可靠起点，其他方式基本绕弯或失效。
Windows 下用 dumpbin /exports 看真实导出符号
dumpbin 不解析调试信息、不依赖 PDB、不关心优化等级，它只读 PE 文件的 IMAGE_EXPORT_DIRECTORY，所以结果最可信。
-
dumpbin /exports mylib.dll输出里第三列（name）才是运行时能被GetProcAddress找到的符号名，不是源码里的函数名 - 如果看到
?add@Math@@YAHHH@Z这种，说明没加extern "C"，这是 MSVC 的 name mangling 结果，不能直接传给GetProcAddress（除非你硬写这个字符串） - 想确认它对应哪个原型？用 VS 自带的
undname：undname "?add@Math@@YAHHH@Z"→ 输出public: static int __cdecl Math::add(int,int) - 注意：
/exports:verbose不会自动 demangle，仍需手动过undname -
dumpbin对延迟加载 DLL 或仅含 .lib 的导入库无效——必须是已生成的真实.dll文件
Linux 下用 nm -D 看 dlsym 可见的符号
nm -D 读的是 .dynsym 动态符号表，和运行时 dlsym 查找范围完全一致，比 objdump -T 更轻量、更直接。
-
nm -D libmy.so输出中，首列为地址，第二列为类型，T表示本 SO 中定义的函数（text），U表示未定义（即外部依赖） - C++ 函数名仍是修饰态，如
_Z3addii；用c++filt _Z3addii可还原为add(int, int) - 如果
nm -D看不到某个函数，但nm -C能看到，说明它没被导出——大概率是编译时加了-fvisibility=hidden且没显式标__attribute__((visibility("default"))) -
objdump -T输出字段更全（含大小、绑定类型），但格式难 parse；若要脚本化过滤，建议先跑objdump -T libmy.so | head -5看清第二列标识符是F还是f，再写 awk
为什么 GetProcAddress/dlsym 找不到明明“存在”的函数？
符号出现在 dumpbin 或 nm -D 列表里，只是第一步。真正调用失败，往往卡在这三个地方：
立即学习“C++免费学习笔记（深入）”；
- Windows：没加
extern "C"→ 传给GetProcAddress的必须是 mangled 名，不是"add"，而是"?add@Math@@YAHHH@Z"；或者干脆改用GetModuleHandle+GetProcAddress配合undname确认真实符号 - Linux：函数被
-fvisibility=hidden静默屏蔽，即使写了__attribute__((visibility("default")))，链接时若加了-dead_strip（macOS）或--gc-sections（GCC），符号仍可能被裁掉 - 跨平台头文件没做条件编译 → Windows 用
__declspec(dllexport)，Linux 必须用__attribute__((visibility("default")))，混用会导致一方完全不导出
macOS 和 Swift 的特殊处理
macOS 上别折腾 objdump -T，GNU binutils 对 Mach-O 支持残缺；otool -Iv 虽能列导入/导出，但格式难提取；唯一稳的只有 nm -D。
-
nm -D libmy.dylib输出中，T表示本 dylib 定义的函数，U是外部引用；Swift 导出的符号形如$s4MyLib3addyySi_SitF，c++filt完全无效，必须用swift-demangle - Clang 默认启用
-fvisibility=hidden，哪怕加了 visibility 属性，也得检查链接命令是否含-dead_strip—— macOS 会静默丢弃未显式引用的符号，且不报错 - Swift 模块若未在
@_cdecl或@usableFromInline下导出，C++ 侧根本看不到任何符号，nm -D输出为空是正常现象
真正的难点不在工具命令本身，而在于理解：导出符号 ≠ 源码函数名，也不等于调试符号名；它是链接器和加载器共同约定的一套“运行时可见性协议”，漏掉任意一环（声明、编译、链接、加载），符号就断在半路。
