1. 为什么Qt要和C# DLL打交道：一个被低估的跨语言协作现实
在Qt开发一线干了十多年，我见过太多团队在“纯C++生态”里死磕到底——结果是花了三周重写一个Excel模板引擎，而隔壁组用C#的EPPlus库两小时就跑通了；也见过更典型的场景：客户现场已经部署了整套基于.NET Framework的设备控制中间件，接口文档厚达87页，但要求新上马的HMI界面必须用Qt开发。这时候，“能不能调用C#写的DLL”就不是技术选型问题，而是项目能不能按期交付的生死线。
很多人第一反应是摇头：“Qt是C++的，C#是.NET的，运行时都不在一个世界里，怎么可能？”这说法没错，但错在把“不可能”当成了“不值得深挖”。真实情况是：Qt程序调用C#编写的DLL不仅可行，而且在工业控制、医疗设备、金融终端等对既有.NET资产高度依赖的领域，已是成熟落地的方案。关键不在于“能不能”，而在于“走哪条路、绕哪些坑、怎么稳住”。
核心关键词就三个：Qt、C#、DLL。这里必须立刻划清边界——我们说的“C# DLL”特指编译为.NET Framework（非.NET Core/.NET 5+）的托管DLL，且目标平台为Windows（因涉及COM互操作与CLR加载机制）。它不是.NET Standard类库，也不是纯C++/CLI混编产物，而是标准的、Visual Studio默认生成的.csproj输出的.dll文件。这类DLL内部全是IL字节码，依赖CLR运行，不能像传统Win32 DLL那样被LoadLibrary直接映射进进程空间。
所以，Qt调用它的本质，不是“链接符号”，而是“启动.NET运行时，加载并桥接托管对象”。这就引出了两条技术路径：一是通过COM Interop将C#类暴露为COM组件，让Qt用QAxObject调用；二是通过C++/CLI桥接层，写一个中间DLL，一边用托管代码加载C# DLL，一边用原生C++导出函数供Qt调用。前者轻量但受限于COM注册与线程模型；后者灵活稳定但多一道编译环节。本文聚焦后者——因为它能覆盖95%的真实生产场景，且规避了COM注册失败、DCOM权限、STA线程阻塞等让人半夜爬起来重启服务的玄学问题。
适合谁看？如果你正面临这些情况中的任意一条：
- 已有成熟C#业务逻辑（如算法库、协议解析器、数据库访问层），但新UI必须用Qt实现；
- 客户强制要求使用其提供的.NET SDK，而你手头只有Qt开发资质；
- 团队里C#开发者多、Qt开发者少，想复用现有代码资产而非重写；
- 需要调用WPF控件或依赖Windows Forms的旧模块（它们只能在.NET Framework下运行）。
那么，这不是一篇“理论可行”的科普文，而是一份我亲手在三个不同产线项目中验证过的、可直接抄作业的实战指南。接下来，我会从底层原理讲起，拆解每一步为什么这么设计，再带你一行行写出可编译、可调试、可上线的完整链路。
2. 底层原理：为什么C++/CLI是Qt与C#之间的唯一可靠桥梁
要真正吃透Qt调用C# DLL这件事，必须先扔掉“DLL就是一段二进制代码”的直觉。Windows下的DLL分三类：Win32 Native DLL（纯机器码）、.NET Managed DLL（IL字节码+元数据）、以及C++/CLI Mixed Mode DLL（Native代码+托管代码混合体）。Qt的QLibrary只能加载第一类；而C#编译出的DLL天生是第二类——它没有导出函数表，没有可被GetProcAddress解析的符号，甚至没有固定的内存布局。试图用QLibrary::resolve("MyFunc")去抓取C#方法，得到的永远是nullptr。
那为什么C++/CLI能破局？答案藏在它的编译产物里。C++/CLI项目（.vcxproj中配置<CLRSupport>true</CLRSupport>）编译后生成的DLL，表面看是Win32 DLL，实则内部嵌入了完整的.NET元数据。它既能被操作系统当作原生模块加载（有PE头、有导出表），又能在运行时触发CLR初始化，并在自己的地址空间内加载托管DLL。更关键的是，C++/CLI允许你在同一源文件里无缝混写托管代码（ref class）和原生代码（class），并通过pin_ptr、marshal_as等机制在托管堆与原生堆之间安全传递数据——这正是Qt（纯原生）和C#（纯托管）之间缺失的“翻译官”。
举个最简例子：假设C# DLL里有个Calculator类，提供Add(int a, int b)方法。在C++/CLI桥接层中，你可以这样写：
// Bridge.h (原生C++头文件，Qt可直接包含) #pragma once extern "C" { __declspec(dllexport) int AddFromCSharp(int a, int b); }// Bridge.cpp (C++/CLI源文件) #include "Bridge.h" using namespace System; // 托管引用 #using "MyCSharpLib.dll" // 原生导出函数 extern "C" __declspec(dllexport) int AddFromCSharp(int a, int b) { // 在托管上下文中创建实例 MyCSharpLib::Calculator^ calc = gcnew MyCSharpLib::Calculator(); // 调用托管方法，自动转换int类型 return (int)calc->Add(a, b); }编译后，这个Bridge.dll就拥有了Win32 DLL的“外壳”（导出函数AddFromCSharp）和.NET DLL的“内核”（加载并执行MyCSharpLib.dll）。Qt只需用QLibrary加载Bridge.dll，resolve出AddFromCSharp函数指针，就能像调用普通C函数一样调用它——整个过程对Qt完全透明，不需要任何.NET知识。
提示：C++/CLI桥接层必须针对.NET Framework x86或x64单独编译，且目标平台需与Qt构建环境严格一致。曾有个项目因Qt用MinGW x64而桥接层用MSVC x86，导致QLibrary加载失败却只报“文件未找到”，排查三天才发现是平台位数不匹配。务必在项目初期就统一构建链路。
为什么不用COM Interop？它确实能绕过C++/CLI，但代价极高：C# DLL必须显式标记[ComVisible(true)]，每个类加[ClassInterface(ClassInterfaceType.AutoDual)]，还要用regasm /tlb注册类型库；Qt端需引入QAxContainer模块，用QAxObject包装，而QAxObject在多线程环境下极易引发STA线程争用，导致UI卡死；更致命的是，COM对泛型、委托、事件等高级特性支持极差，一旦C#侧用了List<T>或Action<T>，Qt端拿到的就是空壳对象。我在某医疗影像系统中试过COM方案，最终因无法传递DICOM图像数据流（byte[]太大，COM序列化超时）而放弃。
C++/CLI的另一个隐形优势是错误隔离。当C# DLL抛出未处理异常时，C++/CLI层可用try/catch(...)捕获，并转换为返回码或错误字符串传给Qt；而COM方式下，托管异常会直接穿透到Qt的事件循环，导致整个应用崩溃。这种稳定性，在24小时不间断运行的工控场景里，是不可妥协的底线。
3. 实战步骤：从零搭建Qt-C#调用链的七步闭环
现在进入最硬核的部分——手把手搭建一条从Qt调用C# DLL的完整链路。我以一个真实案例为蓝本：客户提供了DeviceControl.dll（C#编写），含DeviceManager类，提供Connect(string ip, int port)和ReadSensorData()方法，返回SensorData结构体（含温度、湿度、时间戳）。Qt端需在按钮点击时连接设备并显示数据。整个流程共七步，每一步都附带我踩过的坑和验证技巧。
3.1 步骤一：确认C# DLL的.NET Framework版本与平台目标
这是最容易被跳过的致命步骤。打开Visual Studio Developer Command Prompt，运行：
ildasm "DeviceControl.dll" /text | findstr "Runtime"若输出含.NETFramework,Version=v4.7.2，则确认为.NET Framework；若为.NETCoreApp,Version=v6.0，此方案不适用（需改用.NET Core Hosting API，另文详述）。同时检查平台：
corflags "DeviceControl.dll" | findstr "32BIT"若显示32BITREQ : 1，则必须用x86 Qt构建；若为32BITREQ : 0且PE : PE32+，则需x64 Qt。我曾因客户给的DLL是x86而自己用Qt x64构建，QLibrary::load始终返回false，日志里连错误码都不报——后来用Process Monitor抓取文件加载过程，才看到系统在找DeviceControl.dll时实际尝试了C:\Windows\SysWOW64\DeviceControl.dll（x86路径），而文件在C:\MyApp\目录下，路径根本不对。
3.2 步骤二：创建C++/CLI桥接项目（VS 2019+）
新建“动态链接库(DLL)”项目，项目属性关键设置：
- 常规 → 项目默认值 → 配置类型：动态库(.dll)
- 常规 → Windows SDK版本：与Qt SDK一致（如10.0.19041.0）
- 常规 → 平台工具集：v142（对应VS 2019）
- 常规 → 目标平台：x64 或 x86（必须与Qt一致）
- 配置属性 → 常规 → 公共语言运行时支持：
/clr（这是C++/CLI的开关） - 配置属性 → 链接器 → 高级 → 导入库：取消勾选（避免生成.lib，Qt用QLibrary不依赖.lib）
在源文件中添加Bridge.h（纯原生声明）和Bridge.cpp（托管实现）。注意：Bridge.h中所有函数声明必须用extern "C"和__declspec(dllexport)，否则Qt无法解析符号。C++/CLI项目默认生成DllMain，但绝不要在里面初始化CLR——CLR会在首次调用托管代码时自动加载，手动初始化反而导致冲突。
3.3 步骤三：在Bridge.cpp中安全加载C# DLL并封装函数
这是核心逻辑。完整代码如下（已脱敏）：
// Bridge.cpp #include "Bridge.h" #include <string> #include <vector> #include <windows.h> // 必须用#using而非#include，且路径为绝对路径或相对$(SolutionDir) #using "DeviceControl.dll" as_friend // 托管命名空间别名，避免长名称 using DeviceNS = DeviceControl; // 全局托管对象指针（单例模式，避免重复创建） static DeviceNS::DeviceManager^ g_deviceManager = nullptr; // 原生导出函数：连接设备 extern "C" __declspec(dllexport) int ConnectToDevice(const char* ip, int port) { try { // 将char*转为托管String System::String^ managedIp = gcnew System::String(ip); // 创建或复用DeviceManager实例 if (g_deviceManager == nullptr) { g_deviceManager = gcnew DeviceNS::DeviceManager(); } // 调用托管方法 bool result = g_deviceManager->Connect(managedIp, port); return result ? 0 : -1; // 0成功，-1失败 } catch (System::Exception^ ex) { // 捕获所有托管异常，转换为错误码 OutputDebugString(L"Bridge: Connect exception "); OutputDebugString(ex->Message); return -2; } } // 原生导出函数：读取传感器数据 extern "C" __declspec(dllexport) int ReadSensorData(float* temp, float* humidity, long long* timestamp) { try { if (g_deviceManager == nullptr) return -1; // 调用托管方法获取数据对象 DeviceNS::SensorData^ data = g_deviceManager->ReadSensorData(); if (data == nullptr) return -3; // 安全复制到原生内存（使用pin_ptr固定托管数组） *temp = (float)data->Temperature; *humidity = (float)data->Humidity; *timestamp = (long long)data->Timestamp; return 0; } catch (...) { return -4; } }注意：
#using指令的路径必须正确。我习惯把C# DLL放在桥接项目根目录，然后在#using "DeviceControl.dll"中写相对路径。若DLL在子目录，需写#using "..\\..\\libs\\DeviceControl.dll"。VS不会自动拷贝DLL到输出目录，必须在项目属性→生成事件→后期生成事件中添加：copy "$(ProjectDir)DeviceControl.dll" "$(OutDir)"。
3.4 步骤四：Qt端编写安全调用封装类
在Qt项目中，创建CSharpBridge.h/cpp，用QLibrary封装调用逻辑。关键点：必须检查函数指针有效性，且每次调用前验证DLL是否已加载。
// CSharpBridge.h #ifndef CSHARPBIDGE_H #define CSHARPBIDGE_H #include <QLibrary> #include <QString> #include <QDebug> struct SensorData { float temperature; float humidity; qint64 timestamp; }; class CSharpBridge { public: static bool loadLibrary(const QString& path); static bool connectToDevice(const QString& ip, int port); static bool readSensorData(SensorData& data); static void unloadLibrary(); private: static QLibrary m_library; typedef int (*ConnectFunc)(const char*, int); typedef int (*ReadFunc)(float*, float*, long long*); static ConnectFunc m_connectFunc; static ReadFunc m_readFunc; }; #endif // CSHARPBIDGE_H// CSharpBridge.cpp #include "CSharpBridge.h" #include <QFileInfo> QLibrary CSharpBridge::m_library; CSharpBridge::ConnectFunc CSharpBridge::m_connectFunc = nullptr; CSharpBridge::ReadFunc CSharpBridge::m_readFunc = nullptr; bool CSharpBridge::loadLibrary(const QString& path) { if (m_library.isLoaded()) return true; QFileInfo fi(path); if (!fi.exists()) { qWarning() << "Bridge DLL not found:" << path; return false; } m_library.setFileName(path); if (!m_library.load()) { qWarning() << "Failed to load bridge DLL:" << m_library.errorString(); return false; } // 解析函数指针（注意：函数名必须与Bridge.cpp中声明完全一致） m_connectFunc = (ConnectFunc)m_library.resolve("ConnectToDevice"); m_readFunc = (ReadFunc)m_library.resolve("ReadSensorData"); if (!m_connectFunc || !m_readFunc) { qWarning() << "Failed to resolve functions in bridge DLL"; m_library.unload(); return false; } return true; } bool CSharpBridge::connectToDevice(const QString& ip, int port) { if (!m_connectFunc) return false; QByteArray ipBytes = ip.toLocal8Bit(); return m_connectFunc(ipBytes.constData(), port) == 0; } bool CSharpBridge::readSensorData(SensorData& data) { if (!m_readFunc) return false; float temp = 0.0f, hum = 0.0f; long long ts = 0; int ret = m_readFunc(&temp, &hum, &ts); if (ret == 0) { data.temperature = temp; data.humidity = hum; data.timestamp = ts; return true; } return false; } void CSharpBridge::unloadLibrary() { if (m_library.isLoaded()) { m_library.unload(); } }3.5 步骤五：在Qt UI中集成调用（以QPushButton为例）
在主窗口构造函数中加载DLL：
// MainWindow.cpp MainWindow::MainWindow(QWidget *parent) : QMainWindow(parent), ui(new Ui::MainWindow) { ui->setupUi(this); // 加载桥接DLL（路径需根据实际调整） QString bridgePath = QApplication::applicationDirPath() + "/Bridge.dll"; if (!CSharpBridge::loadLibrary(bridgePath)) { QMessageBox::critical(this, "Error", "Failed to load C# bridge DLL!"); return; } }按钮点击槽函数：
void MainWindow::on_connectButton_clicked() { if (CSharpBridge::connectToDevice("192.168.1.100", 8080)) { ui->statusLabel->setText("Connected"); // 启动定时器读取数据 m_timer.start(1000); } else { ui->statusLabel->setText("Connection failed"); } } void MainWindow::on_readButton_clicked() { SensorData data; if (CSharpBridge::readSensorData(data)) { ui->tempLabel->setText(QString::number(data.temperature)); ui->humLabel->setText(QString::number(data.humidity)); ui->timeLabel->setText(QString::number(data.timestamp)); } else { ui->statusLabel->setText("Read failed"); } }3.6 步骤六：构建与部署的三项铁律
DLL拷贝规则：最终部署目录必须包含三个DLL：
Bridge.dll、DeviceControl.dll、以及msvcp140.dll和vcruntime140.dll（VS 2015+运行时）。用dumpbin /dependents Bridge.dll可查看依赖项。我写了个批处理脚本自动拷贝：@echo off set BRIDGE_DIR=..\Bridge\x64\Release\ set TARGET_DIR=.\deploy\ mkdir %TARGET_DIR% copy %BRIDGE_DIR%Bridge.dll %TARGET_DIR% copy %BRIDGE_DIR%DeviceControl.dll %TARGET_DIR% copy "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Redist\MSVC\14.29.30133\x64\Microsoft.VC142.CRT\*.dll" %TARGET_DIR%.NET Framework检查：安装包必须检测目标机是否安装对应版本。用Qt代码检查：
QSettings reg("HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\NET Framework Setup\\NDP\\v4\\Full", QSettings::NativeFormat); int version = reg.value("Release").toInt(); // version >= 528040 表示 .NET 4.8+错误日志双通道：C++/CLI层用
OutputDebugString输出到DbgView，Qt层用qInstallMessageHandler捕获日志。两者日志需带时间戳和模块标识，便于关联分析。曾有个项目因客户机禁用了Debug输出，导致异常无声消失，后来在Bridge.cpp中增加了文件日志：System::IO::File::AppendAllText("bridge.log", System::DateTime::Now.ToString("yyyy-MM-dd HH:mm:ss") + " Error: " + ex->Message + "\n");
3.7 步骤七：调试与验证的黄金组合
- DbgView抓取托管异常：Sysinternals的DbgView是必备工具。运行时勾选“Capture Global Win32”，即可看到C++/CLI层
OutputDebugString输出的所有信息，包括托管异常详情。 - QLibrary加载路径验证：在Qt中打印
QLibrary::libraryPaths()，确认applicationDirPath()在搜索路径首位。若不在，用QLibrary::addLibraryPath(QApplication::applicationDirPath())显式添加。 - Dependency Walker替代方案：老版Dependency Walker不支持.NET DLL，改用 Dependencies 工具，它能清晰显示Bridge.dll依赖的
mscoree.dll（.NET运行时入口）和DeviceControl.dll。
4. 高阶技巧与避坑指南：那些文档里不会写的实战真相
走到这一步，你已经能跑通基础调用。但真实项目远比Demo复杂——数据量大、线程并发、异常频发、客户环境千奇百怪。以下是我在三个产线项目中总结的高阶技巧和血泪教训，每一条都对应一个曾让我加班到凌晨三点的问题。
4.1 技巧一：用C++/CLI实现“托管回调”到Qt信号，彻底解耦UI线程
C# DLL常需异步通知Qt（如设备状态变更、数据到达）。若在C#线程中直接调用Qt的emit signal()，会因跨线程访问导致崩溃。正确做法是在C++/CLI层建立回调机制：
// Bridge.h 中添加 typedef void (*DataReadyCallback)(float temp, float hum, long long ts); extern "C" __declspec(dllexport) void SetDataCallback(DataReadyCallback cb); // Bridge.cpp 中实现 static DataReadyCallback g_callback = nullptr; extern "C" __declspec(dllexport) void SetDataCallback(DataReadyCallback cb) { g_callback = cb; } // 在C#的事件处理中（如DeviceManager.DataReceived事件） void OnDataReceived(DeviceNS::SensorData^ data) { if (g_callback) { g_callback((float)data->Temperature, (float)data->Humidity, (long long)data->Timestamp); } }Qt端注册回调：
// MainWindow.cpp static void onDataReady(float temp, float hum, qint64 ts) { // 注意：此函数在C#线程中执行，不能直接操作UI // 用QMetaObject::invokeMethod切回主线程 QMetaObject::invokeMethod(qApp, [temp, hum, ts]() { emit sensorDataReady(temp, hum, ts); // 自定义信号 }); } // 构造函数中注册 typedef void (*SetCallbackFunc)(void (*)(float, float, long long)); SetCallbackFunc setCb = (SetCallbackFunc)m_library.resolve("SetDataCallback"); if (setCb) setCb(onDataReady);这招救了我两次：一次是某PLC通信模块，C#侧用
Task.Run轮询设备，每200ms触发一次回调；另一次是医疗设备的心电图实时流，回调频率达1kHz。若用Qt的QTimer模拟，延迟抖动极大；而原生回调+invokeMethod，实测端到端延迟稳定在1.2ms以内。
4.2 技巧二：处理C#中复杂的泛型集合与自定义类型
C#的List<SensorData>或Dictionary<string, object>无法直接传给Qt。暴力方案是序列化为JSON字符串，但性能差。高效方案是C++/CLI层做“扁平化”转换：
// Bridge.h 添加 extern "C" __declspec(dllexport) int GetSensorDataArray(float* temps, float* hums, long long* timestamps, int maxCount, int* actualCount); // Bridge.cpp 实现 extern "C" __declspec(dllexport) int GetSensorDataArray( float* temps, float* hums, long long* timestamps, int maxCount, int* actualCount) { try { if (!g_deviceManager) return -1; // 获取托管列表 System::Collections::Generic::List<DeviceNS::SensorData^>^ list = g_deviceManager->GetRecentData(100); // 假设C#有此方法 int count = list->Count; *actualCount = qMin(count, maxCount); // 用pin_ptr固定原生数组，避免GC移动 pin_ptr<float> pTemp = &temps[0]; pin_ptr<float> pHum = &hums[0]; pin_ptr<long long> pTs = ×tamps[0]; for (int i = 0; i < *actualCount; i++) { DeviceNS::SensorData^ data = list[i]; pTemp[i] = (float)data->Temperature; pHum[i] = (float)data->Humidity; pTs[i] = (long long)data->Timestamp; } return 0; } catch (...) { return -1; } }Qt端调用：
std::vector<float> temps(100), hums(100); std::vector<qint64> timestamps(100); int actual = 0; if (getArrayFunc(temps.data(), hums.data(), timestamps.data(), 100, &actual) == 0) { for (int i = 0; i < actual; i++) { qDebug() << "Data" << i << ":" << temps[i] << hums[i] << timestamps[i]; } }4.3 避坑指南：CLR初始化时机与多实例冲突的终极解法
最大陷阱：当Qt程序创建多个CSharpBridge实例（如多个窗口都调用），C++/CLI层的静态变量g_deviceManager会被共享，导致设备连接状态混乱。更糟的是，若第一个窗口卸载了Bridge.dll，第二个窗口再调用就会崩溃。
根本解法：用C++/CLI的gcroot和句柄管理：
// Bridge.h typedef void* DeviceHandle; extern "C" __declspec(dllexport) DeviceHandle CreateDeviceHandle(); extern "C" __declspec(dllexport) void DestroyDeviceHandle(DeviceHandle handle); extern "C" __declspec(dllexport) int ConnectWithHandle(DeviceHandle handle, const char* ip, int port); // Bridge.cpp #include <msclr/gcroot.h> using namespace msclr; // 用gcroot包装托管对象，每个句柄独立 struct DeviceContext { gcroot<DeviceNS::DeviceManager^> manager; }; extern "C" __declspec(dllexport) DeviceHandle CreateDeviceHandle() { DeviceContext* ctx = new DeviceContext(); ctx->manager = gcnew DeviceNS::DeviceManager(); return (DeviceHandle)ctx; } extern "C" __declspec(dllexport) void DestroyDeviceHandle(DeviceHandle handle) { if (handle) { DeviceContext* ctx = (DeviceContext*)handle; delete ctx; } } extern "C" __declspec(dllexport) int ConnectWithHandle(DeviceHandle handle, const char* ip, int port) { if (!handle) return -1; DeviceContext* ctx = (DeviceContext*)handle; try { System::String^ managedIp = gcnew System::String(ip); return ctx->manager->Connect(managedIp, port) ? 0 : -1; } catch (...) { return -2; } }Qt端改为：
class DeviceSession { public: DeviceSession() { m_handle = createHandleFunc(); } ~DeviceSession() { if (m_handle) destroyHandleFunc(m_handle); } bool connect(const QString& ip, int port) { QByteArray ipBytes = ip.toLocal8Bit(); return connectFunc(m_handle, ipBytes.constData(), port) == 0; } private: DeviceHandle m_handle; };这样每个Qt对象拥有独立的C#设备实例，彻底解决状态污染。我在某多屏HMI系统中用此方案，支持6个独立设备连接，运行30天零异常。
4.4 避坑指南：.NET Framework更新导致的“静默失败”
Windows Update常自动升级.NET Framework（如从4.7.2升到4.8），某些C# DLL在新版中行为改变（如DateTime序列化格式），导致Qt端解析出错。但错误不抛出，只是返回错误数据。
防御性策略：在C++/CLI层添加版本校验钩子：
// Bridge.cpp 开头添加 static bool CheckDotNetVersion() { // 检查运行时版本 System::Environment::Version^ ver = System::Environment::Version; if (ver->Major < 4 || (ver->Major == 4 && ver->Minor < 7)) { OutputDebugString(L"Bridge: .NET version too low!"); return false; } // 检查C# DLL的AssemblyVersion System::Reflection::Assembly::GetExecutingAssembly()->GetName()->Version; return true; }并在每个导出函数开头调用。Qt端若收到特定错误码（如-100），即提示用户检查.NET版本。
最后分享一个真实案例：某客户现场所有机器.NET Framework被IT部门统一升级，我们的设备连接成功率从99.9%跌到60%，日志里全是ReadSensorData返回-3。排查三天，发现是C# DLL中DateTime.Now在.NET 4.8中精度提升，导致Qt端用QDateTime::fromMSecsSinceEpoch解析时溢出。解决方案是在C++/CLI层强制转为秒级时间戳：
*timestamp = (long long)(data->Timestamp / 10000000i64); // .NET ticks to seconds这种细节，只有在产线滚过几遍的人才会刻骨铭心。Qt与C#的协作，从来不是“调通就行”，而是要在每一个字节、每一个线程、每一个异常分支上，都布下严密的防护网。
