聊到.NET与原生代码的交互，DllImport这个词肯定是绕不开的。作为P/Invoke机制的核心，它就像一个桥梁，让托管世界的C#代码能够直接调用非托管DLL中的函数。今天，我们就来把这个话题拆开揉碎，系统地梳理一下它的用途、用法和那些容易踩的坑。
1. 它到底能干什么？
DllImport的核心使命很明确：让C#代码和C/C++、Delphi等语言写的DLL顺畅对话。具体来说：
- 跨语言调用：这是最基本的。托管代码和非托管代码之间，肉眼可见的数据类型差异、调用约定不同，都由P/Invoke来处理。
- 功能复用：很多底层能力，比如硬件驱动、系统API（如kernel32、user32），或者某些特定领域的数学库（如Intel MKL），都已经用C/C++写好了。与其在托管环境里重新发明轮子，不如直接调用。既省事，也可靠。
- 性能优化：对于高频计算、实时处理等极度敏感的场景，代码在非托管环境下运行通常效率更高。我们可以把性能瓶颈部分留在DLL里，需要时通过P/Invoke调用，算是“各取所长”。
2. 典型应用场景
| 场景 | 示例 |
|---|---|
| 硬件交互 | 调用驱动DLL控制设备，比如键盘锁定、传感器读取或USB通信。 |
| 系统级操作 | 访问Windows API（kernel32、user32等）或第三方系统级库。 |
| 旧代码集成 | 把历史遗留的C++库无缝嵌入到全新的.NET应用中。 |
| 高性能计算 | 调用非托管数学库（如Intel MKL）处理复杂的数值计算。 |
| 跨平台兼容 | 在.NET中调用平台特定的非托管代码（如Linux下的libc.so）。 |
3. 关键使用细节
基本语法
[DllImport("DLL名称.dll",
EntryPoint = "函数名",
CallingConvention = CallingConvention.StdCall,
CharSet = CharSet.Ansi)]
public static extern 返回类型 函数名(参数列表);
- DllImport 属性：指定了目标DLL的名称和函数的签名信息。
- EntryPoint：可选。如果托管的函数名和DLL中的函数名不一样，就靠它来指定。
- CallingConvention：必须匹配非托管函数的调用约定（是StdCall、Cdecl还是ThisCall等），否则程序会“摔”得很惨。
- CharSet：指定字符串的编码方式（Ansi或Unicode），防止乱码。
调用约定
这块容易出错，简单说几种常见的：
- StdCall：Windows API的默认选择，由被调用者负责清理堆栈。
- Cdecl：C语言默认，由调用者清理堆栈，支持可变参数。
- ThisCall：专门用于C++类的成员函数。
数据类型映射
托管和非托管世界的“语言”不同，需要一个翻译官。这张表可以作为速查手册：
| 托管类型 | 非托管类型 | 示例 |
|---|---|---|
| int | int、long（32位） | [DllImport] public static extern int Add(int a, int b); |
| string | char*（ANSI） | 通常用MarshalAs(UnmanagedType.LPStr)或IntPtr处理。 |
| bool | BOOL（4字节） | 日常映射为int（非零即真）。 |
| struct | struct | 托管结构体需用[StructLayout(LayoutKind.Sequential)]定义。 |
| IntPtr | 通用指针 | 用来处理void*或动态分配的内存。 |
4. 常见问题与解决方案
既然要上手，就免不了碰到几个“老朋友”问题：
DLL 加载失败
原因：最常见的就是DLL找不到。它可能没在程序目录、系统PATH环境变量里。 方案：
- 把DLL复制到输出目录。
- 直接用绝对路径（比如[DllImport(@"C:\path\to\dll.dll")]）。
- 更灵活的方式是动态加载：用LoadLibrary + GetProcAddress。
调用约定不匹配
现象：程序崩溃、堆栈被破坏。 方案：检查DLL函数文档，确保CallingConvention参数设置准确。
内存管理混乱
问题：非托管代码分配的内存，托管环境不会自动回收。 方案：用Marshal.FreeHGlobal或Marshal.FreeCoTaskMem手动释放。如果要操作指针，最好用IntPtr，并封装对应的释放逻辑。
字符串处理冲突
问题：乱码。 方案：明确CharSet。Unicode对应wchar_t*。也可以用Marshal.StringToHGlobalAnsi/Uni进行数据转换。
5. 高级技巧
动态加载 DLL
有时候不希望程序启动时就加载DLL，或者DLL路径不确定。这时候可以动态操作：
[DllImport("kernel32.dll", SetLastError = true)]
private static extern IntPtr LoadLibrary(string dllToLoad);
[DllImport("kernel32.dll", SetLastError = true)]
private static extern IntPtr GetProcAddress(IntPtr hModule, string procedureName);
public static void LoadDllDynamically()
{
IntPtr hDll = LoadLibrary("CompalLockInput.dll");
if (hDll != IntPtr.Zero)
{
IntPtr funcAddr = GetProcAddress(hDll, "LockKeyboard");
// 后续通过委托调用函数...
}
}
结构体与指针
传递结构体时，记得用ref关键字。比如：
[StructLayout(LayoutKind.Sequential)]
public struct Point
{
public int X;
public int Y;
}
[DllImport("Graphics.dll")]
public static extern void DrawPoint(ref Point point);
错误处理
非托管函数调用失败后会设置错误码。开启SetLastError = true，然后通过Marshal.GetLastWin32Error来捕获：
[DllImport("kernel32.dll", SetLastError = true)]
public static extern bool CloseHandle(IntPtr hObject);
// 调用后检查错误码
if (!CloseHandle(handle))
{
int errorCode = Marshal.GetLastWin32Error();
Console.WriteLine($"错误码: {errorCode}");
}
6. 替代方案
P/Invoke虽然强大，但有时也有更合适的替代：
- C++/CLI：用混合模式程序集封装非托管代码。写起来可能复杂点，但能得到一个更安全的托管接口。
- COM 互操作：如果DLL本身就是COM组件，用tlbimp生成托管包装会更省力。
- SWIG：适用于复杂的C/C++库，它可以自动生成C#绑定。
7. 总结
DllImport是集成现有非托管功能或者调用高性能代码时的“瑞士军刀”。但它也伴随着风险：
- 风险点：内存泄漏、类型不匹配、调用约定错误。
- 最佳实践：
调用前先搞定CallingConvention和CharSet。 把非托管调用封装起来，把那些“脏活累活”藏到内部。 如果可以，优先考虑托管库或者C++/CLI来替代P/Invoke，毕竟更安全可控。
总的来说，只要用对、用好，它就能帮助开发者高效地复用已有的优秀代码，让.NET应用的能力边界大大扩展。
