C++原生wchar_t*经C++/CLI封装传递到C#的实现方法咨询

这里提供两种行业通用的标准实现方案，分别对应你最初查阅微软文档提到的StringBuilder封送方式，以及你后来摸索的返回String的优化方式：

方案1：使用StringBuilder封送（符合微软官方互操作规范） #

实现逻辑 #

StringBuilder在跨语言互操作场景下，默认会被封送为可修改的wchar_t*缓冲区，你只需要在C++/CLI中锁定StringBuilder的底层缓冲区传给原生函数，调用完成后运行时会自动同步缓冲区内容到StringBuilder实例，无需手动赋值。

C++/CLI 代码实现 #

#include "MyCppLib.h"
using namespace System;
using namespace System::Text;
using namespace System::Runtime::InteropServices;

namespace MyCppCliLib
{
    int CppCliFunc(int Index, StringBuilder^ sB, int StringLength) {
        // 提前校验容量，避免缓冲区溢出
        if (sB == nullptr)
            throw gcnew ArgumentNullException(nameof(sB));
        if (sB->Capacity < StringLength)
            sB->Capacity = StringLength;
        
        // 锁定StringBuilder底层字符缓冲区，获取原生wchar_t*指针
        pin_ptr<wchar_t> pBuffer = &sB->GetChunks()[0].m_Chars[0];
        return ::CppFunc(Index, pBuffer, StringLength);
    }
}

C# 侧调用代码 #

// 初始化时直接指定容量，减少C++/CLI侧扩容开销
StringBuilder sB = new StringBuilder(4096);
int x = CppCliFunc(2, sB, sB.Capacity);
// 直接调用ToString即可获取原生函数返回的字符串
string result = sB.ToString();

注意：不要在C#侧给StringBuilder预先赋值内容，原生函数会直接覆盖缓冲区内容，传入空的、指定好容量的StringBuilder即可。

方案2：直接返回String类型（更符合C#调用习惯的优化实现） #

你自己摸索的版本思路是正确的，只需要修正几个风险点即可：

• 用智能指针管理原生内存，避免手动free遗漏导致内存泄漏
• 构造托管String时显式指定长度，避免原生字符串未加\0结尾导致的读取越界

优化后的标准实现 #

#include "MyCppLib.h"
#include <memory>
using namespace System;

namespace MyCppCliLib
{
    String^ CppCliFunc(int Index, int StringLength) {
        if (StringLength <= 0)
            throw gcnew ArgumentOutOfRangeException(nameof(StringLength), "字符串长度必须大于0");
        
        // 用unique_ptr自动管理原生内存，不需要手动调用free
        auto wBuffer = std::make_unique<wchar_t[]>(StringLength);
        int errorCode = ::CppFunc(Index, wBuffer.get(), StringLength);
        
        if (errorCode != 0)
            throw gcnew Exception("调用原生函数失败，错误码：" + errorCode.ToString());
        
        // 显式指定字符串长度，避免无\0结尾导致的越界问题
        return gcnew String(wBuffer.get(), 0, StringLength);
    }
}

C# 侧调用代码 #

string result = CppCliFunc(2, 4096);

方案选型建议 #

• 如果需要兼容现有使用StringBuilder的互操作代码，选择方案1
• 如果是新开发的封装接口，优先选择方案2，调用逻辑更简单，出错概率更低

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