C# P/Invoke技术详解与实战避坑指南

1. 为什么P/Invoke是C#开发者的必修课

在Windows平台上做C#开发时，经常会遇到需要调用Win32 API或第三方原生DLL的情况。这时候P/Invoke（Platform Invocation Services）就成了连接托管代码和原生代码的桥梁。但很多开发者只是简单复制网上的DllImport示例，却不知道背后隐藏着多少技术细节和潜在陷阱。

我曾在项目中遇到过这样一个案例：一个看似简单的文件监控功能，在32位系统上运行良好，但在64位系统上频繁崩溃。经过两天排查才发现是P/Invoke调用时的结构体对齐问题。这种问题一旦发生，往往会导致难以追踪的内存错误。

2. P/Invoke的底层运行机制

2.1 CLR如何桥接托管与非托管世界

当C#代码通过DllImport调用原生函数时，CLR会执行以下关键步骤：

1. 在加载时验证DLL是否存在以及函数签名是否匹配
2. 生成适当的存根（stub）代码处理托管到非托管的转换
3. 安排参数从托管堆栈到非托管堆栈的传递
4. 转换调用约定（默认为StdCall）
5. 处理返回值和任何输出参数

这个过程中最耗时的部分是参数封送（Marshaling）。根据我的性能测试，一个简单的int参数传递会产生约20-30ns的开销，而字符串这样的引用类型可能达到100ns以上。

2.2 内存布局的魔鬼细节

结构体的内存对齐是P/Invoke中最容易出错的地方之一。考虑以下结构体定义：

csharp复制[StructLayout(LayoutKind.Sequential)]
public struct SYSTEM_INFO {
    public ushort processorArchitecture;
    public uint pageSize;
    // ...其他字段
}

在32位系统上，这个结构体默认是4字节对齐的。但在64位系统上，如果没有显式指定Pack值，CLR会使用8字节对齐。这会导致与原生DLL预期的布局不匹配。

经验法则：总是显式设置StructLayout的Pack属性，并通过sizeof()验证结构体大小是否与原生代码一致。

3. 那些年我踩过的P/Invoke坑

3.1 编码问题的幽灵