.NET互操作：是否只能依赖AllocHGlobal？

我继承了一段旧的Interop代码，原代码使用StringBuilder进行字符串输出，希望按照新的互操作指导方针更新，但无法获取原生方法的源代码。

原代码实现：

[DllImport(NativeLib, CharSet = CharSet.Ansi, ExactSpelling = true)]
static extern int native_func(double input, StringBuilder result);

public string Convert(double input)
{
   var res = new StringBuilder();
   if (native_func(input, res) == 0)
      return res.ToString();
   throw ...;
}

我尝试用AllocHGlobal替代StringBuilder，修改后代码：

[DllImport(NativeLib, CharSet = CharSet.Ansi, ExactSpelling = true)]
static extern int native_func(double input, IntPtr result);

public string Convert(double input)
{
   var res = Marshal.AllocHGlobal(100);
   // 假设后续会调用Marshal.FreeHGlobal...
   if (native_func(input, res) == 0)
      return Marshal.PtrToStringAnsi(res);
   throw ...;
}

但这并没有用到Span/Ref等新特性。无论怎么设置result参数，要么只能获取到第一个字符，要么触发System.AccessViolationException。试过MemoryMarshal.GetReference、固定内存、ref/out关键字等方式使用托管缓冲区，都没有效果。想知道：

1. 是否存在新互操作特性不适用的场景？
2. AllocHGlobal是否为当前最优选择？

新互操作特性的适用限制 #

是的，Span/Ref这类新互操作特性确实存在不适用场景，尤其是在无法明确原生函数内存写入逻辑的情况下：

• 若原生函数默认要求传入的是非托管堆内存指针（比如内部依赖非托管内存的生命周期、或者假设指针指向的是堆内存而非栈上固定的托管内存），那么用Span固定的托管内存就会触发访问违规——固定的托管内存本质还是托管堆的一部分，和原生函数的内存模型假设不匹配。
• 另外，原StringBuilder会自动处理缓冲区扩容，而如果原生函数需要预先知道缓冲区大小，你没通过额外参数告知它缓冲区长度，就会出现只写入第一个字符的情况。

AllocHGlobal的合理性 #

在无法获取原生源代码的前提下，AllocHGlobal是当前最稳妥的选择，原因如下：

• 它分配的是标准非托管堆内存，和原StringBuilder在互操作时底层的内存模型完全一致（StringBuilder会被Marshal自动转换为非托管内存指针传入原生函数），原生函数的写入逻辑可以完全兼容。
• 使用时需要注意两点：
  • 尽量不要硬编码缓冲区大小（比如你写的100），如果原生函数支持第一次调用传IntPtr.Zero来获取所需缓冲区长度，一定要利用这个机制动态分配足够的内存，避免溢出。
  • 必须在使用完后用Marshal.FreeHGlobal释放内存，建议用try/finally或者自定义包裹类确保内存不会泄漏。

关于新特性的尝试建议 #

如果一定要尝试Span等新特性，你需要满足两个前提：

• 用fixed关键字固定托管数组或Span的内存，获取指针传入原生函数；
• 必须额外传入缓冲区的长度参数（如果原生函数支持的话），让它知道可以写入的最大范围。
  但因为你不清楚原生函数的具体实现，这种尝试风险极高，远不如AllocHGlobal可靠。

内容的提问来源于stack exchange，提问作者Greg Sandstrom