Marshal.AllocHGlobal分配的内存必须配对调用Marshal.FreeHGlobal释放，不可与AllocCoTaskMem/FreeCoTaskMem混用，写入前需确保大小、对齐及指针算术正确。
Marshal.AllocHGlobal 申请的内存必须配对调用 Marshal.FreeHGlobal
手动分配非托管内存最常用的是 Marshal.AllocHGlobal，它等价于 Win32 的 GlobalAlloc(GMEM_FIXED)，返回一个 IntPtr。但它的内存**不会自动释放**，哪怕对象被 GC 回收，也照样泄漏。
常见错误是只分配不释放，或在非托管资源清理逻辑中遗漏 FreeHGlobal 调用：
- 在
IDisposable.Dispose()中忘记调用Marshal.FreeHGlobal(ptr) - 分配后发生异常，跳过释放路径（需用
try/finally或using+ 自定义包装） - 把同一块指针重复释放，触发 Access Violation 或堆损坏
正确做法是：分配和释放严格成对，且确保只释放一次。例如：
IntPtr ptr = IntPtr.Zero;
try
{
ptr = Marshal.AllocHGlobal(1024);
// 使用 ptr...
}
finally
{
if (ptr != IntPtr.Zero)
Marshal.FreeHGlobal(ptr);
}Marshal.AllocHGlobal 和 Marshal.AllocCoTaskMem 的区别在哪
两者都分配非托管内存，但语义和底层 API 不同，混用会导致未定义行为：
-
Marshal.AllocHGlobal→ 底层调用GlobalAlloc，对应Marshal.FreeHGlobal -
Marshal.AllocCoTaskMem→ 底层调用CoTaskMemAlloc，必须用Marshal.FreeCoTaskMem释放
关键区别在于 COM 互操作场景：AllocCoTaskMem 是 COM 接口（如 IDispatch）期望的内存分配方式；而 AllocHGlobal 更通用，适合与 Win32 API（如 ReadProcessMemory、SendMessage）交互。
不能交叉释放——比如用 AllocHGlobal 分配却调用 FreeCoTaskMem，程序可能立即崩溃或静默损坏堆。
写入 Marshal.AllocHGlobal 分配的内存前要确认大小和对齐
Marshal.AllocHGlobal 返回的是一块裸字节区域，没有类型信息，写入时极易越界或错位。尤其要注意：
- 分配大小按字节计算，不是元素个数。例如存 100 个
int，得传100 * sizeof(int)，而非100 - 结构体写入前建议用
Marshal.SizeOf<t>()</t>而非sizeof(T)，因为后者不处理显式布局（[StructLayout]）和打包（Pack） - 指针算术需手动换算：若想写第
i个int，地址是IntPtr.Add(ptr, i * 4)，不能直接ptr + i（C# 不允许IntPtr原生加法）
示例：安全写入结构体数组
int size = Marshal.SizeOf<MyStruct>();
IntPtr ptr = Marshal.AllocHGlobal(size * count);
for (int i = 0; i < count; i++)
{
IntPtr itemPtr = IntPtr.Add(ptr, i * size);
Marshal.StructureToPtr(myStructs[i], itemPtr, false);
}Marshal 类不管理生命周期，别指望它和 GC 协作
Marshal 系列方法纯粹是“调用 Win32 内存 API 的薄封装”，它不注册任何终结器、不参与 GC 根追踪、也不提供安全句柄（SafeHandle）那样的自动保护机制。
这意味着：
- 无法靠
GC.Collect()触发释放 - 没有类似
SafeBuffer的引用计数或双重释放防护 - 跨线程传递
IntPtr时，必须自行保证目标线程释放，且原线程不再访问该地址
真正健壮的做法是封装成 SafeHandle 子类（重写 ReleaseHandle），或者用 NativeMemory（.NET 5+）替代——后者提供 Alloc/Free + Zero + 异常安全的 using 支持，更现代也更难出错。
手动内存管理里最容易被忽略的，不是怎么分配，而是谁负责释放、何时释放、以及释放后是否还有其他代码在读那块地址——这三个问题没闭环，Marshal 就只是个危险的工具。
