企业官网建设流程全解析

简介：面向工业自动化领域的DAQ122 IPC SDK设计源码，提供C++、C、C#三语言兼容的开发接口，适合需要对接采集硬件、实现数据读取与上层应用的开发者使用。压缩包共498个文件、约33.97MB，以408个.h头文件为主体，配合cpp、cs源文件及dll动态库构成核心功能，另有PNG图片、Markdown文档、VI文件、示例工程和驱动/图片目录，便于理解模块划分并快速定位所需内容。已有309人学习下载。这套源码既可用于实际项目的二次开发，也可作为学习DAQ设备驱动封装、跨语言SDK组织方式和上位机采集交互的完整参考，目录结构清晰，能帮助开发者减少从零搭建的重复工作。

1. DAQ122 多语言 SDK：这套 IPC 源码包里到底有什么

在工业上位机开发里，最怕的不是算法难写，而是设备商给的 SDK 只支持一种语言。你手上的 DAQ122 采集模块，如果只给 C++ 接口，C# 团队就得自己用 SerialPort 或者 TCP 再包一层协议；如果只给 C# 接口，C++ 侧的实时采集逻辑又没法复用。这套基于 C++/C/C# 多语言兼容的 DAQ122 IPC SDK 设计源码，把核心采集逻辑写在 C++ 侧，用 C 作为稳定 ABI，C# 直接 DllImport 调用。它解决的典型痛点是：C++ 写的帧解析、环形缓冲、设备管理可以被 C 和 C# 同时复用，不用为每个语言栈复制第二份逻辑。适合正在设计设备 SDK 的嵌入式工程师，也适合想把 DAQ122 接入 WinForms/WPF 上位机的应用层开发。下面按分层结构、C++ 实现、C# 接入、常见坑位和验证顺序逐层拆。

2. SDK 分层设计：为什么核心用 C++，对外用 C，托管层用 C#

这一层是整个 SDK 的骨架。DAQ122 的 IPC 通道要同时被 C++ 服务端、C 客户端和 C# 上位机调用，直接暴露 C++ 类显然行不通。C# 不能消费 C++ 未修饰的类布局，C 编译器也没法链接重构后的符号。所以分层顺序是：C++ 实现“怎么做”，C API 决定“能卖什么接口”，C# 封装负责“用起来像原生类”。这三者的边界一旦划清，后面生成文档、写测试、挂调试器都清爽很多。

2.1 为啥不直接用 C++/CLI 一统天下

我最早也想过全程用 C++/CLI 做 .NET 封装，因为能直接写 ref class 引用 C++ 工厂，省掉 DllImport 的手写签名。但 C++/CLI 有几个硬伤：编译环境强制绑定 MSVC 和 Windows，如果 DAQ122 侧未来要出 Linux 版 IPC 服务，这套托管封装立刻作废；C++/CLI 生成的混合程序集在 .NET Core 环境里兼容性很差，运行时报找不到 runtime 的案例一搜一大把。所以中间层选标准 C API 最保险，把 C++/CLI 只作为可选项保留。C API 是 C++ 与 C# 之间的 ABI 共识，结构体布局、回调函数指针、错误码都围着它转。

2.2 目录结构先定好，防止后面重构

这份源码里，我习惯把目录按 core / api / managed / samples / cmake 切开：

• core：C++ 实现，包含设备枚举、IPC 帧协议、环形缓冲区；对外发布时编译成 daq122_core 静态库。
• api：C 接口层，只有 daq122.h 和 daq122.c，负责把 C++ 调用包成 C 可调用函数；编译成 daq122_api.dll。
• managed：C# 项目，DllImport 声明、辅助类、回调委托包装；编译成 DAQ122.Managed.dll。
• samples：分别放 C++、C、C# 三个调用示例，每个示例只调 api 层，不允许直接 include core 的头文件。

这个隔离是硬性约定：上层如果越过 api 直接碰 core，相当于私有成员露出，后面的兼容性承诺就是句空话。任何一次跨语言崩溃，先检查是不是有人绕过了 C API 直接访问了 C++ 对象指针。

2.3 C API 的头文件签名长什么样

daq122.h 里最重要的几组函数如下：

/* daq122.h - C API for DAQ122 IPC */ #ifndef DAQ122_API_H #define DAQ122_API_H #ifdef __cplusplus extern "C" { #endif #if defined(_WIN32) # if defined(DAQ122_API_EXPORTS) # define DAQ122_API __declspec(dllexport) # else # define DAQ122_API __declspec(dllimport) # endif #else # define DAQ122_API __attribute__((visibility("default"))) #endif typedef enum { DAQ122_OK = 0, DAQ122_ERR_INVALID_PARAM = -1, DAQ122_ERR_TIMEOUT = -2, DAQ122_ERR_BUSY = -3, DAQ122_ERR_NO_DEVICE = -4 } daq122_status_t; typedef struct daq122_device daq122_device_t; typedef void (*daq122_frame_callback)(const uint8_t* data, uint32_t len, uint64_t timestamp_us); DAQ122_API daq122_status_t daq122_open(const char* addr, uint32_t timeout_ms, daq122_device_t** out_dev); DAQ122_API daq122_status_t daq122_start_stream(daq122_device_t* dev, uint32_t buf_size_kb, daq122_frame_callback cb); DAQ122_API daq122_status_t daq122_stop_stream(daq122_device_t* dev); DAQ122_API void daq122_close(daq122_device_t* dev); #ifdef __cplusplus } #endif #endif

这段头文件其实把 90% 的跨语言财富定下来了：不透明句柄 daq122_device_t 避免把 C++ 类直接暴露出去；状态码用枚举统一；回调函数指针按 C 约定，接收裸指针和长度，不传递 std::function、std::string 这些不可跨 ABI 的类型。__declspec(dllexport/dllimport) 的宏区分构建期和使用期，C# 侧感知不到这些宏，但 C++/C 工程会靠它正确生成导入库。

2.4 各语言选型边界与构建顺序

选型上我的结论是：核心逻辑必须留在 C++/C 侧做，不要在 C# 里重写帧解析；C# 只负责发起调用、接收字节块、做界面和业务。为什么这么分？DAQ122 的 IPC 数据流是高频小包，帧头解析、时间戳校准、重复包丢弃这些动作放在 C++ 侧，可以直接操作内存并减少托管堆压力。C# 侧如果做这些，每一个包都会经过一次数组拷贝，GC 压力增大不说，P/Invoke 边界还会被频繁跨越。

构建顺序我建议用 CMake 一次把 core 和 api 都编出来，避免出现“core 是 Debug、api 是 Release”这种混搭产物：

cmake_minimum_required(VERSION 3.20) project(daq122_sdk LANGUAGES C CXX) add_library(daq122_core STATIC core/session_impl.cpp core/ring_buffer.cpp ) target_include_directories(daq122_core PUBLIC core) add_library(daq122_api SHARED api/daq122.c ) target_link_libraries(daq122_api PRIVATE daq122_core) target_compile_definitions(daq122_api PRIVATE DAQ122_API_EXPORTS)

逻辑说明：project 里同时声明 LANGUAGES C CXX，是为了让 CMake 同时启用 C 编译器和 C++ 编译器，api 的 .c 文件按 C 编译，core 的 .cpp 按 C++ 编译，最后链接在一起。daq122_core 设成 STATIC，是为了减少最终 DLL 的依赖项；daq122_api 设成 SHARED，是因为 C# 侧 DllImport 需要加载动态库。target_compile_definitions 里的 DAQ122_API_EXPORTS 会在 api 工程内触发 dllexport，外部工程没有这个宏，include 头文件时走 dllimport，这个对称关系不能写反。

3. 用 C++ 实现 DAQ122 IPC 高速数据通道：共享内存、环形缓冲区与线程模型

第 2 章解决了接口契约，这一章解决性能问题。DAQ122 的 IPC 通道说白了就是采集端写、消费端读的一条高速数据管道。只靠 socket 或者命名管道，延迟上到毫秒级没问题，但要做到微秒级转发就得用共享内存。源码里默认的传输方案是：共享内存 + 环形缓冲区 + 条件变量通知，下面我拆开讲。

3.1 为什么选共享内存 + 环形缓冲，而非 Socket、管道

先说结论：IPC 场景里，Socket 的优势是跨机器和跨进程简单，缺点是要经过内核协议栈，单包延迟通常在几十微秒上下，且容易被防火墙和安全软件干扰；命名管道同样过内核，胜在权限好管。DAQ122 的需求是同机进程内的高速采集数据互通，要求抖动小、CPU 占用低，所以共享内存更合适。共享内存本质就是一块跨进程可见的物理内存，写入方和读取方各自映射同一块区域，用户态直达，不需要系统调用参与每次收发。配合环形缓冲区，写入和读取只需要移动读/写游标，在一读一写模型下不加锁也能做到无锁交替。

共享内存的创建过程，Windows 和 Linux 各写一段，核心参数是命名标识和映射大小：

#ifdef _WIN32 HANDLE hMap = CreateFileMappingW(INVALID_HANDLE_VALUE, nullptr, PAGE_READWRITE, 0, map_size, L"Local\\Dq122IpcShared"); uint8_t* view = (uint8_t*)MapViewOfFile(hMap, FILE_MAP_ALL_ACCESS, 0, 0, map_size); #else int fd = shm_open("/daq122_ipc", O_CREAT | O_RDWR, 0666); ftruncate(fd, map_size); uint8_t* view = (uint8_t*)mmap(nullptr, map_size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); #endif

这里的 map_size 不是简单等于 buffer 大小，我一般会把控制块放前面：前 128 字节存魔数、读写游标、帧计数，后面才是真正的数据缓冲区。这样读进程拿到共享内存后，第一件事就是校验魔数，避免误连到另一个项目留下的同名内存。命名上 Windows 的 Local\ 前缀表示当前会话，多用户服务器上要改成 Global\ 并处理权限；Linux 的 /daq122_ipc 是全局命名，重名时会拿到旧对象，所以挂载后先检查魔数，对不上就 shm_unlink 重建。

环形缓冲区的读写实现，我习惯这样写：

// ring_buffer.h #include <atomic> #include <cstdint> #include <cstring> #include <vector> class DqRingBuffer { public: explicit DqRingBuffer(uint32_t capacity_pow2) : capacity_(capacity_pow2) { // 容量必须是 2 的幂，这样取模可以用位运算 buffer_.resize(capacity_); mask_ = capacity_ - 1; } bool Write(const uint8_t* src, uint32_t len) { uint32_t head = head_.load(std::memory_order_relaxed); uint32_t tail = tail_.load(std::memory_order_acquire); if (len > FreeBytes(head, tail)) return false; // 分两段写入，处理绕回 uint32_t toEnd = capacity_ - (head & mask_); uint32_t first = len < toEnd ? len : toEnd; memcpy(buffer_.data() + (head & mask_), src, first); memcpy(buffer_.data(), src + first, len - first); head_.store(head + len, std::memory_order_release); return true; } bool Read(uint8_t* dst, uint32_t len) { uint32_t head = head_.load(std::memory_order_acquire); uint32_t tail = tail_.load(std::memory_order_relaxed); if (len > UsedBytes(head, tail)) return false; uint32_t toEnd = capacity_ - (tail & mask_); uint32_t first = len < toEnd ? len : toEnd; memcpy(dst, buffer_.data() + (tail & mask_), first); memcpy(dst + first, buffer_.data(), len - first); tail_.store(tail + len, std::memory_order_release); return true; } private: uint32_t FreeBytes(uint32_t head, uint32_t tail) const { return capacity_ - (head - tail); } uint32_t UsedBytes(uint32_t head, uint32_t tail) const { return head - tail; } std::vector<uint8_t> buffer_; uint32_t capacity_; uint32_t mask_; std::atomic<uint32_t> head_{0}; std::atomic<uint32_t> tail_{0}; };

逻辑说明：环形缓冲的读写索引是无符号 32 位整数，绕回计算靠 capacity 是 2 的幂这个前提，head 减去 tail 不会出现负值，无符号溢出在 C++ 标准里是定义好的行为。写侧在写入前把 head 加载进局部变量，读侧把 tail 加载进去，这样一个 producer 和一个 consumer 的模型下不会出现数据竞争，memory_order_acquire/release 保证对方看到完整数据。参数 capacity 我通常给 4MB，对应 2048 字节一帧大概能缓冲 2048 包，足够覆盖消费端的调度抖动。如果你只有一个读线程一个写线程，这套代码可以直接搬到自己的项目里；多个生产线程同时写就需要加锁，这是另一个话题。

3.2 线程模型：采集线程、通知线程和消费者线程

环形缓冲本身解决存储问题，但消费端不能靠轮询死等。源码里用条件变量做“数据到达通知”，生产线程在写入一帧后调用 notify_one；消费线程 wait_for 超时 10 毫秒，被唤醒后批量把缓冲里的帧取走。这里有个性能细节：notify 要放在环形缓冲写入完成之后，否则消费端读到半帧数据会解出错误长度，进而在帧解析处翻车。还有，如果每帧都 notify，高频小包场景下线程上下文切换会吃掉 CPU；我一般让生产端攒 4 帧或者累计 8KB 再 notify 一次，消费端即使晚一点醒来，吞吐量反而更高，延迟偶尔增加但不能超过 1ms 的采集容忍度。

3.3 导出 C 函数时怎么写实现

C 层 api 文件里的每个函数都要处理 C++ 的异常边界，不能让任何一个 std::exception 穿过 extern "C" 边界，否则 C# 侧会直接进程崩溃。常见的做法是包一层 try/catch：

#include "daq122.h" #include "session_impl.hpp" extern "C" { DAQ122_API daq122_status_t daq122_start_stream(daq122_device_t* dev, uint32_t buf_size_kb, daq122_frame_callback cb) { if (!dev || !cb) return DAQ122_ERR_INVALID_PARAM; try { auto* impl = reinterpret_cast<SessionImpl*>(dev); return impl->StartStream(buf_size_kb, cb); } catch (const std::exception& e) { // 这里把异常转成错误码，不能把 C++ 异常抛出边界 return DAQ122_ERR_INTERNAL; } } }

这段代码看着简单，但每次写导出函数我都强制走一遍这个模板。参数里的回调函数指针是 C 层传进来的，在 C++ 实现里以普通函数指针保存即可；如果 core 内部用 std::function，需要做一个适配器包一下，否则函数指针和 std::function 是两套东西。另外注意回调里传的 uint64_t timestamp_us，含义是设备硬件时钟的时间戳，不是墙钟时间，业务侧做对齐时要用它，而不是 DateTime.Now。

3.4 四个关键参数怎么调

• buf_size_kb：环形缓冲区大小，默认 4096KB，如果采集帧长波动大，可提到 16384；小于 512KB 时容易出现覆盖丢帧。
• timeout_ms：open 时等待设备就绪的最大毫秒数，做上位机联调时先给 5000，生产环境一般写成 1000。
• 攒帧通知阈值：我内部放在配置结构里，默认 8KB，如果上层业务要求低延迟，改成 1 帧。
• 内存映射的 page 数目：共享内存在 Windows 上要用 CreateFileMapping 并在大小上按页对齐，Linux 用 shm_open 后 ftruncate，page 数目最好按缓冲区大小对齐到系统页大小，否则映射大小会小于请求值，读写越界静默发生。

这些参数一旦改错，多数症状不是报错，而是数据悄悄变慢或帧丢失，所以后面要专门讲怎么排查这类“无报错的异常行为”。

4. C# 侧接入：P/Invoke 签名、内存布局与回调委托的正确姿势

C# 接入多语言 SDK 最容易落入的陷阱是“把 C 头文件翻译成 C# 声明就完事”。DllImport 只是开始，结构体内存布局、字符串编码、回调生命周期，任何一个出问题都会复现那种经典的 AccessViolation。这一章按我实际验证过能跑的姿势来写。

4.1 DllImport 声明和结构体布局

C# 侧首先要把 daq122.h 的类型描述准确，尤其是结构体对齐。默认情况下 C# 没指定 Pack 时会按 8 字节对齐，而 C 侧如果按 4 字节打包，就会错位。建议统一在结构体上标 Pack = 4，并跟 C 侧的头文件保持一字不差：

[StructLayout(LayoutKind.Sequential, Pack = 4)] internal struct DqFrameHeader { public uint Magic; // 0xD122D122 public uint Seq; // 帧序号 public UInt64 TimestampUs; public uint DataLength; // 载荷长度，不含头 } public sealed class DqDevice : IDisposable { private IntPtr _handle; [DllImport("daq122_api.dll", CallingConvention = CallingConvention.Cdecl, CharSet = CharSet.Ansi)] private static extern int daq122_open(string addr, uint timeoutMs, out IntPtr outDev); }

逻辑说明：daq122_open 的第一个参数是字符串，这里的 CharSet.Ansi 很关键。C++ 侧如果用 char* 接收，C# 侧写成 string 并标记 Ansi，P/Invoke 会把它按系统代码页转过去；如果忘记标，.NET Framework 默认是 Ansi，但 .NET Core 默认是 UTF-8，两边行为不一致就会在设备地址解析上出错。更稳妥的方案是直接用 IntPtr 加 Marshal.StringToCoTaskMemUTF8 手动转换，绕开默认值差异。设备句柄必须用 out IntPtr 接收，不要试图用类引用去接，那是一个常见的翻车位。

4.2 回调委托：不能声明成局部变量

daq122_start_stream 接受帧回调。如果这个委托变量是局部临时变量，P/Invoke 调用返回后它会被 GC 回收，C++ 侧下一次异步触发时就会拿着悬空函数指针，直接 AccessViolation。正确做法是把委托存到字段里，且在 StopStream 之后再释放：

public sealed class DqStream : IDisposable { private DqFrameCallback _callback; private GCHandle? _pinned; public void Start() { _callback = OnFrame; // 把委托固定住，防止 GC 移动其内部对象 _pinned = GCHandle.Alloc(_callback); int rc = daq122_start_stream(_handle, 4096, _callback); if (rc != 0) throw new DqException(rc); } private void OnFrame(IntPtr data, uint len, ulong tsUs) { var header = Marshal.PtrToStructure<DqFrameHeader>(data); // 业务处理 } public void Dispose() { daq122_stop_stream(_handle); _pinned?.Free(); _callback = null; } }

这段的关键是把 _callback 保留到停止之后。很多人只做 GCHandle.Alloc 却忘了停止之后还要 Free，结果进程退出时才报错；我在源码实现里把 GCHandle 的释放放在 Dispose 的最后一行，顺序错一步都可能让回调残留。还有一个点：回调里不要直接调用 Console.WriteLine 或 MessageBox，因为高频回调情况下 UI 操作会阻塞管道；如果实在要打日志，先拷出数据，异步写文件。

4.3 用 C++/CLI 包一层“后悔药”

如果受不了纯 P/Invoke 的手写签名，也可以把 DllImport 这层替换成 C++/CLI 封装。C++/CLI 能直接 include daq122.h 并调用原生 C 函数，然后在 ref class 里以 .NET 方法暴露，不需要写 IntPtr 转换。风险在前面说过：环境绑定死 MSVC，且 Linux 上不可用。我的习惯是把它做成可选编译目标，只在纯 Windows 项目里用，核心解决方案仍然维持 C API + DllImport。如果你刚上手，建议先用纯 P/Invoke 跑通，等对整个流程有把握再用 C++/CLI 换皮，不然分层一乱，后面排查成本很高。

4.4 异步读取线程和 UI 线程的协调

C# 上位机常见的做法是：回调里把帧转成 Byte[] 后放到 ConcurrentQueue，然后 UI 线程的 DispatcherTimer 定时批量取走刷新。不要直接在回调里访问 UI 控件，因为回调来的线程是不确定的 C++ 线程，在 WinForms/WPF 里跨线程访问控件会抛异常。代码上我一般这样组织：

private readonly ConcurrentQueue<byte[]> _frameQueue = new(); private void OnFrame(IntPtr data, uint len, ulong tsUs) { var copy = new byte[len]; Marshal.Copy(data, copy, 0, (int)len); _frameQueue.Enqueue(copy); } private async Task PollQueueAsync() { while (!_cancelled) { while (_frameQueue.TryDequeue(out var frame)) { await Task.Run(() => ProcessFrame(frame)); // 不让 UI 卡死 } await Task.Delay(16); } }

说明：queue 的作用是把高频回调和平滑 UI 解耦，16ms 的轮询间隔对应约 60 fps，符合大多数波形界面的刷新预期。拷贝这里的 len 直接用回调给的逻辑长度，而不是整个缓冲区长度，不然会把尾部垃圾数据也搬过去。如果担心 GC 压力，可以把 Byte[] 换成池化数组，但先跑对再优化，这条经验我踩过不少次。

5. 避坑手册：多语言 SDK 的 5 个高频崩溃现场

这一章是用任务清单换来的。跨语言调用崩溃，根本原因通常集中在类型布局、生命周期、线程模型和链接方式上。下面 5 条按实际故障频率排序，每条都写了现象、原因和处理办法，照着核对基本能定位。

5.1 现象：C# 调用 daq122_start_stream 时不断报 AccessViolation(C0000005)

原因：90% 是 DllImport 的 CallingConvention 选错。C++ 侧函数默认是 __cdecl，而 C# DllImport 如果不写 CallingConvention，在 x86 平台上默认是 StdCall；参数多的时候栈平衡不一致，返回后栈指针错位，就会在第一次调用成功、第二次调用时崩。解决：显式在 DllImport 里写 CallingConvention = CallingConvention.Cdecl，并且 EntryPoint 不要写成 C++ 修饰名。我这里还遇到过更隐蔽的原因：回调委托变量被 GC 回收，现象也是 AccessViolation，但崩溃时机往往延迟到下一次 GC 之后。所以遇到 C0000005 先检查这两个点，一个查调用约定，一个查委托生命周期。

5.2 现象：C++ 侧回调正常，C# 侧却收不到数据，程序不报错

原因：回调里把数据拷贝时机搞错了。C 回调给的 data 指针指向环形缓冲内部，如果回调返回后缓冲区被覆盖，而 C# 侧只保存了 IntPtr 而没有立即 Marshal.Copy，之后再拿 IntPtr 去读，就是旧数据或随机数据。解决：在回调函数内部就完成拷贝，绝对不要把指针存下来等会儿再用。另一种情况是 C# 侧把回调注册到 daq122_start_stream 后，承载回调的服务线程没有保持存活，导致线程池回收，但这种情况较少，排查时先排除拷贝时机。

5.3 现象：C/C++ 侧传出的字符串在 C# 里显示乱码

原因：C++ 侧返回 char* 编码不统一，C# 侧按 Unicode 解析。解决：在 C API 定义处统一用 UTF-8 作为交换编码，头文件注释里写明“所有字符串参数均为 UTF-8”。DllImport 里用 string 接收时，.NET Framework 和 .NET Core 的默认 CharSet 行为不一致；如果嫌版本差异，干脆全部用 IntPtr + Marshal.PtrToStringUTF8，不依赖默认 CharSet。这也是我在 4.1 里建议字符串参数尽量手动转换的原因。

5.4 现象：32 位调试编译正常，切到 64 位后 open 直接返回空句柄

原因：DAQ122 的驱动库或依赖的第三方库只提供了 32 位版本，SDK 编译成 x64 后 LoadLibrary 时找不到依赖 DLL，运行时也不会弹“缺 DLL”的框，只会在调 open 时得到错误码或空句柄。解决：先确认 DAQ122 底层驱动是否有 x64 版本，如果有，保证整个调用链都是 x64；如果只有 x86，客户端 C# 项目也得强制 x86，不要在 Any CPU 下抱着侥幸心理。排查时用 Process Explorer 看加载的模块里有没有 daq122 相关依赖被重定向，或者用 Dependencies 工具检查 api 工程的所有 DLL 依赖。

5.5 现象：C++ 调用自己导出的 C API 没问题，C# 调用就触发 0xC0000409

原因：跨 C API 边界的异常没被 catch。C++ 实现里任何未捕获的 std::exception 传到 extern "C" 函数外，在 .NET 眼里就是未处理异常，直接快速失败。解决：统一在导出函数入口加 try/catch，并返回错误码。我已经把这条固化成模板，每个导出函数必须经过同一个异常转换宏，不接受任何“这里不可能抛异常”的说法，因为 std::bad_alloc 在任何地方都可能发生。另外，Debug 和 Release 构建混用也会触发类似问题，检查 C# 引用的 DLL 和 C++ 工程是否同一构建类型。

6. 验证与进阶：把 IPC 延迟和吞吐量压到一个可接受区间

最后一章聊验证，不聊概念。多语言 SDK 交付前，至少要做三件事：压测吞吐、验证回调时序、核对内存增长曲线。很多人只测“能跑通”就发布，结果客户现场出现间歇性丢帧，再定位就难了。我的经验是先把指标打出来再发版。

6.1 最小压测工程：循环接收 100 万帧统计

我在源码里放了一个 benchmark 目录，C++/C# 各写一份。核心思路是：生产者造 100 万帧并写入环形缓冲，消费者统计收到帧数、延迟 p50/p95/p99，最后打印丢帧率。C# 侧代码简化后如下：

var sw = Stopwatch.StartNew(); long received = 0; long expected = 1_000_000; var stream = new DqStream(dev); stream.FrameReceived += (frame) => { Interlocked.Increment(ref received); }; stream.Start(); while (Interlocked.Read(ref received) < expected) { Thread.Sleep(5); } sw.Stop(); var stats = stream.GetStats(); Console.WriteLine($"Received={received}, elapsed={sw.ElapsedMilliseconds}ms, " + $"throughput={received / sw.Elapsed.TotalSeconds:F0} fps, " + $"drop={expected - received}");

注意 GetStats 里的 p99 延迟是 C++ 侧在每帧时间戳里计算的，委托里打印的 elapsed 只能代表“收到最后一帧的时间”，不代表单帧延迟；要拿真实延迟，必须用回调时间戳与发送时间戳做差。压测时机器负载要控制在 CPU 占用 20% 以下，否则延迟分布被系统调度污染，读出来的 p99 没有参考价值。

6.2 验证内存增长曲线：抓托管堆和原生堆

另一个隐性问题是内存泄漏：C# 侧每次回调 Marshal.Copy 分配的 Byte[] 看似即时释放，其实可能被 LOH 回收卡住。所以压测里我会同时观察两个指标：C++ 侧用 AddressSanitizer 跑用例看原生泄漏；C# 侧用 PerfView 看 GC 分配总量。要点是让 queue 不回积：ConcurrentQueue 的 Count 要稳定在一个值附近，如果持续增加，说明消费速度跟不上生产速度，这不是内存问题，而是吞吐瓶颈。

6.3 我现在习惯用的验证组合

固定流程是这样的：先用 C++ 控制台跑一轮 100 万帧，打印吞吐；然后切到 C#，跑同样的轮数，对比两者吞吐差距，差距超过 20% 就要找 P/Invoke 频繁调用或者拷贝问题；最后在 Debug 下开着调试跑逻辑，在 Release 下验证性能。从那以后我每次做跨语言 SDK 都强制走一遍这套流程——先压测再交付，再把回调里的数据拷贝时机和委托回收周期钉死在代码规范里。希望帮到你。

本文还有配套的精品资源，点击获取