简介面向需要在 .NET 环境中调用 C 动态链接库的开发者这份资源以“函数参数包含指针”这一常见难点为切入点演示如何借助 P/Invoke 完成跨语言互操作。示例同时包含 C# 调用端Form、DllImport 声明、Marshal 内存管理与 C 导出端MySum、Sum 工程可对照学习调用约定、指针类型映射、unsafe 代码及内存释放等关键环节。压缩包共 46 个文件涵盖 cs/cpp/h/dll/lib/exe/sln 等主要类型既有源码与工程文件也有编译生成的库与可执行文件便于直接运行调试。资源大小 4.87MB轻量易获取目前已有 8819 人学习下载适合希望快速掌握 C# 与 C 互操作、避免内存泄漏和平台不兼容踩坑的中高级 .NET 开发者。完整工程目录结构清晰配 ReadMe 说明与多种配置不仅可用于理解理论也可作为团队协作或二次开发的参考模板。1. C#调用C DLL指针参数是第一个拦路虎做跨语言调用时很多人第一次在 C# 里调用 C 的 DLL就被“函数参数包含指针”这几个字卡住了。明明 C 那边接口清清楚楚到了 C# 这边却不知道用int、ref int还是IntPtr去接更要命的是程序一运行就报内存访问冲突连崩溃在哪一行都看不出来。这篇文章要解决的就是这个问题帮你把 C DLL 里那些带指针的接口函数在 C# 里一个个安全、正确地调通。这里说的“指针参数”泛指四类常见场景基础类型指针如int*、结构体指针、字符串指针char*以及函数指针回调。它们对应的 C# 映射方案完全不同选错了轻则数据对不上重则直接进程崩溃。这篇笔记面向正在做跨平台系统集成或现有 C 模块移植的开发者用实际能跑的代码把每一种情况拆开讲最后再给几个我踩过的坑帮你绕开那些文档里根本不写的陷阱。2. 先把平台调用搭起来DllImport、调用约定与 32/64 位2.1 DllImport 最简骨架从 extern 到入口点C# 调用 C DLL 的核心机制是平台调用P/Invoke入口就是DllImport特性。你得先搞清楚三件事DLL 文件路径、函数入口点名字、参数怎么封送。最常见的写法是[DllImport(MyNativeLib.dll, CallingConvention CallingConvention.Cdecl, CharSet CharSet.Ansi)] private static extern int CalculateSum(int* numbers, int count);这里DllImport的第一个参数是 DLL 的名字运行时会在当前目录、系统目录和 PATH 环境变量里找。CallingConvention.Cdecl告诉 CLR 按 C 语言的调用约定来清理栈C 项目里如果没显式指定__stdcall默认就是 Cdecl两边必须对齐。CharSet影响字符串参数的编码方式C 那边是char*就用 Ansi是wchar_t*就用 Unicode。一个常见的坑是把函数名写错或忽略了大小写。C 编译出来的函数名在 DLL 里可能被修饰过了比如CalculateSum在 32 位下可能变成_CalculateSum8。你可以用EntryPoint字段精确指定[DllImport(MyNativeLib.dll, EntryPoint CalculateSum, CallingConvention CallingConvention.Cdecl)] private static extern int CalculateSum(int[] numbers, int count);EntryPoint可以同时解决两个问题一是避开 C 名字修饰的差异二是让 C# 端的函数名和 C 端不一样也能调。2.2 函数签名对齐的关键int* 对应的不是 int[]很多从 C# 入门的开发者第一反应是把int*映射成int[]这在部分场景下确实能跑但不是放之四海皆准。一维数组在封送时是以指针方式传递的所以下面两种写法效果很接近// 写法A用 int[] 接收 [DllImport(MyNativeLib.dll)] private static extern int SumArray(int[] data, int count); // 写法B用 IntPtr 显式指过去 [DllImport(MyNativeLib.dll)] private static extern int SumArray(IntPtr dataPtr, int count);两种写法的差别在语义上int[]让 CLR 帮你自动固定托管数组并取其首元素地址代码简洁IntPtr是完全手动控制适合指针可能指向非托管内存的场景。需要改值且改完要带回 C# 的用ref或out只读的用int[]或IntPtr都行。实际项目里我一般遵循这条选型线参数是标量指针就用ref T参数是数组且函数内只读就用T[]参数是数组且函数要改变元素个数或重新分配内存直接用IntPtr配合 Marshal 操作。这条线捋清楚后面所有接口都能套。2.3 平台位数与编译选项DLL 是 32 位还是 64 位指针参数最容易翻车的不是类型映射而是平台位数对不上。C# 进程是 64 位DLL 是 32 位加载时直接报BadImageFormatException。解决方案很简单把 C DLL 和 C# 程序编成同一个位数或者在 C# 里把平台目标改为 x86 来匹配 32 位 DLL。在 C 工程里你可以在项目属性中把“平台”设置为 x64 重新编译一份 64 位 DLL。如果拿到的 DLL 只有 32 位版本、一时没有源码C# 这边只能把“项目属性 → 生成 → 平台目标”改成 x86。注意这不是改一行配置那么简单你的 C# 程序里所有依赖的托管 DLL 也得都是 AnyCPU 或 x86否则会连锁报错。3. 指针参数的类型映射ref、out 与 IntPtr 到底怎么选3.1 能改值的标量参数用 ref 和 outC 里最常见的指针参数是输出参数函数通过解引用修改变量的值。比如void GetVersion(int* major, int* minor);C# 这边的标准映射就是ref[DllImport(MyNativeLib.dll, CallingConvention CallingConvention.Cdecl)] private static extern void GetVersion(ref int major, ref int minor); int major 0, minor 0; GetVersion(ref major, ref minor); Console.WriteLine($版本号{major}.{minor});用ref时CLR 会把托管变量的地址传给 CC 修改的就是 C# 变量本身。这在语义上和 C 的传地址完全一致。如果 C 函数不读入值、只写入也可以把ref改成out[DllImport(MyNativeLib.dll)] private static extern void GetVersion(out int major, out int minor); GetVersion(out int major, out int minor);out和ref在封送层面没有本质区别但out明确告诉 CLR 这个参数不需要初始化调用前不用赋值代码意图也更清晰。这里有个细节有些 C 接口函数会先读入参数值再决定行为比如int ResizeBuffer(int* capacity)内部先判断*capacity是否大于某个阈值。这种就必须用ref因为调用前参数里要有值。3.2 只读指针与未知结构IntPtr 是万能兜底当指针指向的是一个不透明结构或者 C 那边是一个void*ref和out都无能为力这时候IntPtr是唯一的选择。比如 C 有这样一个接口typedef struct _NativeContext NativeContext; int NativeProcess(NativeContext* ctx, const char* input);因为NativeContext是前向声明的C# 这边根本看不到它的内部布局也就没法定义对应的结构体。正确做法是让 C 提供一个NativeContext* CreateContext()返回的指针直接作为IntPtr存起来后续所有操作都把IntPtr原样传回去[DllImport(MyNativeLib.dll)] private static extern IntPtr CreateContext(); [DllImport(MyNativeLib.dll)] private static extern int NativeProcess(IntPtr ctx, string input); IntPtr ctx CreateContext(); int result NativeProcess(ctx, hello);IntPtr的本质是一个和 CPU 位宽一致的无符号整数32 位进程里是 4 字节64 位进程里是 8 字节。它本身不携带类型信息所以用起来自由度最大但也最容易滥用。原则是能用强类型ref、out、结构体表达清楚的地方尽量用强类型只有面对不透明句柄Handle或 C 里刻意隐藏的结构体时才退回IntPtr。3.3 需要分配内存的接口配合 Marshal.AllocHGlobal 使用有一类接口函数会自己分配内存并返回指针或者接受一个指针变量作为输出。比如 C 函数声明如下int GetData(int** outBuf, int* outLen);函数内部malloc一段缓冲把地址写入outBuf。此时 C# 端需要用IntPtr来接收这个地址[DllImport(MyNativeLib.dll)] private static extern int GetData(out IntPtr outBuf, out int outLen); IntPtr bufferPtr; int len; GetData(out bufferPtr, out len); byte[] result new byte[len]; Marshal.Copy(bufferPtr, result, 0, len);拿到指针之后必须注意释放内存的问题。如果 C 那边用malloc分配的就得让 C 提供对应的释放函数如果提供的是free(void*)的封装C# 这边可以这样调[DllImport(MyNativeLib.dll)] private static extern void FreeBuffer(IntPtr buf); FreeBuffer(bufferPtr);很多人在这里图省事用Marshal.FreeHGlobal去释放一旦 C 那边用的是new[]或malloc内存管理器不一致会直接崩溃。跨语言的内存分配和释放必须在同一边这是铁律。4. 结构体指针与字符串指针两类高频传址的完整解法4.1 结构体按引用传址LayoutKind.Sequential 与 ref 组合结构体指针是除基础类型之外最高频的传址场景。比如 C 有一个配置结构体和对应接口typedef struct { int width; int height; int channels; } ImageConfig; int ApplyConfig(ImageConfig* cfg);C# 这边要先定义结构体再指定内存布局[StructLayout(LayoutKind.Sequential)] public struct ImageConfig { public int width; public int height; public int channels; } [DllImport(MyNativeLib.dll)] private static extern int ApplyConfig(ref ImageConfig cfg); ImageConfig cfg new ImageConfig { width 1920, height 1080, channels 3 }; ApplyConfig(ref cfg);LayoutKind.Sequential让 CLR 按字段声明顺序、以默认对齐规则排列结构体内存和 C 侧struct的内存布局一致。如果不写这个特性托管结构体的布局是由 CLR 决定的内存顺序通常和声明不一致C 读到的字段就全乱了。这里最隐蔽的坑是字段类型的对齐差异。C# 的bool占用 1 字节C 的bool也占 1 字节但如果你 C 侧用的是int而 C# 侧用了bool字段类型错位会导致整个结构体后面的成员全部偏移。从 C 侧抄结构体定义时字段类型要原样对照不要自行“优化”。4.2 结构体数组指针IntPtr Marshal.PtrToStructure 逐个取当 C 接口要返回一个结构体数组时情况比单结构体传址复杂一些。假设接口如下int GetResults(ResultStruct* outResults, int count); typedef struct { int id; float score; } ResultStruct;C 那边要求 C# 分配足够的内存来承接结果C# 侧有两种做法。第一种是托管数组直接传[StructLayout(LayoutKind.Sequential)] public struct ResultStruct { public int id; public float score; } [DllImport(MyNativeLib.dll)] private static extern int GetResults(ResultStruct[] results, int count); ResultStruct[] results new ResultStruct[10]; GetResults(results, results.Length);这种写法依赖 CLR 自动固定数组并传递首地址C 写入的实际就是托管数组的内层内存函数返回后 C# 数组已经更新。第二种更灵活的做法是用IntPtr分配非托管内存再逐一取回IntPtr buffer Marshal.AllocHGlobal(Marshal.SizeOfResultStruct() * 10); GetResults(buffer, 10); ResultStruct[] results new ResultStruct[10]; for (int i 0; i 10; i) { IntPtr itemPtr IntPtr.Add(buffer, i * Marshal.SizeOfResultStruct()); results[i] Marshal.PtrToStructureResultStruct(itemPtr); } Marshal.FreeHGlobal(buffer);两种写法的取舍看场景C 函数如果只要求一块连续内存托管数组足够如果函数要重新分配内存或改变数组长度就必须走IntPtr路线。用IntPtr.Add而不是buffer i * size是避免算错字节偏移的安全做法64 位下指针偏移按字节算很容易漏掉sizeof。4.3 字符串指针StringBuilder 与强制编码C 的char*参数在 C# 里最常见的映射是string或StringBuilder。区别在于string是不可变的适合只读传参StringBuilder是可变的适合 C 往里写字符串。比如void GetUserName(char* buffer, int bufferSize);C# 调用[DllImport(MyNativeLib.dll, CharSet CharSet.Ansi)] private static extern void GetUserName(StringBuilder buffer, int bufferSize); StringBuilder sb new StringBuilder(256); GetUserName(sb, sb.Capacity); string name sb.ToString();这里的CharSet.Ansi决定了字符串按 ANSI 编码封送StringBuilder被预分配 256 字符的缓冲C 往里写时不会越界。如果 C 用的是wchar_t*CharSet要改成Unicode同时StringBuilder的容量要覆盖 Unicode 字符数的两倍字节数。很多老接口直接返回const char*比如const char* GetVersion()这种返回值映射成string是安全的CLR 会把非托管字符串复制一份到托管堆C 那边释放内存不影响 C# 端。但如果返回的是char*且指向内部缓冲区后续对该缓冲区的任何修改都会反映到 C# 字符串上——这时最好立刻ToString()复制一份出来。5. 避坑手册指针参数翻车的五种典型现场5.1 内存对齐与结构体布局不符数据错位但程序不崩现象结构体传进去后C 读到的width是 0height是 1920字段整体错位。程序能运行只是输出全是乱值。原因C# 结构体没加[StructLayout(LayoutKind.Sequential)]或者加了但字段顺序与 C 不一致。CLR 默认的布局策略会重排字段以优化内存占用造成两边内存结构不匹配。解决给结构体显式声明[StructLayout(LayoutKind.Sequential)]并逐字段核对 C 头文件里的声明。如果 C 结构体用了#pragma pack(push, 1)调整对齐C# 侧还要写Pack 1[StructLayout(LayoutKind.Sequential, Pack 1)]5.2 32/64 位不匹配导致加载即崩现象DllNotFoundException或BadImageFormatException程序启动即异常。原因C DLL 是 32 位的而 C# 进程跑在 64 位上或者反过来。解决在 C 工程里针对 C# 进程位数重新编一份 DLL保持两边一致。如果拿不到 64 位 DLLC# 项目平台目标改为 x86。在解决方案里可以加个生成后事件把对应位数的 DLL 复制到输出目录避免“能编译但找不到 DLL”的尴尬。5.3 用错内存释放函数导致堆损坏现象调用释放函数时程序崩溃或者过了很久才在随机位置崩溃一次错误信息毫无规律。原因C 用malloc分配的内存被 C# 用Marshal.FreeHGlobal释放两边堆管理器不是同一个。Windows 上 CRT 不同版本之间也可能有隔离。解决谁分配、谁释放。C 接口里实现一个对应的释放函数C# 只调用它。如果第三方 DLL 没提供释放函数优先考虑不持有它分配的内存在 C# 侧自行分配缓冲传进去。5.4 缓冲区大小预判不足导致内存越界现象调用函数后 C# 侧抛出AccessViolationException或者周围变量的值无故变化。原因C 函数按约定向char*或byte*写数据但 C# 传入的缓冲区容量不够C 写越界了。越界写入不一定会立刻崩溃破坏的可能是托管堆上的其他对象。解决预估最坏情况下的缓冲大小通常通过函数名中带Size的参数获取或直接传一个足够大的值。拿不准时用StringBuilder的容量字段和Capacity反复核对C 侧每写一个字符都要检查当前偏移是否到达末尾。5.5 回调函数指针委托被 GC 回收导致调用无效现象回调在前几次调用正常运行一段时间后 C 侧回调报错或程序闪退。原因C 端保存了 C# 委托的函数指针但 C# 侧的委托对象没有引用被垃圾回收回收掉了C 再调用时就访问了已释放的内存。解决在 C# 侧用一个静态字段或长期存活的对象持有委托private static CallbackDelegate _callback; [DllImport(MyNativeLib.dll)] private static extern void RegisterCallback(CallbackDelegate callback); _callback new CallbackDelegate(OnNativeCallback); RegisterCallback(_callback);只要_callback还存活C 持有的函数指针就有效。这在长时间运行的程序里属于必备操作。6. 指向任意内存的 Copymem用 IntPtr 做内存块搬运的通用速写最后落一个非常实用的技巧当你手头有一个IntPtr指向非托管内存又希望把它转成byte[]做后续处理时可以直接用Marshal.Copy走一个万用通道这也是调试任何指针参数时最常用的验证手段。static byte[] ReadMemory(IntPtr ptr, int length) { if (ptr IntPtr.Zero) throw new ArgumentException(指针不能为空); byte[] data new byte[length]; Marshal.Copy(ptr, data, 0, length); return data; } static void WriteMemory(IntPtr ptr, byte[] data) { if (ptr IntPtr.Zero) throw new ArgumentException(指针不能为空); Marshal.Copy(data, 0, ptr, data.Length); }这段代码的思路很直接不关心指针到底指向什么结构先按字节原样搬到托管数组里再用BitConverter或自定义解析去按偏移读字段。调接口时先用这个函数把指针指向的内存快照出来int就取第 0 到 3 字节float就取第 4 到 7 字节C 结构体布局一目了然比自己猜强得多。验证一个带指针参数的接口是否调用正确我现在的习惯是三步走第一步用上面ReadMemory把 C 写回的内存快照打出来核对每个字段偏移上的值第二步主动把一个IntPtr指向已知数据的托管数组用WriteMemory写进去再传给 C看 C 能不能读到预期输入第三步才放开手脚接真实数据。这三步走完接口到底有没有接对基本没有玄学空间。从那以后我每次接新的 C DLL都会强制先写一遍ReadMemory和WriteMemory这对工具函数再开始定义结构体和DllImport。无论是结构体对齐问题还是缓冲区越界在这两招面前都无处遁形。希望这套经验帮到你少走几步冤枉路。本文还有配套的精品资源点击获取 
长河君 · 2026/10/19 7:49:40 · 阅读 1.2k C#调用C++ DLL指针参数完全指南：从DllImport到Marshal避坑手册
简介面向需要在 .NET 环境中调用 C 动态链接库的开发者这份资源以“函数参数包含指针”这一常见难点为切入点演示如何借助 P/Invoke 完成跨语言互操作。示例同时包含 C# 调用端Form、DllImport 声明、Marshal 内存管理与 C 导出端MySum、Sum 工程可对照学习调用约定、指针类型映射、unsafe 代码及内存释放等关键环节。压缩包共 46 个文件涵盖 cs/cpp/h/dll/lib/exe/sln 等主要类型既有源码与工程文件也有编译生成的库与可执行文件便于直接运行调试。资源大小 4.87MB轻量易获取目前已有 8819 人学习下载适合希望快速掌握 C# 与 C 互操作、避免内存泄漏和平台不兼容踩坑的中高级 .NET 开发者。完整工程目录结构清晰配 ReadMe 说明与多种配置不仅可用于理解理论也可作为团队协作或二次开发的参考模板。1. C#调用C DLL指针参数是第一个拦路虎做跨语言调用时很多人第一次在 C# 里调用 C 的 DLL就被“函数参数包含指针”这几个字卡住了。明明 C 那边接口清清楚楚到了 C# 这边却不知道用int、ref int还是IntPtr去接更要命的是程序一运行就报内存访问冲突连崩溃在哪一行都看不出来。这篇文章要解决的就是这个问题帮你把 C DLL 里那些带指针的接口函数在 C# 里一个个安全、正确地调通。这里说的“指针参数”泛指四类常见场景基础类型指针如int*、结构体指针、字符串指针char*以及函数指针回调。它们对应的 C# 映射方案完全不同选错了轻则数据对不上重则直接进程崩溃。这篇笔记面向正在做跨平台系统集成或现有 C 模块移植的开发者用实际能跑的代码把每一种情况拆开讲最后再给几个我踩过的坑帮你绕开那些文档里根本不写的陷阱。2. 先把平台调用搭起来DllImport、调用约定与 32/64 位2.1 DllImport 最简骨架从 extern 到入口点C# 调用 C DLL 的核心机制是平台调用P/Invoke入口就是DllImport特性。你得先搞清楚三件事DLL 文件路径、函数入口点名字、参数怎么封送。最常见的写法是[DllImport(MyNativeLib.dll, CallingConvention CallingConvention.Cdecl, CharSet CharSet.Ansi)] private static extern int CalculateSum(int* numbers, int count);这里DllImport的第一个参数是 DLL 的名字运行时会在当前目录、系统目录和 PATH 环境变量里找。CallingConvention.Cdecl告诉 CLR 按 C 语言的调用约定来清理栈C 项目里如果没显式指定__stdcall默认就是 Cdecl两边必须对齐。CharSet影响字符串参数的编码方式C 那边是char*就用 Ansi是wchar_t*就用 Unicode。一个常见的坑是把函数名写错或忽略了大小写。C 编译出来的函数名在 DLL 里可能被修饰过了比如CalculateSum在 32 位下可能变成_CalculateSum8。你可以用EntryPoint字段精确指定[DllImport(MyNativeLib.dll, EntryPoint CalculateSum, CallingConvention CallingConvention.Cdecl)] private static extern int CalculateSum(int[] numbers, int count);EntryPoint可以同时解决两个问题一是避开 C 名字修饰的差异二是让 C# 端的函数名和 C 端不一样也能调。2.2 函数签名对齐的关键int* 对应的不是 int[]很多从 C# 入门的开发者第一反应是把int*映射成int[]这在部分场景下确实能跑但不是放之四海皆准。一维数组在封送时是以指针方式传递的所以下面两种写法效果很接近// 写法A用 int[] 接收 [DllImport(MyNativeLib.dll)] private static extern int SumArray(int[] data, int count); // 写法B用 IntPtr 显式指过去 [DllImport(MyNativeLib.dll)] private static extern int SumArray(IntPtr dataPtr, int count);两种写法的差别在语义上int[]让 CLR 帮你自动固定托管数组并取其首元素地址代码简洁IntPtr是完全手动控制适合指针可能指向非托管内存的场景。需要改值且改完要带回 C# 的用ref或out只读的用int[]或IntPtr都行。实际项目里我一般遵循这条选型线参数是标量指针就用ref T参数是数组且函数内只读就用T[]参数是数组且函数要改变元素个数或重新分配内存直接用IntPtr配合 Marshal 操作。这条线捋清楚后面所有接口都能套。2.3 平台位数与编译选项DLL 是 32 位还是 64 位指针参数最容易翻车的不是类型映射而是平台位数对不上。C# 进程是 64 位DLL 是 32 位加载时直接报BadImageFormatException。解决方案很简单把 C DLL 和 C# 程序编成同一个位数或者在 C# 里把平台目标改为 x86 来匹配 32 位 DLL。在 C 工程里你可以在项目属性中把“平台”设置为 x64 重新编译一份 64 位 DLL。如果拿到的 DLL 只有 32 位版本、一时没有源码C# 这边只能把“项目属性 → 生成 → 平台目标”改成 x86。注意这不是改一行配置那么简单你的 C# 程序里所有依赖的托管 DLL 也得都是 AnyCPU 或 x86否则会连锁报错。3. 指针参数的类型映射ref、out 与 IntPtr 到底怎么选3.1 能改值的标量参数用 ref 和 outC 里最常见的指针参数是输出参数函数通过解引用修改变量的值。比如void GetVersion(int* major, int* minor);C# 这边的标准映射就是ref[DllImport(MyNativeLib.dll, CallingConvention CallingConvention.Cdecl)] private static extern void GetVersion(ref int major, ref int minor); int major 0, minor 0; GetVersion(ref major, ref minor); Console.WriteLine($版本号{major}.{minor});用ref时CLR 会把托管变量的地址传给 CC 修改的就是 C# 变量本身。这在语义上和 C 的传地址完全一致。如果 C 函数不读入值、只写入也可以把ref改成out[DllImport(MyNativeLib.dll)] private static extern void GetVersion(out int major, out int minor); GetVersion(out int major, out int minor);out和ref在封送层面没有本质区别但out明确告诉 CLR 这个参数不需要初始化调用前不用赋值代码意图也更清晰。这里有个细节有些 C 接口函数会先读入参数值再决定行为比如int ResizeBuffer(int* capacity)内部先判断*capacity是否大于某个阈值。这种就必须用ref因为调用前参数里要有值。3.2 只读指针与未知结构IntPtr 是万能兜底当指针指向的是一个不透明结构或者 C 那边是一个void*ref和out都无能为力这时候IntPtr是唯一的选择。比如 C 有这样一个接口typedef struct _NativeContext NativeContext; int NativeProcess(NativeContext* ctx, const char* input);因为NativeContext是前向声明的C# 这边根本看不到它的内部布局也就没法定义对应的结构体。正确做法是让 C 提供一个NativeContext* CreateContext()返回的指针直接作为IntPtr存起来后续所有操作都把IntPtr原样传回去[DllImport(MyNativeLib.dll)] private static extern IntPtr CreateContext(); [DllImport(MyNativeLib.dll)] private static extern int NativeProcess(IntPtr ctx, string input); IntPtr ctx CreateContext(); int result NativeProcess(ctx, hello);IntPtr的本质是一个和 CPU 位宽一致的无符号整数32 位进程里是 4 字节64 位进程里是 8 字节。它本身不携带类型信息所以用起来自由度最大但也最容易滥用。原则是能用强类型ref、out、结构体表达清楚的地方尽量用强类型只有面对不透明句柄Handle或 C 里刻意隐藏的结构体时才退回IntPtr。3.3 需要分配内存的接口配合 Marshal.AllocHGlobal 使用有一类接口函数会自己分配内存并返回指针或者接受一个指针变量作为输出。比如 C 函数声明如下int GetData(int** outBuf, int* outLen);函数内部malloc一段缓冲把地址写入outBuf。此时 C# 端需要用IntPtr来接收这个地址[DllImport(MyNativeLib.dll)] private static extern int GetData(out IntPtr outBuf, out int outLen); IntPtr bufferPtr; int len; GetData(out bufferPtr, out len); byte[] result new byte[len]; Marshal.Copy(bufferPtr, result, 0, len);拿到指针之后必须注意释放内存的问题。如果 C 那边用malloc分配的就得让 C 提供对应的释放函数如果提供的是free(void*)的封装C# 这边可以这样调[DllImport(MyNativeLib.dll)] private static extern void FreeBuffer(IntPtr buf); FreeBuffer(bufferPtr);很多人在这里图省事用Marshal.FreeHGlobal去释放一旦 C 那边用的是new[]或malloc内存管理器不一致会直接崩溃。跨语言的内存分配和释放必须在同一边这是铁律。4. 结构体指针与字符串指针两类高频传址的完整解法4.1 结构体按引用传址LayoutKind.Sequential 与 ref 组合结构体指针是除基础类型之外最高频的传址场景。比如 C 有一个配置结构体和对应接口typedef struct { int width; int height; int channels; } ImageConfig; int ApplyConfig(ImageConfig* cfg);C# 这边要先定义结构体再指定内存布局[StructLayout(LayoutKind.Sequential)] public struct ImageConfig { public int width; public int height; public int channels; } [DllImport(MyNativeLib.dll)] private static extern int ApplyConfig(ref ImageConfig cfg); ImageConfig cfg new ImageConfig { width 1920, height 1080, channels 3 }; ApplyConfig(ref cfg);LayoutKind.Sequential让 CLR 按字段声明顺序、以默认对齐规则排列结构体内存和 C 侧struct的内存布局一致。如果不写这个特性托管结构体的布局是由 CLR 决定的内存顺序通常和声明不一致C 读到的字段就全乱了。这里最隐蔽的坑是字段类型的对齐差异。C# 的bool占用 1 字节C 的bool也占 1 字节但如果你 C 侧用的是int而 C# 侧用了bool字段类型错位会导致整个结构体后面的成员全部偏移。从 C 侧抄结构体定义时字段类型要原样对照不要自行“优化”。4.2 结构体数组指针IntPtr Marshal.PtrToStructure 逐个取当 C 接口要返回一个结构体数组时情况比单结构体传址复杂一些。假设接口如下int GetResults(ResultStruct* outResults, int count); typedef struct { int id; float score; } ResultStruct;C 那边要求 C# 分配足够的内存来承接结果C# 侧有两种做法。第一种是托管数组直接传[StructLayout(LayoutKind.Sequential)] public struct ResultStruct { public int id; public float score; } [DllImport(MyNativeLib.dll)] private static extern int GetResults(ResultStruct[] results, int count); ResultStruct[] results new ResultStruct[10]; GetResults(results, results.Length);这种写法依赖 CLR 自动固定数组并传递首地址C 写入的实际就是托管数组的内层内存函数返回后 C# 数组已经更新。第二种更灵活的做法是用IntPtr分配非托管内存再逐一取回IntPtr buffer Marshal.AllocHGlobal(Marshal.SizeOfResultStruct() * 10); GetResults(buffer, 10); ResultStruct[] results new ResultStruct[10]; for (int i 0; i 10; i) { IntPtr itemPtr IntPtr.Add(buffer, i * Marshal.SizeOfResultStruct()); results[i] Marshal.PtrToStructureResultStruct(itemPtr); } Marshal.FreeHGlobal(buffer);两种写法的取舍看场景C 函数如果只要求一块连续内存托管数组足够如果函数要重新分配内存或改变数组长度就必须走IntPtr路线。用IntPtr.Add而不是buffer i * size是避免算错字节偏移的安全做法64 位下指针偏移按字节算很容易漏掉sizeof。4.3 字符串指针StringBuilder 与强制编码C 的char*参数在 C# 里最常见的映射是string或StringBuilder。区别在于string是不可变的适合只读传参StringBuilder是可变的适合 C 往里写字符串。比如void GetUserName(char* buffer, int bufferSize);C# 调用[DllImport(MyNativeLib.dll, CharSet CharSet.Ansi)] private static extern void GetUserName(StringBuilder buffer, int bufferSize); StringBuilder sb new StringBuilder(256); GetUserName(sb, sb.Capacity); string name sb.ToString();这里的CharSet.Ansi决定了字符串按 ANSI 编码封送StringBuilder被预分配 256 字符的缓冲C 往里写时不会越界。如果 C 用的是wchar_t*CharSet要改成Unicode同时StringBuilder的容量要覆盖 Unicode 字符数的两倍字节数。很多老接口直接返回const char*比如const char* GetVersion()这种返回值映射成string是安全的CLR 会把非托管字符串复制一份到托管堆C 那边释放内存不影响 C# 端。但如果返回的是char*且指向内部缓冲区后续对该缓冲区的任何修改都会反映到 C# 字符串上——这时最好立刻ToString()复制一份出来。5. 避坑手册指针参数翻车的五种典型现场5.1 内存对齐与结构体布局不符数据错位但程序不崩现象结构体传进去后C 读到的width是 0height是 1920字段整体错位。程序能运行只是输出全是乱值。原因C# 结构体没加[StructLayout(LayoutKind.Sequential)]或者加了但字段顺序与 C 不一致。CLR 默认的布局策略会重排字段以优化内存占用造成两边内存结构不匹配。解决给结构体显式声明[StructLayout(LayoutKind.Sequential)]并逐字段核对 C 头文件里的声明。如果 C 结构体用了#pragma pack(push, 1)调整对齐C# 侧还要写Pack 1[StructLayout(LayoutKind.Sequential, Pack 1)]5.2 32/64 位不匹配导致加载即崩现象DllNotFoundException或BadImageFormatException程序启动即异常。原因C DLL 是 32 位的而 C# 进程跑在 64 位上或者反过来。解决在 C 工程里针对 C# 进程位数重新编一份 DLL保持两边一致。如果拿不到 64 位 DLLC# 项目平台目标改为 x86。在解决方案里可以加个生成后事件把对应位数的 DLL 复制到输出目录避免“能编译但找不到 DLL”的尴尬。5.3 用错内存释放函数导致堆损坏现象调用释放函数时程序崩溃或者过了很久才在随机位置崩溃一次错误信息毫无规律。原因C 用malloc分配的内存被 C# 用Marshal.FreeHGlobal释放两边堆管理器不是同一个。Windows 上 CRT 不同版本之间也可能有隔离。解决谁分配、谁释放。C 接口里实现一个对应的释放函数C# 只调用它。如果第三方 DLL 没提供释放函数优先考虑不持有它分配的内存在 C# 侧自行分配缓冲传进去。5.4 缓冲区大小预判不足导致内存越界现象调用函数后 C# 侧抛出AccessViolationException或者周围变量的值无故变化。原因C 函数按约定向char*或byte*写数据但 C# 传入的缓冲区容量不够C 写越界了。越界写入不一定会立刻崩溃破坏的可能是托管堆上的其他对象。解决预估最坏情况下的缓冲大小通常通过函数名中带Size的参数获取或直接传一个足够大的值。拿不准时用StringBuilder的容量字段和Capacity反复核对C 侧每写一个字符都要检查当前偏移是否到达末尾。5.5 回调函数指针委托被 GC 回收导致调用无效现象回调在前几次调用正常运行一段时间后 C 侧回调报错或程序闪退。原因C 端保存了 C# 委托的函数指针但 C# 侧的委托对象没有引用被垃圾回收回收掉了C 再调用时就访问了已释放的内存。解决在 C# 侧用一个静态字段或长期存活的对象持有委托private static CallbackDelegate _callback; [DllImport(MyNativeLib.dll)] private static extern void RegisterCallback(CallbackDelegate callback); _callback new CallbackDelegate(OnNativeCallback); RegisterCallback(_callback);只要_callback还存活C 持有的函数指针就有效。这在长时间运行的程序里属于必备操作。6. 指向任意内存的 Copymem用 IntPtr 做内存块搬运的通用速写最后落一个非常实用的技巧当你手头有一个IntPtr指向非托管内存又希望把它转成byte[]做后续处理时可以直接用Marshal.Copy走一个万用通道这也是调试任何指针参数时最常用的验证手段。static byte[] ReadMemory(IntPtr ptr, int length) { if (ptr IntPtr.Zero) throw new ArgumentException(指针不能为空); byte[] data new byte[length]; Marshal.Copy(ptr, data, 0, length); return data; } static void WriteMemory(IntPtr ptr, byte[] data) { if (ptr IntPtr.Zero) throw new ArgumentException(指针不能为空); Marshal.Copy(data, 0, ptr, data.Length); }这段代码的思路很直接不关心指针到底指向什么结构先按字节原样搬到托管数组里再用BitConverter或自定义解析去按偏移读字段。调接口时先用这个函数把指针指向的内存快照出来int就取第 0 到 3 字节float就取第 4 到 7 字节C 结构体布局一目了然比自己猜强得多。验证一个带指针参数的接口是否调用正确我现在的习惯是三步走第一步用上面ReadMemory把 C 写回的内存快照打出来核对每个字段偏移上的值第二步主动把一个IntPtr指向已知数据的托管数组用WriteMemory写进去再传给 C看 C 能不能读到预期输入第三步才放开手脚接真实数据。这三步走完接口到底有没有接对基本没有玄学空间。从那以后我每次接新的 C DLL都会强制先写一遍ReadMemory和WriteMemory这对工具函数再开始定义结构体和DllImport。无论是结构体对齐问题还是缓冲区越界在这两招面前都无处遁形。希望这套经验帮到你少走几步冤枉路。本文还有配套的精品资源点击获取