在桌面端或工业控制软件开发里，使用C#编写界面层而把核心算法放在C++编译的DLL中是常见架构。当C++接口需要接收一批采样数据，并以结构体数组形式暴露给外部调用者时，C#一侧如果照搬普通数组传参，大概率会在运行期抛出AccessViolationException或者得到错乱的数值。问题的核心并不是语法写错，而是托管堆里的数组和被调用方期待的连续非托管内存块之间存在鸿沟。只有理解两者内存模型差异，才能选对封送路线。
明确C++导出接口与结构体布局约定
任何可靠的互操作都始于对C++侧契约的精确掌握。假设C++工程导出一个函数，用来处理一组设备状态记录，其结构体包含整型ID、浮点数值与定长字符描述。C++编译器默认会根据成员类型做对齐填充，例如在三十二位下可能按四字节或八字节对齐，这与C#结构体若不加干预时的布局并不天然一致。我们必须要求双方使用相同的字节对齐方式，否则同一个结构体在两边的大小不同，数组整体偏移便会错位。
在C++头文件中，通常会用#pragma pack或者__declspec(dllexport)配合extern "C"来避免名称修饰。对应的C#结构体必须用[StructLayout(LayoutKind.Sequential, Pack = 1)]这类特性显式声明顺序布局与对齐字节。如果C++端用了pack(1)，C#端也必须写Pack = 1，少写一行就可能让数组第二个元素整体偏移几个字节。下面给出一个最小可对照的C++定义与C#映射示例，注意字符数组要用ByValTStr并在StructLayout里指定CharSet。
// C++ 头文件 device.h
#pragma pack(push, 1)
struct DeviceData {
int id;
float value;
char name[16];
};
#pragma pack(pop)
extern "C" __declspec(dllexport) int ProcessDevices(DeviceData* arr, int count);
// C# 映射
using System;
using System.Runtime.InteropServices;
[StructLayout(LayoutKind.Sequential, Pack = 1, CharSet = CharSet.Ansi)]
public struct DeviceData {
public int id;
public float value;
[MarshalAs(UnmanagedType.ByValTStr, SizeConst = 16)]
public string name;
}
class NativeLib {
[DllImport("device.dll", CallingConvention = CallingConvention.Cdecl)]
public static extern int ProcessDevices(IntPtr arr, int count);
}
</code>
使用Marshal手动分配非托管数组并写入数据
第一种稳妥方案是在C#里不依赖默认封送，而是用Marshal类在非托管堆上开出一块连续内存，把每个结构体逐个写进去，再把首地址传给DLL。这种写法虽然代码量稍多，但每一步内存归属都清晰，不会因垃圾回收移动托管数组而导致指针失效。尤其在需要回调或异步调用时，手动分配的内存生命周期完全由开发者控制，是最不容易踩坑的做法。
具体步骤是先算出单个结构体的非托管大小，用Marshal.SizeOf获取，再乘以数组长度得到总字节数，调用Marshal.AllocHGlobal拿到IntPtr。随后循环使用Marshal.StructureToPtr把托管结构体拷入对应偏移。调用完C++函数后，若C++只做读取，我们可以直接释放；若C++修改了内容并需要回读，则还要用Marshal.PtrToStructure把数据拷回托管侧。下面示例展示传参并取回结果的完整过程。
DeviceData[] managed = new DeviceData[3];
managed[0] = new DeviceData { id = 1, value = 12.3f, name = "A1" };
managed[1] = new DeviceData { id = 2, value = 45.6f, name = "B2" };
managed[2] = new DeviceData { id = 3, value = 78.9f, name = "C3" };
int size = Marshal.SizeOf(typeof(DeviceData));
IntPtr ptr = Marshal.AllocHGlobal(size * managed.Length);
try {
for (int i = 0; i < managed.Length; i++) {
Marshal.StructureToPtr(managed[i], ptr + i * size, false);
}
int ret = NativeLib.ProcessDevices(ptr, managed.Length);
// 若DLL修改了内容，回读
for (int i = 0; i < managed.Length; i++) {
managed[i] = (DeviceData)Marshal.PtrToStructure(ptr + i * size, typeof(DeviceData));
}
}
finally {
Marshal.FreeHGlobal(ptr);
}
这种方案的优点是没有对数组元素个数做隐式假设，也不会因为C#数组被GC压缩而崩溃。缺点是每次调用都有分配、拷贝、释放的成本，当数组长度达到几十万时，性能开销需要评估。此外，字符串字段因为是定长字符数组，在StructureToPtr时会按CharSet转码，若C++端是Unicode而C#写成Ansi，就会出现中文乱码，所以字符集必须双向核对。
通过unsafe与fixed固定托管数组提升性能
当调用频率极高且结构体较简单时，手动Marshal的拷贝开销可能成为瓶颈。此时可开启C#项目的AllowUnsafeBlocks，用unsafe上下文配合fixed语句把托管数组直接钉在内存中，把指针传给C++。这样做省去了非托管内存分配与逐元素拷贝，适合实时数据采集场景。但要注意，fixed块执行期间垃圾回收器不会移动该数组，一旦超出作用域钉住解除，指针立刻失效，绝不能把指针缓存起来异步使用。
为了让fixed能取到结构体数组的指针，C#结构体本身必须是非托管兼容类型，即所有字段都是基元类型或定长数组，且同样需要StructLayout顺序对齐。声明DLL导入时参数类型改为对应指针，例如DeviceData*。下方代码演示了在unsafe方法中直接传入托管数组首地址的做法，并说明为何不能在fixed外保留指针。
// 项目需勾选允许不安全代码
[DllImport("device.dll", CallingConvention = CallingConvention.Cdecl)]
public static unsafe extern int ProcessDevices(DeviceData* arr, int count);
class Test {
public static unsafe void Run() {
DeviceData[] data = new DeviceData[3];
data[0].id = 1; data[0].value = 1.1f; data[0].name = "X";
// 填充其余元素...
fixed (DeviceData* p = data) {
int r = ProcessDevices(p, data.Length);
} // 此处钉住结束，p不可用
}
}
从工程维护角度看，unsafe方案代码更短、运行更快，但对团队有额外要求：必须理解指针与GC协作机制，且静态分析工具会标记风险。若C++函数内部会把指针存到全局变量延后访问，则fixed方案绝对不可用，只能回到Marshal持久化内存。实践中建议封装一层托管包装函数，在内部根据数组大小自动选择策略，既保证安全又兼顾性能。
常见错误排查与字符集对齐提醒
即便布局写对，仍有两类高频错误。其一是忽视CallingConvention，C++默认cdecl而C#默认Winapi，不匹配会让栈损坏，现象是第一次调用正常第二次崩溃。其二是结构体里包含bool类型，C#的bool是四字节而C++的bool常是一字节，应改用[MarshalAs(UnmanagedType.U1)]映射。还有字符串字段若用string而非ByValTStr，默认会封送成指针而非内嵌数组，导致结构体尺寸完全不同。
另一个隐蔽问题是数组长度与count参数不一致。有些开发者在C#里用list.ToArray()后修改了list却忘了同步count，C++越界写入会破坏堆。建议在封装方法里直接用array.Length传入，不要手动填数字。最后，在调试阶段可以临时在C++侧打印sizeof(DeviceData)和C#侧Marshal.SizeOf的值，二者不相等就立刻停手检查Pack与字段类型，这是成本最低的自检手段。