CComBSTR内部存储UTF-16，char[]需显式编码转换：UTF-8用MultiByteToWideChar(CP_UTF8)转，ANSI用CP_ACP（不推荐）；直接赋值会将每个char误作wchar_t低字节导致乱码。
字符数组转CComBSTR：必须先转成宽字符
CComBSTR内部存储的是UTF-16（即wchar_t序列），直接用多字节字符数组（如char[]）构造会触发隐式转换，但默认按系统本地代码页（如GBK）解释——在非中文环境或含Unicode字符时必然出错。
正确做法是显式做编码转换：
- 若源数组是UTF-8：
MultiByteToWideChar(CP_UTF8, 0, src, -1, nullptr, 0)先查长度，再分配缓冲区，最后转换 - 若源数组是ANSI（系统默认编码）：
MultiByteToWideChar(CP_ACP, 0, src, -1, ...)，但不推荐依赖此方式，跨机器易失效 - 已有
wchar_t[]？直接传给CComBSTR构造函数：CComBSTR bstr(wide_array)
示例（UTF-8转）：
char utf8_str[] = u8"你好，世界"; int len = MultiByteToWideChar(CP_UTF8, 0, utf8_str, -1, nullptr, 0); wchar_t* wbuf = new wchar_t[len]; MultiByteToWideChar(CP_UTF8, 0, utf8_str, -1, wbuf, len); CComBSTR bstr(wbuf); delete[] wbuf;
字符数组转CString：看编译选项和构造方式
CString的行为完全取决于项目是否定义了_UNICODE（或UNICODE）：
立即学习“C++免费学习笔记（深入）”；
- 未定义时：
CString底层是char*，可直接用char[]构造：CString str("hello") - 定义了
_UNICODE时：CString等价于CStringW，只接受wchar_t*；此时传char[]会编译失败 - 想写一次代码兼容两者？用
TEXT()宏或_T()宏包装字面量，但对运行时变量无效
运行时char[]转CString（Unicode模式下）必须先转宽字符，方法同上——MultiByteToWideChar + 构造CStringW，或直接用CStringA临时转换再调用CA2W辅助类：
char ansi_str[] = "test"; CStringW str(CA2W(ansi_str)); // 自动按CP_ACP转，慎用于UTF-8数据
为什么不能用std::string.data()直接赋值给CComBSTR？
CComBSTR的operator=重载对const char*有隐式转换，但它的实现是调用SysAllocStringByteLen，该函数把每个char当做一个wchar_t的低字节复制过去——相当于把"ab"变成L"\x61\x00\x62\x00"，结果是乱码且内存布局错误。
- 这种赋值仅在源数据本身就是UTF-16 LE编码的
char[]（即每两个char构成一个wchar_t）时才“碰巧”有效 - 绝大多数情况下，这是隐蔽的bug来源，尤其在处理中文、emoji或跨平台数据时
- 编译器不会报错，但运行时字符串显示异常或COM接口调用失败
性能与生命周期要注意的坑
CComBSTR和CString都管理自己的内存，但转换过程容易引发重复拷贝或悬空指针：
-
CComBSTR构造时会深拷贝传入的wchar_t*，原缓冲区可安全释放；但若传入栈上wchar_t[256]后立即离开作用域，CComBSTR内部已拷贝，无风险 -
CString在Unicode模式下用CA2W时，默认使用栈缓冲区，超出长度才堆分配——但若原char*很长，频繁调用可能触发堆分配，影响性能 - 避免在循环里反复做
char[] → CComBSTR转换；提前转好复用，或改用std::wstring中间缓存
最易被忽略的是编码源头：确认你的char[]到底是什么编码。Windows API返回的多字节字符串几乎都是CP_ACP，而网络/文件读取的很可能是UTF-8——混用CP_ACP和CP_UTF8参数会导致一半字符正常、一半变问号。
