加了namespace仍LNK2005或GetProcAddress失败，因namespace仅作用于编译期，DLL导出需__declspec(dllexport)在DLL编译时生效且须用宏区分场景，extern"C"禁用名字修饰但不兼容命名空间，DEF文件可锁定ABI。
加了 namespace 还是链接报 LNK2005 或运行时 GetProcAddress 失败？说明符号隔离没起作用——namespace 仅控制编译期作用域，对 DLL 导出无约束力。真正起效的是可见性控制机制，不是命名空间嵌套。
__declspec(dllexport) 必须在 DLL 编译时生效，且不能只写在头文件里
常见错误是把 __declspec(dllexport) 直接写在头文件中，然后被 EXE 工程包含。结果 EXE 编译时也尝试导出（无效），甚至触发编译警告或链接冲突。
- 必须用预处理器宏区分编译场景：DLL 工程定义
MYDLL_EXPORTS，EXE 工程不定义 - 头文件中统一用
MYDLL_API宏，定义为__declspec(dllexport)或__declspec(dllimport) - 类的构造/析构函数、虚函数表成员必须显式导出；只标在声明上不够，VC++ 要求定义处也带宏（或全部用宏包裹类定义）
- 模板函数/类不能直接导出，必须显式实例化后加宏，例如：
template class MYDLL_API std::vector;
extern "C" 是 C 接口导出的唯一可靠方式，namespace 在它面前完全失效
extern "C" 禁用名字修饰，符号名退化为纯标识符。此时若两个 DLL 都导出 init()，Windows 加载器无法分辨，必然冲突。
- 禁止在
extern "C"块内套namespace，语法合法但语义无效——导出名仍是init - 所有 C 风格接口必须带模块前缀，如
acme_v2_init()、acme_v2_shutdown() - 不要用
#define init acme_v2_init替换，这会让头文件污染全局命名空间，且调用方仍可能误用原始名 - 导出后务必用
dumpbin /exports mydll.dll验证符号名是否为干净的acme_v2_init，而非?acme_v2_init@@YAXXZ
-fvisibility=hidden + visibility("default") 是 Linux/macOS 下防泄漏的核心组合
GCC/Clang 默认导出所有非 static 全局符号，这是符号冗余和冲突的根源。不加 -fvisibility=hidden，单靠 visibility("default") 几乎没用。
- 编译动态库时必须加
-fvisibility=hidden -fpic，否则默认行为照旧 - 只对真正需要跨库调用的接口加
__attribute__((visibility("default")))，其余一律隐藏 - 类定义加该属性后，其成员函数自动继承可见性；但静态成员变量仍需单独标注
- 匿名命名空间或
static函数不能防止导出——只要被visibility("default")标记，照样进符号表
DEF 文件是绕过 C++ 名字修饰、锁定导出 ABI 的最后防线
当需要稳定导出名（比如供 Python ctypes 或 C# P/Invoke 调用），或多个 DLL 必须共存且导出同名逻辑函数时，DEF 文件比编译器属性更可控。
- DEF 中
init@1 = MyNamespace::init@0的等号右边必须是真实修饰名，可用dumpbin /symbols或nm -C查得 - @ 后数字代表参数字节数（
@0表示无参__cdecl，@4表示一个int），错配会导致调用崩溃 - VS 项目中需在「链接器 → 输入 → 模块定义文件」填入
mylib.def，否则不生效 - DEF 文件不替代头文件声明，调用方仍需按导出名（左边）声明函数原型
最容易被忽略的是：符号可见性控制必须贯穿整个构建链——从编译选项、宏定义、函数标记，到链接器配置，缺一不可。漏掉任意一环，比如忘了在 DLL 工程中定义 MYDLL_EXPORTS，或没加 -fvisibility=hidden，都会让前面所有隔离努力归零。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
