dllimport找不到dll时抛dllnotfoundexception，因clr未在搜索路径（当前目录→system32→path→基目录）中找到；需确保dll复制到输出目录并与exe同级，用process monitor定位查找路径。
DllImport找不到DLL文件的典型表现和定位方法
调用时抛出 System.DllNotFoundException，不是因为路径写错，而是CLR根本没在任何搜索路径里找到那个DLL。Windows加载DLL遵循严格顺序：当前目录 → 系统目录（System32）→ PATH环境变量所列目录 → 应用程序基目录（即 AppDomain.CurrentDomain.BaseDirectory）。
常见误操作是把DLL放在项目根目录或bin\Debug子目录下却没设“复制到输出目录”。必须确保编译后DLL真实存在于可执行文件同级目录（如MyApp.exe和native.dll在同一文件夹）。
- 在VS中右键DLL文件 → 属性 → “复制到输出目录”设为“始终复制”
- 若用.NET Core/.NET 5+，注意默认不继承系统
PATH，需手动调用SetDllDirectory或改用NativeLibrary.Load - 用
Process Monitor过滤进程名+操作“CreateFile”，看它到底去哪些路径找，比猜快得多
函数签名不匹配导致AccessViolationException或乱码
AccessViolationException或返回值明显异常（比如该返回int却得到负数大整型），90%是托管与非托管类型映射错误。C++导出函数的调用约定、字符编码、结构体内存布局，必须和C#端[DllImport]声明严丝合缝。
例如C++用__declspec(dllexport) int __cdecl add(int a, int b)，C#必须写[DllImport("native.dll", CallingConvention = CallingConvention.Cdecl)]；若C++用__stdcall却漏写CallingConvention，栈就会被错误清理，后续调用直接崩。
- 字符串参数优先用
string+[MarshalAs(UnmanagedType.LPStr)]对应C++的const char*，避免用char*指针引发GC移动问题 - 结构体必须加
[StructLayout(LayoutKind.Sequential, Pack = 1)]，否则C#默认按8字节对齐，而C++可能按1或4 - 导出函数名在DLL中可能被修饰（mangled），用
dumpbin /exports native.dll确认真实符号名，必要时在C++侧用extern "C"禁用修饰
64位/32位平台不匹配的静默失败
最隐蔽的问题：x64进程加载x86 DLL，或反过来，会直接抛BadImageFormatException，但有时只表现为函数返回0或空指针，尤其当DLL里有全局变量初始化逻辑时，错误发生在DllMain而未暴露给C#层。
VS项目属性里的“平台目标”（Platform Target）必须和DLL编译平台完全一致。不要选“Any CPU”——它在64位系统上默认跑x64，但若引用了x86 DLL，运行时就挂。
- 检查DLL架构：命令行执行
corflags native.dll（仅对.NET DLL有效），对原生DLL用file native.dll（Linux/macOS）或用sigcheck -a native.dll（Sysinternals） - C#项目属性 → “生成” → “平台目标”明确设为
x64或x86，取消勾选“首选32位” - 若需兼容多平台，得准备两套DLL，并在运行时根据
Environment.Is64BitProcess动态选路径
卸载DLL或跨模块内存管理引发的崩溃
Windows不允许卸载已加载的DLL（FreeLibrary后再次LoadLibrary仍用原实例），所以DllImport本质是进程级单例绑定。真正危险的是内存越界：C++分配的内存由C#释放，或反之。
比如C++导出一个char* get_message()返回堆内存，C#用Marshal.PtrToStringAnsi读完后，绝不能调用Marshal.FreeHGlobal——那块内存不是C#分配的，free会触发heap corruption。
- 原则：谁分配，谁释放。C++分配的内存，提供配套的
void free_message(char*)函数供C#调用 - 避免返回裸指针。改用输出参数：
void get_message(char* buffer, int size)，由C#传入StringBuilder并指定Capacity - 若DLL含全局状态或静态构造，多次加载/卸载（如插件场景）极易出问题，应设计为无状态或用
AppDomain隔离（.NET Framework）或AssemblyLoadContext（.NET Core+）
跨语言调用没有银弹，每个[DllImport]背后都藏着ABI契约。漏掉一个CallingConvention、少写一个MarshalAs、或者让32位和64位DLL混在一起，都会在深夜三点让你对着事件查看器里的Application Error发呆。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
