__declspec(dllexport) 是 Windows 专属语法，Linux 下 GCC/Clang 不识别，直接使用会编译报错；正确做法是用预处理器按平台隔离：Windows 用 __declspec(dllexport)，Linux/macOS 用 __attribute__((visibility("default"))) 并配合 -fvisibility=hidden 编译选项。
为什么 __declspec(dllexport) 在 Linux 上根本不起作用
因为它是 Microsoft Visual C++ 的 Windows 专属扩展，GCC/Clang 完全不识别。直接在跨平台代码里写这个宏，Linux 下编译会报错：error: expected identifier before '__declspec'。不是兼容性差，是语法层面就不合法。
正确做法是用预处理器隔离平台逻辑：
#ifdef _WIN32
#define EXPORT_API __declspec(dllexport)
#elif defined(__GNUC__) || defined(__clang__)
#define EXPORT_API __attribute__((visibility("default")))
#else
#define EXPORT_API
#endif
注意两点：一是必须同时检查 __GNUC__ 和 __clang__（Clang 默认兼容 GCC 宏但不定义 __GNUC__）；二是 Linux/macOS 下仅靠 visibility("default") 不够——你还得在链接时加 -fvisibility=hidden 编译选项，否则该属性默认不生效。
extern "C" 能防 C++ 名字修饰，但挡不住函数重载冲突
加 extern "C" 确实能让 void foo(int) 和 void foo(double) 都导出为简单符号 foo，但这会导致链接器报错：multiple definition of 'foo'。C 链接规范下不允许同名函数存在。
立即学习“C++免费学习笔记（深入）”；
真实场景中要导出重载函数，只能放弃 C 链接，接受名字修饰（mangling），并用平台工具解析符号：
- Windows：用
dumpbin /exports your.dll查看类似?foo@@YAXH@Z的修饰名 - Linux：用
nm -D your.so | c++filt还原为可读形式 - macOS：用
nm -gU your.dylib，符号带_Z前缀
如果你控制调用方，建议统一用 C 接口封装——每个重载函数起唯一 C 风格名，比如 foo_int、foo_double，避免运行时符号解析歧义。
动态库加载时 dlopen 找不到符号？先查符号可见性与导出列表
常见现象：Linux 下 dlopen 成功，但 dlsym 返回 nullptr，错误是 undefined symbol: xxx。这往往不是路径问题，而是符号根本没导出。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
验证步骤必须按顺序做：
- 确认编译时加了
-fvisibility=hidden，且目标函数用了EXPORT_API - 用
readelf -d your.so | grep NEEDED检查是否意外依赖了其他未安装的库 - 用
objdump -T your.so | grep your_symbol直接查符号是否出现在动态符号表里（-T而非-t）
特别注意：GCC 10+ 默认启用 -fPIE，若动态库含全局构造函数（如 __attribute__((constructor))），可能触发地址空间布局冲突，导致 dlopen 失败——此时需显式加 -fPIC 并避免非常规初始化代码。
Windows DLL 导出时 .def 文件比 __declspec 更可靠
当导出大量函数或需要精确控制序号（ordinal）、别名（alias）时，__declspec(dllexport) 容易漏写、难维护，且无法指定序号——而序号对老版本 Windows 兼容性很关键。
一个最小可用的 mylib.def：
LIBRARY mylib.dll
EXPORTS
init @1
process_data @2
cleanup @3
然后编译命令里显式引用：link /DLL /DEF:mylib.def ...。这样导出的符号不会受 C++ 名字修饰影响，也不依赖头文件宏定义一致性。缺点是没法自动导出模板实例化函数——这类必须回到 __declspec + 显式实例化。
真正棘手的是混合使用：如果头文件里既有 __declspec 又有 .def，链接器优先按 .def 列表裁剪，其余 __declspec 标记会被静默忽略——调试时容易误判导出失败原因。
跨平台项目里，符号导出不是“写对就行”的事，而是编译器、链接器、加载器三方规则叠加的结果。哪怕一行宏、一个编译选项、一次 nm 命令的疏忽，都可能让动态库在某个平台彻底不可用。
