简介：这份森锐身份证识别模块SDK全套源码面向需要在Android与iOS应用中集成身份证信息自动识别能力的开发者，核心围绕OCR文字提取、相机采集与识别结果回传展开，适合希望理解SDK内部实现并进行定制化改造的中高级移动端开发人员。资源包为zip格式，体积约16.46MB，上游未披露文件总数与类型明细，下载后可自行查看工程目录与源码组织。已有1589人学习，说明该模块在身份证识别场景中具有一定关注度。读者可从中接触Android与iOS双端工程代码、API调用方式、图像预处理流程、机器学习模型推理、权限管理、UI集成、错误处理与日志记录、性能优化及数据安全等实现线索，并据此梳理从初始化识别器、上传图片到开始识别的完整链路，为后续集成、排错和二次开发提供参考。

1. 用一台读卡器，看清"身份证识别模块"到底重在哪

前台值守机、酒店登记台、考场入口，插上一个巴掌大的读卡器，把证件放上去，两三秒后姓名、号码、照片出现在屏幕上——这大概是"身份证识别模块"最日常的形态。很多人第一次接手这类需求时的直觉是：不就是读个卡嘛，调个 DLL 完事。真正做过一轮的人会发现，编码、照片解码、位数、安全模块授权，每一件都能让你在客户现场改代码改到深夜。这套 SDK 全套源码的价值就在于此：它给出的不是一段孤立的调用示例，而是一整条从 USB 通信、设备寻卡、文本信息解析到 WLT 照片转 BMP 的完整链路，覆盖 C/C++、C#、Java、Delphi 等多个调用侧。适合两类人：一类是要在两三天内把读卡功能接进现有业务系统的应用开发，另一类是打算自己封装一层读卡服务、做多设备管理与二次开发的人。

2. SDK 包解构：一个身份证识别模块由哪几层拼起来

把压缩包解开，第一感觉通常是"文件夹怎么这么多"。它并不是一堆同质化的示例堆在一起，而是严格按分层组织的：最底下是硬件与驱动，中间是通信与协议，再往上是解码，最上面才是你真正调用的那几个函数。理解了这个分层，后面出问题时你就知道该往哪一层看，而不是对着一个错误码反复重启程序。

2.1 从目录结构看四层架构：硬件层、通信层、解码层、业务层

一套完整的身份证识别模块 SDK，目录结构常见做法是长这样（不同版本文件夹名会差几个字，但分层基本一致）：

IDCardSDK/ ├── bin/ │ ├── x86/ IDCardDll.dll WltDecode.dll Comm.dll │ └── x64/ IDCardDll.dll WltDecode.dll Comm.dll ├── include/ IDCardApi.h IDCardType.h ├── lib/ │ ├── x86/ IDCardDll.lib │ └── x64/ IDCardDll.lib ├── driver/ 串口.inf HID.inf ├── demo/ CSharp/ Cpp/ Java/ Delphi/ VB/ ├── doc/ 接口说明书.pdf 通信协议.pdf 版本变更.txt └── tools/ 读卡测试工具.exe WLT转BMP工具.exe

bin下的三个 DLL 对应三个职责，这个划分是理解整个 SDK 的关键。Comm.dll负责和读卡器建立物理通道，屏蔽掉底下是串口还是 HID 的差异；IDCardDll.dll是协议层，把"寻卡、选卡、读基本信息、读补充信息"这些动作翻译成读卡器能听懂的指令帧；WltDecode.dll只干一件事，把证件照的压缩数据还原成位图。上层业务只要拿到IDCardDll.dll的导出函数，中间那层协议细节完全不用管。

硬件层是最容易被忽略的一层。读卡器内部除了读卡天线，还有一块安全控制模块，行业里习惯叫 SAM 小卡，插在机器侧面的卡槽里。所有身份信息的解密都在这一小块上完成，SDK 本身不做解密算法。所以"程序能跑但读不出数据"的场景里，有很大一部分根本不是代码问题，而是 SAM 卡没插好、插反了，或者这张卡和这台机器不配套。

提示：拿到包先别急着写代码，把tools/里的读卡测试工具跑一遍。工具能读出数据，说明硬件、驱动、SAM 全通，问题一定在你自己的调用代码里；工具也读不出，就别在代码里找了。

2.2 四个必须认识的文件夹：bin、include、lib、demo

bin是运行时依赖，程序最终发布时这个目录里的东西必须跟着走，而且只能跟一份。我见过太多项目把 x86 和 x64 两套 DLL 全塞进输出目录，结果进程随机加载到错的那一份，报"找不到入口点"或者直接崩在LoadLibrary里。

include里是头文件，IDCardType.h定义了所有结构体，比 PDF 文档可信得多。文档会过期，头文件不会——字段顺序、数组长度、字符编码的注释，都以头文件为准。lib是导入库，只给 C/C++ 用；C# 走 P/Invoke 不需要它，Java 走 JNA 也不需要。

demo是整个包里信息密度最高的地方。不要只跑那一个 C# 示例就结束，至少把 C++ 那份也翻一遍：C++ 示例里能看到结构体的内存布局和调用顺序，而 C# 示例往往把这些细节藏在封装类里，出问题时你根本不知道底层发生了什么。Delphi 和 VB 的示例则能帮你确认导出函数的调用约定到底是stdcall还是cdecl，这一点在跨语言接入时非常致命。

2.3 一张对照表：不同语言怎么接同一个 DLL

同一个IDCardDll.dll，不同语言调用侧的做法差别很大，坑也各不相同：

表格里"C# 编码"那一条值得单独说一句。这类 SDK 返回的文本信息，绝大多数是 GBK 编码而不是 UTF-8，因为历史协议就是这么定的。你在 .NET Framework 下用Encoding.Default可能恰好是对的，一旦迁到 .NET Core 或 .NET 5+，Encoding.Default变成了 UTF-8，姓名立刻变乱码。解决办法是显式指定代码页，并且注册编码提供程序——这一点后面给具体代码。

2.4 SAM 安全模块的位置：授权在机器上，不在代码里

再强调一次这个分层里最特殊的一环。很多人以为只要拿到 SDK 就能在任何设备上读卡，实际上这类模块的可用性是和硬件绑定的：读卡器内置的安全模块有独立的序列号，SDK 初始化时会去校验它。有些厂商的做法更严格，还需要一份和读卡器序列号或主板绑定的授权文件，缺了这个文件，OpenDevice会返回成功，但FindCard永远失败。

所以如果你打算把程序部署到多台机器上，先确认授权是怎么走的：是每台机器配一个读卡器（授权跟着设备走），还是需要按机器数申请授权文件（授权跟着主机走）。这个信息在doc/里一般有说明，但往往写得比较含糊，最稳的办法是拿两台不同机器实测一遍。

分层的意义到这儿就清楚了：硬件层决定"能不能读"，通信层决定"连不连得上"，解码层决定"读出来是不是乱码"，业务层决定"你的程序会不会崩"。绝大多数线上问题，答案都在这四层里能定位到具体一层。

3. 核心接口拆解：从寻卡到照片落盘的完整调用链

真正写业务代码时，你会发现整个流程其实只有五步：打开设备、寻卡、选卡、读信息、关设备。但这五步之间的顺序、返回值语义、以及每一步失败后该怎么处理，才是 SDK 真正需要吃透的部分。这一章把这条链拆开，每个环节给一段可以照着写的代码。

3.1 打开设备与寻卡：先 Open 再 Find，顺序不能反

导出函数的形态在不同版本里名字会差几个字母，但语义基本一致，头文件里大致是这样一组声明：

// 打开设备，nPort 为串口号，USB 虚拟串口方案下通常是 1~16 // 也有版本是无参的 OpenDevice()，由底层自动扫描 int OpenDevice(int nPort); // 寻卡：卡放在感应区才返回成功 // 返回 0 表示找到卡，非 0 为错误码（具体含义查头文件里的宏定义） int FindCard(void); // 选卡：拿到卡的操作权，多卡环境下必须先选再读 int SelectCard(void); // 关闭设备，释放串口/句柄 int CloseDevice(void);

顺序不能颠倒的原因很直接：FindCard走的是设备通道，通道没打开它连指令都发不出去，只会返回一个含糊的错误码。SelectCard在很多单卡场景下看似可有可无，因为FindCard内部已经隐式选了一次，但一旦换成支持多卡并发的读写器，跳过这一步就可能读到另一张卡的数据。

FindCard是这套接口里最需要"轮询"的一个。卡放上去到天线感应完成，中间有几十到几百毫秒的延迟，如果你在 UI 线程里调一次没成功就报"请放卡"，用户会以为设备坏了。稳妥的写法是启动一个后台线程，每 200 到 300 毫秒调一次，连续失败若干次之后再提示。

// 轮询寻卡的最小实现，放在独立线程里跑 int WaitCard(int timeoutMs) { int elapsed = 0; while (elapsed < timeoutMs) { if (FindCard() == 0) { // 0 = 找到卡 if (SelectCard() == 0) { // 选卡成功才能读 return 0; } } Sleep(200); // 间隔别低于 100ms，太密会占满串口 elapsed += 200; } return -1; // 超时 }

参数上唯一要调的是timeoutMs。窗口业务一般给 3000 到 5000 毫秒，考试核验这种要求快速反馈的场景给 2000 毫秒足够。Sleep的间隔不要压到 50 毫秒以下，这类设备走的是低速通道，指令发太密反而会丢帧，表现就是"偶尔能读、偶尔读不到"这种玄学问题。

3.2 读文本信息：结构体里那些一眼看不出的坑

读基本信息是最常用的接口，返回的是一组定长字段。头文件里的定义大概是这个样子：

typedef struct { char name[32]; // 姓名，GBK 编码，定长 32 字节 char sex[4]; // 性别，"男"/"女" char nation[8]; // 民族，如"汉" char birthday[16]; // 出生日期，yyyymmdd char address[128]; // 住址，GBK，可能截断 char idNo[20]; // 公民身份号码，18 位，末位可能是 X char issueOrg[64]; // 签发机关 char validFrom[16]; // 有效期起 char validTo[16]; // 有效期止，"长期" 时为特殊值 } IDCardInfo; int ReadBaseInfo(IDCardInfo* pInfo);

三个地方必须注意。第一，所有char数组都是定长的，SDK 不会给你长度，也不会保证\0结尾。住址字段 128 字节看着够用，但遇到特别长的地址会被截断，而且截断位置可能正好落在 GBK 双字节字符的中间，转码时直接抛异常——所以转码前先做一次长度截断保护。

第二，validTo在长期证件里不是日期。老版本 SDK 会填"长期"或者一串"00000000"，新版本可能填"20501231"。三种情况都要兼容，判断逻辑不能只写一种。

第三，编码。C# 侧的标准写法是这样，关键是显式注册代码页：

using System.Text; // .NET Core / .NET 5+ 默认不带 GBK，必须先注册 Encoding.RegisterProvider(CodePagesEncodingProvider.Instance); static string GbkToString(byte[] buffer) { // 先按 \0 截断，再按 GBK 解码 int len = Array.IndexOf(buffer, (byte)0); if (len < 0) len = buffer.Length; return Encoding.GetEncoding(936).GetString(buffer, 0, len).Trim(); }

Encoding.GetEncoding(936)就是 GBK 的代码页。Array.IndexOf那一行处理的是"数组里可能没有\0"的情况，看起来啰嗦，但省掉它，遇到某些型号读卡器返回的定长缓冲时会读出尾部一串不可见字符，前端展示就变成"张三□□□"。

3.3 照片解码：WLT 到 BMP 的那一步

头像字段返回的不是图片，而是一段几百到一千多字节的压缩数据，格式业内叫 WLT。它不能直接用Bitmap加载，必须调解码库。SDK 里一般有两种入口：一种是把 wlt 数据交给WltDecode.dll的导出函数，另一种是IDCardDll.dll上面直接挂一个GetBmpPhoto。

// 输入：wlt 数据指针 + 长度；输出：bmp 缓冲区 + 实际长度 // nBmpLen 是入参也是出参：调用前填入缓冲区容量，返回后是实际写入长度 int DecodeWltToBmp(const unsigned char* pWlt, int nWltLen, unsigned char* pBmp, int* nBmpLen);

调用时最容易错的是nBmpLen这个双向参数。缓冲区给 64KB 基本够用，解码出来的位图一般在二三十 KB，转成 JPEG 还能再小一半。如果返回的nBmpLen是 0，说明解码失败，原因通常是 wlt 长度传错了——有些示例代码里 wlt 缓冲区是定长的 1024 字节，但实际有效数据只有 800 多字节，你把 1024 传进去，解码器就会在尾部垃圾数据上失败。

3.4 把调用链封成一个方法：C# 侧的完整读卡示例

把前面几步串起来，一个能直接放进项目的读卡方法大概是这样：

[DllImport("IDCardDll.dll", CharSet = CharSet.Ansi, CallingConvention = CallingConvention.StdCall)] private static extern int OpenDevice(int nPort); [DllImport("IDCardDll.dll", CallingConvention = CallingConvention.StdCall)] private static extern int FindCard(); [DllImport("IDCardDll.dll", CallingConvention = CallingConvention.StdCall)] private static extern int ReadBaseInfo(ref IDCardInfo info); [DllImport("IDCardDll.dll", CallingConvention = CallingConvention.StdCall)] private static extern int CloseDevice(); private static readonly object _lock = new object(); // SDK 非线程安全，必须串行 public static IDCardInfo? ReadOnce(int port = 1) { lock (_lock) // 多线程下不加锁必崩 { if (OpenDevice(port) != 0) return null; // 打开失败直接返回 try { if (FindCard() != 0) return null; // 没卡 var info = new IDCardInfo(); if (ReadBaseInfo(ref info) != 0) return null; return info; } finally { CloseDevice(); // 必须关，否则下次打开失败 } } }

lock那一行是这段代码里最值钱的部分。这类 SDK 内部普遍维护一份全局状态（串口句柄、当前选中卡号），两个线程同时调FindCard会互相踩状态，现象是偶发的访问冲突或者读到上次的缓存数据。加上锁，并发问题立刻消失，代价只是读卡变成串行——本来一台机器也只有一张卡在读，这个代价可以忽略。

finally里那句CloseDevice同样不能省。不关设备，下次OpenDevice会返回"端口被占用"，程序重启才能恢复。这类问题在开发机上很难复现，因为你会不停地重启调试，但到了客户现场就是"用一会儿就卡死"。

4. 跑通第一个 Demo：环境、驱动与位数的实操顺序

代码写对了跑不起来，几乎都出在环境上。这一章给一个固定的自检顺序，按这个顺序走，能把大部分"环境问题"在前十分钟内排掉，省下大量盲目试错的时间。

4.1 先确认位数：x86 与 x64 不能混

这是最高频的翻车点。SDK 里bin/x86和bin/x64是两套独立的二进制，导出的函数名、结构体布局都可能有细微差别，混用一定出问题。

先查 DLL 本身是几位：

# Visual Studio 开发者命令行里执行 dumpbin /headers bin\x86\IDCardDll.dll | findstr machine # 输出 x86 表示 32 位 # 输出 x64 表示 64 位

再查你的进程是几位。最直接的办法是运行时打印：

// 4 = 32 位进程，8 = 64 位进程 Console.WriteLine($"当前进程位数：{IntPtr.Size * 8} 位");

两个数必须对上。C# 项目里通过 csproj 强制指定，比在 IDE 里点选靠谱得多：

<PropertyGroup> <PlatformTarget>x86</PlatformTarget> <!-- 与 DLL 位数保持一致 --> <Prefer32Bit>false</Prefer32Bit> <!-- 别让运行时偷偷降位 --> </PropertyGroup>

为什么默认建议先锁x86？因为绝大多数存量 SDK 的 x86 版本是主力维护的，x64 版本往往是后补的，更新更慢。如果你的业务没有超过 4GB 内存的需求，锁 x86 能规避掉一大堆坑。真要上 x64，先在测试机上把五个接口全跑一遍再动生产。

4.2 驱动与设备自检：用官方测试工具先验硬件

装驱动这一步没什么技巧，但顺序有讲究：先装驱动、再插设备。反过来的话，系统可能给它装上一个通用的串口驱动，设备管理器里能看到 COM 口，程序却打不开。

插上之后打开设备管理器，看两件事：端口列表里有没有新增的 COM 口（USB 转串口方案的设备会出现在这里），通用串行总线设备里有没有未识别的项。如果有黄色感叹号，说明驱动没装对，右键更新驱动，手动指向driver/目录。

确认设备被识别之后，立刻跑tools/里的读卡测试工具。这个工具能把五步流程全走一遍，并且显示原始返回码。测试通过说明硬件链路完全没问题；测试不通过，看工具报的错误码，对照doc/里的错误码表，基本能定位到是 SAM 卡问题还是设备通信问题。

注意：测试工具里有个"读安全模块序列号"的功能，先点它。能读出序列号，说明 SAM 卡在位且被识别，这一步比直接读卡更能快速排除硬件问题。

4.3 编译第一个可执行程序：从 demo 到最小可运行集

demo 目录里一般每个语言有一到两个工程。第一次跑，不要直接改 demo 做业务，而是先原封不动编译一次，确认它能跑通。跑通之后再复制一份出来改，这样出问题时你能确定是环境问题还是自己的改动问题。

最小可运行集的构成其实只有四项：可执行文件、IDCardDll.dll、WltDecode.dll、Comm.dll。四个东西放在同一个目录下，不要分散到 system 目录或者别的路径。很多人习惯把公共 DLL 丢到系统目录，结果机器上装了别的同类产品，DLL 被覆盖成另一个版本，导出函数对不上，报"找不到入口点"。这类问题查起来极其痛苦，因为你的代码一行没改。

如果确实需要放到别的路径，用SetDllDirectory显式指定搜索目录，别依赖默认搜索顺序：

[DllImport("kernel32.dll", CharSet = CharSet.Unicode, SetLastError = true)] private static extern bool SetDllDirectory(string lpPathName); // 启动时第一件事：把 DLL 目录钉死 SetDllDirectory(Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "native"));

4.4 跨语言接入：Java 与 Delphi 的两处额外动作

Java 侧走 JNA 的话，结构体不能用普通 POJO 直接映射，必须按字节数组对齐，否则字段全部错位。稳妥的做法是在 Java 里先声明一个Structure，把每个字段按byte[]定义，长度和头文件完全一致，再写转换方法。JNI 方案则要自己写一层 C 包装，好处是性能好、可以复用到 Android。

Delphi 侧的关键是调用约定。声明的时候必须写stdcall：

function OpenDevice(nPort: Integer): Integer; stdcall; external 'IDCardDll.dll' name 'OpenDevice';

漏掉stdcall，编译器会按register约定传参，调用瞬间栈就乱了，程序直接退出，连异常都没有。这是 Delphi 接这类 SDK 最常见的第一个坑。

VB6 侧的问题在字符串。Declare声明时把ByVal和ByRef搞混，或者用String而不是定长String * N接返回值，读出来就是空。这类老项目现在不多，但存量系统里还有，遇到就照 demo 抄，别自己发挥。

5. 避坑与排查：五条踩过的坑

下面这五条都是我在实际项目里撞过的，每一条都按"现象 → 原因 → 解决"写清楚，遇到类似症状可以直接对照。

5.1 寻卡一直失败，但测试工具能读

现象：自己的程序调FindCard永远返回非 0，同一个读卡器用官方测试工具却能正常读出信息。

原因：九成是 DLL 加载错了版本。输出目录里同时存在 x86 和 x64 两份同名 DLL（比如从别的项目复制过来没清理），进程按搜索顺序加载了不匹配的那份。函数地址能解析到，但内部状态初始化失败，于是寻卡恒失败。

解决：清空输出目录，只保留与进程位数一致的一套 DLL。再用Process Explorer之类的工具看一下进程实际加载的 DLL 路径，确认加载的是你期望的那一份。顺手在启动时加一句位数校验，位数不匹配直接弹提示退出，别让它跑起来再说。

5.2 姓名正常，住址是乱码

现象：读出来的姓名没问题，住址字段尾部一串方块或者问号，偶尔还会抛编码异常。

原因：住址比姓名长得多，被截断在 GBK 双字节字符的中间。GBK 每个汉字两个字节，128 字节的缓冲区如果正好在第 127 字节处截断，最后那个字节就是个孤立的半字符，解码器处理不了。

解决：解码前先做长度保护，遇到长度为奇数的缓冲区，丢掉最后一个字节再解：

int len = Array.IndexOf(buffer, (byte)0); if (len < 0) len = buffer.Length; if (len % 2 != 0) len--; // GBK 双字节，奇长度必然有半字符 string addr = Encoding.GetEncoding(936).GetString(buffer, 0, len).Trim();

同时确认一下你的目标框架。.NET Framework 下Encoding.Default恰好是 GBK，迁到 .NET 6 之后变成 UTF-8，代码不改就全乱。这种"升级框架导致老功能坏掉"的问题，排查方向很容易跑偏到 SDK 上。

5.3 照片解码返回空，文本信息却完全正常

现象：ReadBaseInfo一切正常，调DecodeWltToBmp返回失败，或者返回成功但输出长度是 0。

原因：三个可能，按概率排。第一，DecodeWlt.dll没被找到——它在bin目录下，但你的程序工作目录不是那里，LoadLibrary按当前目录找，找不到就静默失败。第二，wlt 长度传的是缓冲区容量而不是实际数据长度。第三，调用DecodeWltToBmp之前没调ReadBaseInfo，wlt 数据区还是空的。

解决：先把WltDecode.dll复制到可执行文件同目录，或者用绝对路径加载。然后把ReadBaseInfo返回的实际 wlt 长度打印出来，和你在代码里传进去的值对比。这个排查方法很土，但几乎每次都能一眼看出问题。

5.4 用一会儿就卡死，重启程序才恢复

现象：程序启动后能正常读卡，连续读几十次之后突然全部失败，重启程序又好了。

原因：句柄或设备通道没释放。OpenDevice成功之后没有对应的CloseDevice，串口句柄一直占着，读到一定次数后系统资源耗尽。另一种情况是读卡器被拔插过，原来的句柄已经失效，但程序还在用旧句柄发指令。

解决：把OpenDevice和CloseDevice严格配对，用try/finally保证异常路径也走到关闭逻辑。对于拔插场景，在每次读卡前检查一次设备是否还在（读安全模块序列号是最轻量的探测方式），失效就重新打开。这一条看起来是防御性编程，实际上省掉的是客户现场"每天重启一次"的投诉。

5.5 多线程并发调用直接崩

现象：单线程测试一切正常，接入 Web 服务之后，并发一上来就崩溃或者读到别人的数据。

原因：这类 SDK 内部是全局状态，不支持并发调用。两个线程同时进入FindCard，一个刚选中卡，另一个又发了寻卡指令，状态机直接错乱。

解决：在 SDK 外面套一层锁，所有调用串行化。如果并发压力确实大（比如多台读卡器接同一台主机），不要靠加锁解决，改成"一台设备一个工作线程 + 任务队列"的模型，每个线程独占一个设备句柄，线程之间不共享 SDK 状态。这个改造在后面一章还会展开。

6. 二次开发：把读卡器变成一层 HTTP 服务

业务系统现在很少有纯桌面端了，读卡器插在客户端的机器上，业务逻辑却在服务端，中间怎么接？我一般不在浏览器里直接调 DLL（ActiveX 那条路已经走不通了），而是在客户端机器上跑一个极小的本地服务，把读卡封装成 HTTP 接口，业务页面通过http://127.0.0.1:端口/read拿 JSON。这样前端技术栈随便换，读卡逻辑一行不用动。

结构上就三块：一个常驻线程做设备轮询，一个任务队列接收请求，一个极简的 HTTP 监听把结果吐回去。核心是让设备线程独占 SDK，其他线程只碰队列。

// 设备线程：独占 SDK，循环从队列取任务 private static readonly BlockingCollection<TaskCompletionSource<IdCardDto>> _queue = new(); private static void DeviceLoop() { while (true) { var job = _queue.Take(); // 没有任务就阻塞，不占 CPU try { job.SetResult(ReadOnce()); } // ReadOnce 就是第 3 章那个方法 catch (Exception ex) { job.SetException(ex); } } }

BlockingCollection的好处是天然串行，队列里永远只有一个任务在跑，SDK 的全局状态不会被并发踩到。业务侧只管_queue.Add(...)然后 await 结果，完全不用关心底层是串口还是 HID。这个模式我在三个项目里用过，稳定性和调试友好度都远超直接在lock里死等。

再往上可以做两层优化。第一层是设备发现：启动时把所有 COM 口扫一遍，逐个尝试OpenDevice，哪个成功就把端口号记进配置，避免每台机器手动填端口。第二层是照片缓存：同一张身份证在短时间内可能被重复读取（比如用户反复放卡），按身份证号做一次短时效缓存，能显著减少解码次数，也顺带解决了用户"手抖放两次"造成的重复请求。

验证方法很简单：写一个压测脚本，十个线程并发请求 200 次，看成功率是不是 100%、内存有没有缓慢上涨。内存涨说明句柄没释放，成功率不到 100% 说明还有共享状态没隔离干净。这两个指标过了，基本可以交付。

最后说个习惯。从那以后我每次接这类 SDK，第一步都不是写代码，而是先把tools/里的测试工具跑通、把dumpbin的位数对一遍，再动手建工程。前面省下的那十分钟，后面往往要用一整天来还。希望帮到你。

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