最小可行DLL需三点：显式导出函数（__declspec(dllexport)）、加extern “C”禁用c++名字修饰、运行时库设为/MT静态链接；避免导出类，分发前用dumpbin验证符号名，确保架构与调用方一致。
windows下用visual studio生成DLL的最小可行步骤
直接能被其他程序加载调用的DLL，核心就三点：导出函数、正确的调用约定、匹配的运行时库。VS默认项目模板容易埋坑，别选“动态链接库(DLL)”向导里的“空项目”或勾选“导出符号”，那会自动生成一堆你不需要的宏和样板代码。
- 新建项目选
Win32 项目→ 下一步 → 勾选DLL，**取消勾选“预编译头”和“安全开发生命周期检查”**（避免_CRT_SECURE_NO_WARNINGS等干扰） - 在主
.cpp文件里写函数，用__declspec(dllexport)显式导出，例如：extern "C" __declspec(dllexport) int add(int a, int b) { return a + b; } -
extern "C"是关键——禁用C++名字修饰，否则其他语言（如C#、python）根本找不到add这个符号 - 生成后检查输出目录是否有
.dll和.lib文件；.lib仅用于静态链接时的符号解析，分发时**不需要给用户**
导出C++类时为什么总加载失败
直接导出类几乎必然失败。DLL里的类对象内存布局、虚函数表、异常处理机制都依赖编译器和运行时版本，跨模块（尤其跨语言）极难对齐。不是不能做，而是成本远高于收益。
- 真正可靠的做法是：只导出纯C风格函数，用指针传递数据，内部用工厂函数管理对象生命周期
- 例如导出
__declspec(dllexport) void* create_processor()和__declspec(dllexport) void destroy_processor(void* p)，所有成员函数通过函数指针或回调方式暴露 - 若坚持导出类，必须确保调用方和DLL使用**完全相同的编译器版本、运行时库（/MD 或 /MT）、字节对齐设置**，且调用方也得用C++（比如另一个VS项目），否则
access violation或unresolved external symbol是常态
分发DLL时用户报“找不到 VCRUNTIME140.dll”怎么办
这是运行时库不匹配的典型表现。你的DLL依赖VS2015+的UCRT和C++运行时，但用户机器没装对应Visual C++ redistributable。
- 最稳妥方案：在项目属性 →
C/C++ → 代码生成 → 运行时库改为/MT（静态链接）——生成的DLL不再依赖外部vcruntime*.dll，体积略大但免部署烦恼 - 若必须用
/MD（动态链接），则需让用户安装对应版本的microsoft Visual C++ Redistributable，注意x86/x64位数必须严格一致 - 用
Dependency Walker（或更现代的Dependencies.exe）打开你的DLL，看它实际依赖哪些DLL；若出现VCRUNTIME140D.dll（带D后缀），说明你发布的是Debug版，**绝对不能分发**
Python或C#调用时提示“找不到指定的程序”或“入口点不存在”
这不是路径问题，而是符号名没对上。windows加载DLL后，是按**精确的函数名字符串**去查表的，任何修饰都会导致失败。
立即学习“C++免费学习笔记（深入）”；
- 用
dumpbin /exports your.dll查看实际导出的符号：如果没加extern "C"，你会看到类似?add@@YAHHH@Z这样的乱码名，C#的[DllImport]或Python的ctypes.CDLL().add肯定找不到 - C#中必须写
[DllImport("your.dll", CallingConvention = CallingConvention.Cdecl)]，且函数声明签名要和DLL里extern "C"导出的一致 - Python用
ctypes时，先cdll = CDLL("your.dll")，再通过cdll.add调用——前提是dumpbin里确实导出了add这个裸名 - 额外提醒：DLL路径必须在系统PATH里，或放在调用进程的当前工作目录，否则
LoadLibrary失败
分发DLL时最容易被忽略的，是目标机器的架构（x86 vs x64）和运行时库类型（/MT vs /MD）这两层匹配。哪怕函数逻辑完全正确，只要其中一层错，就是黑屏、崩溃或找不到入口点——连错误提示都可能被系统吞掉。