GmSSL Windows版国密集成：SM2/SM3/SM4落地与避坑

简介：面向 Windows 平台国密开发场景的 Gmssl 预编译支撑库，适合具备一定 C/C++ 基础、需要在项目中接入 SM2、SM3、SM4 的开发者与安全实验人员使用。它主要解决源码编译链路较长、依赖配置繁琐的问题，便于在 Windows 环境下直接完成接口对接、算法验证与联调测试。压缩包共 2000 个文件，以 1903 个 HTML 文档和 95 个 .h 头文件为主体，另含少量 txt 说明与 c 源文件，整体约 14.29MB；HTML 适合检索 API 说明与使用背景，头文件覆盖 ssl、evp、ec、x509、asn1、engine 等模块，可支撑证书处理、摘要计算、对称加密及引擎相关开发。已有 257 人学习下载。读者可借此减少从源码构建到工程集成的时间成本，按模块查阅函数原型、类型定义与调用约束，并结合配套文档排查编译链接和接口使用中的常见问题；对于需要对照接口声明与文档说明的读者，也能更直观地理解各模块职责与依赖关系，适合国密功能预研、课程实验或 Windows 加密通信原型开发参考。

1. GmSSL Windows 版到底解决什么问题：从 SM2/SM3/SM4 的落地场景说起

在 Windows 上做国密改造，绕不开 GmSSL 这个支撑库：它把 SM2 签名验签、SM3 摘要、SM4 对称加密收在一套 C 接口和命令行工具里，省去自己拼算法细节。这个 Windows 版资源包的价值不在于“多一个 exe”，而在于让内网文件交换、接口签名、证书链路这些场景能在 MSVC/MinGW 工程里直接落地。适合谁？需要把国密算法接进现有 C/C++ 服务、又不想从零造轮子的开发者；也适合测试同学拿命令行先做向量回归。后面按资源包拆解、SM2/SM3/SM4 最小闭环、Windows 集成避坑和交叉验证四段推进，尽量把参数和翻车点写透。

2. 资源包拆解与 Windows 环境准备：DLL、LIB、头文件和命令行怎么摆

2.1 资源包里通常有哪些文件：目录结构与文件职责

拿到一个 Windows 版 GmSSL 资源包，先别急着写代码，第一步是认目录。常见结构是bin/放命令行工具和运行时 DLL，lib/放导入库，include/gmssl/放头文件，有的包还会带samples/或docs/。目录乱并不可怕，可怕的是把 x86 的 lib 和 x64 的 dll 混在一起，编译能过，运行时直接给你一个“应用程序无法正常启动 0xc000007b”。这类问题不是算法错，是文件摆错。

先列一遍文件，确认路径没有中文和空格带来的干扰。PowerShell 里可以这样看：

# 查看资源包内所有文件与相对路径，先确认 bin/lib/include 是否齐全 Get-ChildItem -Recurse -File | Select-Object @{Name="RelativePath";Expression={$_.FullName.Replace((Get-Location).Path + "\", "")}}, Length | Sort-Object RelativePath

这段命令只做一件事：把资源包的目录结构摊平。Length用来判断 DLL 和 LIB 是不是明显不对，比如导入库只有几百字节，通常不是正常构建产物。路径里如果出现空格，后续cl和gcc命令都要加引号，这是 Windows 下最常见的低级翻车点之一。

2.2 开发环境与运行时依赖：PATH、DLL 搜索顺序和编译工具链

Windows 加载 DLL 的顺序里，exe 所在目录优先级很高，所以最省心的做法是把gmssl.dll复制到你的app.exe旁边，而不是依赖PATH。PATH适合开发机临时跑命令，不适合交付。你永远不知道客户机器上哪个目录先命中同名 DLL，这种玄学问题查起来很费时间。发布前用dumpbin /dependents看依赖，比运行时报错再猜要快。

:: 确认工具链和资源包入口是否在 PATH 中 where cl where gcc where gmssl.exe :: 查看 exe 依赖哪些 DLL，重点看是否有 MSVC 运行库和 gmssl.dll dumpbin /dependents bin\gmssl.exe

where cl为空说明当前不是开发者命令提示符，MSVC 编译会找不到头文件。where gcc为空说明 MinGW 没进 PATH。dumpbin需要在 Visual Studio 开发者命令提示符里执行，普通 cmd 里可能找不到。看到gmssl.dll之外还有vcruntime140.dll、msvcp140.dll之类的依赖，交付包里要么带上，要么确认目标机器已安装对应运行库。

MSVC 编译最小示例：

:: /I 指定头文件目录，/LIBPATH 指定导入库目录，最后链接 gmssl.lib cl /nologo /I include demo_sm3.c /link /LIBPATH:lib gmssl.lib

MinGW 编译同一份代码：

# -I 头文件，-L 库目录，-lgmssl 链接导入库，输出 exe gcc -Iinclude demo_sm3.c -Llib -lgmssl -o demo_sm3.exe

参数不复杂，关键是位数一致。cl默认跟当前命令提示符的环境走，x64 开发者提示符编出来就是 x64；MinGW 也要用对应的 x86_64 工具链。32 位程序加载 64 位 DLL 会直接失败，反过来也一样。另一个容易忽略的是 CRT 链接方式：如果资源包是/MD构建，你的工程用/MT，某些情况下能编过但运行期内存管理会出问题。最稳妥的做法是先用资源包自带示例的编译参数跑通，再往业务工程里搬。

2.3 命令行工具先跑通：SM3 摘要与 SM4 加解密的验证顺序

在写 C 代码之前，先用gmssl.exe做冒烟验证。不同构建的参数命名可能有差异，先看帮助，不要照抄网上命令。SM3 用"abc"做已知向量最合适，因为结果固定，能快速判断库有没有被换掉。注意写入文件时不要带换行，否则你算的是abc\r\n，结果对不上还以为是库有问题。

# 先看当前包支持哪些子命令，以及 sm3 子命令的参数 .\bin\gmssl.exe help .\bin\gmssl.exe sm3 -help # 写入无换行的 abc，避免 CRLF 被算进摘要 [System.IO.File]::WriteAllBytes("$PWD\abc.txt", [Text.Encoding]::ASCII.GetBytes("abc")) # 计算 SM3，输出应为 66c7f0f4... 开头的 64 位十六进制 .\bin\gmssl.exe sm3 -in .\abc.txt

help和sm3 -help是必须动作，因为有的包把输入参数叫-in，有的直接跟文件名。SM3 的期望值可以背一半：66c7f0f4 62eeedd9 d1f2d46b dc10e4e2 4167c487 5cf2f7a2 297da02b 8f4ba8e0。如果输出长度不是 64 个十六进制字符，先查是不是把文件路径当成了字符串内容。SM4 的命令行参数差异更大，常见做法是先确认sm4子命令支持-e、-d、-key、-iv中的哪些，再用标准向量验证。命令行只做冒烟，真正集成还是走 C 接口，因为业务里的密钥管理、错误码和缓冲区控制都得自己接管。

提示：命令行工具能跑通，不代表开发库能链接成功；反过来，开发库能编译，也不代表运行时 DLL 找得到。这两件事要分开验证。

3. SM2 密钥、签名与验签：Windows 下的最小可运行闭环

3.1 SM2 密钥对生成与格式转换：私钥、公钥和 PEM/DER 的边界

SM2 在业务里最常见的入口不是加密，而是签名验签：接口参数防篡改、设备身份认证、许可证文件校验。第一步是密钥对。GmSSL 的 C 接口通常围绕SM2_KEY结构体转，生成、导入、导出各有函数。不同构建的函数名可能略有差异，写代码前先翻include/gmssl/sm2.h，以头文件为准。下面这段只做内存密钥生成，目的是确认库能正常初始化随机数和曲线参数。

#include <stdio.h> #include <gmssl/sm2.h> int main(void) { SM2_KEY key; /* 生成 SM2 密钥对，返回 1 表示成功，其他值要查错误栈 */ if (sm2_key_generate(&key) != 1) { fprintf(stderr, "sm2_key_generate failed\n"); return 1; } /* 实际导出函数名以 sm2.h 为准：常见有私钥/公钥 PEM 导出接口 */ printf("SM2 key generated\n"); return 0; }

这段代码的重点不是打印，而是确认sm2_key_generate返回 1。返回 0 或负数时不要继续往下走，先看随机数源是否可用。Windows 下常见问题是进程权限受限或运行库初始化失败，导致随机数拿不到。密钥格式上，PEM 适合配置文件和人眼检查，DER 适合二进制协议，RAW 只适合内部约定。把 RAW 私钥直接写日志是血泪经验里最不该犯的一条。

SM2 公钥常见两种写法：带04前缀的未压缩点，和不带前缀的裸 X||Y。两边不一致时，验签会一直失败，但错误码可能只告诉你“签名错误”。我一般会在导入函数里先判断长度：65 字节按带前缀处理，64 字节按裸点处理，别让上层业务猜。

3.2 签名与验签代码：C 接口调用与错误码检查

签名代码要关注三件事：摘要怎么来、签名缓冲区多大、验签返回值怎么判。下面这段先对消息做 SM3，再对 32 字节摘要调用 SM2 签名，最后用同一把公钥验签。它是最小闭环，不代表所有协议细节都处理了，但足够把编译、链接、运行三关跑通。

#include <stdio.h> #include <string.h> #include <stdint.h> #include <gmssl/sm2.h> #include <gmssl/sm3.h> int main(void) { SM2_KEY key; const char *msg = "order=1001&amount=99.00"; uint8_t dgst[32]; uint8_t sig[SM2_MAX_SIGNATURE_SIZE]; size_t siglen = sizeof(sig); if (sm2_key_generate(&key) != 1) { fprintf(stderr, "keygen failed\n"); return 1; } /* 先做 SM3，得到 32 字节摘要 */ SM3_CTX ctx; sm3_init(&ctx); sm3_update(&ctx, (const uint8_t *)msg, strlen(msg)); sm3_finish(&ctx, dgst); /* 对摘要签名，siglen 入参是缓冲区大小，出参是实际签名长度 */ if (sm2_sign(&key, dgst, sizeof(dgst), sig, &siglen) != 1) { fprintf(stderr, "sm2_sign failed\n"); return 1; } /* 验签返回 1 才算通过，0 或负值都按失败处理 */ if (sm2_verify(&key, dgst, sizeof(dgst), sig, siglen) != 1) { fprintf(stderr, "sm2_verify failed\n"); return 1; } printf("sign/verify ok, siglen=%zu\n", siglen); return 0; }

SM2_MAX_SIGNATURE_SIZE是签名缓冲区上限，不要自己拍一个 64 字节就完事，DER 编码后的长度会变。siglen入参传缓冲区大小，函数返回后变成实际长度；验签时必须用实际长度，不能用sizeof(sig)。sm2_verify返回 1 才是通过，0 和负值都要走失败分支。实际工程里还要把sm2_sign的返回值、siglen范围和错误栈一起打日志，否则线上只看到“验签失败”四个字，排查成本很高。

如果协议要求“先算 Z 值再签名”，这段代码还不够。SM2 标准签名是对e = SM3(Z || M)签名，Z 里包含用户 ID、曲线参数和公钥。有些库的sm2_sign直接对传入摘要签名，有些接口会内部处理 ID。两种用法签出来的结果不互通，联调时最容易在这里翻车。确认方式很简单：让对端用标准向量或同一套 ID 验一次，别只看自己签自己验。

3.3 和常见 TLS 库习惯不同的参数点：ID、摘要模式和随机数来源

SM2 的用户 ID 默认常用1234567812345678，但协议完全可以自定义。签名方用 A 的 ID，验签方用 B 的 ID，数学上都没错， business 上就是验不过。工程里要把 ID 写进配置，不要散落在代码常量里。摘要模式也要统一：是先对原文做 SM3 再签名，还是库内部做 Z 值再签名，两条路径的结果不一样。联调前把这两项写进接口文档，比事后抓包有用。

随机数来源是另一个黑匣子。SM2 签名需要随机数 k，k 的质量直接影响私钥安全。Windows 下常见库会走系统随机源，但如果你在服务启动时 fork 了进程、或者把库塞进特殊宿主环境，随机数初始化可能失败。做法是启动自检：生成一对临时密钥、签一条固定消息、验签通过再放行。不要等第一笔交易来了才发现随机数不可用。

签名输出格式也要确认。常见是 DER 编码的SEQUENCE，里面包含 r 和 s；也有库输出固定 64 字节的 r||s。两者长度不同，验签接口不认就会失败。遇到“签名长度一会 70 多、一会 64”的情况，先查输出编码，不要怀疑算法。把siglen打出来，和协议文档对一遍，通常几分钟就能定位。

4. SM3 与 SM4 的工程化用法：摘要、HMAC、分组模式和填充

4.1 SM3 摘要与 HMAC：输入长度、分段更新和十六进制输出

SM3 本身不难，难在输入边界。文件摘要要分块读，不能一次性ReadAllBytes；协议摘要要确认有没有把换行、空格、字段顺序算进去。分段更新接口就是为这个场景准备的：sm3_init初始化，sm3_update可以调多次，sm3_finish收尾。每次update的长度可以是任意字节，不要求 64 字节对齐，库内部会处理缓冲。

#include <stdio.h> #include <string.h> #include <stdint.h> #include <gmssl/sm3.h> int main(void) { const char *msg = "abc"; uint8_t dgst[32]; SM3_CTX ctx; sm3_init(&ctx); /* 分段更新：这里故意拆成两段，验证流式接口 */ sm3_update(&ctx, (const uint8_t *)msg, 1); sm3_update(&ctx, (const uint8_t *)msg + 1, 2); sm3_finish(&ctx, dgst); for (int i = 0; i < 32; i++) { printf("%02x", dgst[i]); } printf("\n"); return 0; }

这段代码的输出应该是66c7f0f4...开头的 64 位十六进制。拆成两段update是为了验证流式接口没有把上一次的缓冲丢掉。文件摘要时把fread的缓冲区设成 8KB 或 64KB 都行，关键是循环到feof后还要处理最后一次读到的字节数。HMAC-SM3 在协议签名里很常见，库如果自带 HMAC 接口就直接用；没有就按标准 HMAC 结构自己拼，注意 key 超过 64 字节时先做一次 SM3 压缩。

#include <string.h> #include <stdint.h> #include <gmssl/sm3.h> /* 简化版 HMAC-SM3：key 超过 64 字节先哈希，再拼 ipad/opad */ void hmac_sm3(const uint8_t *key, size_t keylen, const uint8_t *data, size_t datalen, uint8_t out[32]) { uint8_t k[64] = {0}; uint8_t ipad[64], opad[64]; uint8_t inner[32]; SM3_CTX ctx; if (keylen > 64) { sm3_init(&ctx); sm3_update(&ctx, key, keylen); sm3_finish(&ctx, k); } else { memcpy(k, key, keylen); } for (int i = 0; i < 64; i++) { ipad[i] = k[i] ^ 0x36; opad[i] = k[i] ^ 0x5c; } sm3_init(&ctx); sm3_update(&ctx, ipad, 64); sm3_update(&ctx, data, datalen); sm3_finish(&ctx, inner); sm3_init(&ctx); sm3_update(&ctx, opad, 64); sm3_update(&ctx, inner, 32); sm3_finish(&ctx, out); }

参数说明：key是共享密钥，data是消息，out是 32 字节结果。keylen > 64的分支不能省，否则长密钥会越界。ipad和opad是固定常量0x36、0x5c，不要写反。这个实现适合协议层自己控制，但生产环境优先用库自带 HMAC，减少侧信道和边界错误。

4.2 SM4 分组模式选择：ECB、CBC、CTR、GCM 的取舍

SM4 是 128 位分组、128 位密钥的分组密码。选模式比选算法更容易出问题。ECB 同一明文块输出同一密文块，适合做已知向量测试，不适合业务数据。CBC 需要 IV，且 IV 要随机、不可预测；CTR 把分组密码变成流模式，不需要填充，但绝不能重复使用同一密钥下的计数器；GCM 带认证，能同时解决机密性和完整性，但 nonce 复用是灾难。下面这张表按工程场景选，不按教科书排。

CBC 加密可以用单块接口自己拼，逻辑清楚，也方便排查。下面这段用sm4_set_encrypt_key和sm4_encrypt做 CBC 链接，输入长度必须是 16 的倍数。生产代码还要加 PKCS#7 填充和 HMAC 校验，这里先看链接逻辑。

#include <string.h> #include <stdint.h> #include <gmssl/sm4.h> static void xor16(uint8_t *r, const uint8_t *a, const uint8_t *b) { for (int i = 0; i < 16; i++) r[i] = a[i] ^ b[i]; } /* 仅演示 CBC 链接：len 必须是 16 的倍数，iv 会被内部复制 */ int sm4_cbc_encrypt_raw(const uint8_t key[16], const uint8_t iv[16], const uint8_t *in, size_t len, uint8_t *out) { SM4_KEY sk; uint8_t prev[16]; uint8_t blk[16]; if (len % 16 != 0) return -1; sm4_set_encrypt_key(&sk, key); memcpy(prev, iv, 16); for (size_t off = 0; off < len; off += 16) { xor16(blk, in + off, prev); sm4_encrypt(&sk, blk, out + off); memcpy(prev, out + off, 16); } return 0; }

key和iv都是 16 字节，len不是 16 的倍数直接返回错误，不要悄悄截断。prev保存上一块密文，第一块用 IV。加密串行是 CBC 的特性，解密可以并行，但这里不展开。实际业务里 IV 要和密文一起存，但 IV 不需要保密；密钥必须单独管理，不能和密文放同一个目录。

4.3 文件加解密与流式处理：缓冲区、padding 和完整性校验

文件加密不要一次性读进内存。做法是固定缓冲区循环读，最后一块做 PKCS#7 填充。填充值等于填充字节数，比如缺 5 字节就补 5 个0x05；如果明文长度正好是 16 的倍数，也要补一整块 16 个0x10。解密后先检查最后一个字节 n 是否在 1 到 16 之间，再检查末尾 n 个字节是否都等于 n，防止填充 oracle。

#include <stdio.h> #include <stdint.h> #include <string.h> #include <gmssl/sm4.h> /* PKCS#7 填充：buf 至少能放下 len + 16 字节 */ size_t pkcs7_pad(uint8_t *buf, size_t len) { size_t pad = 16 - (len % 16); memset(buf + len, (int)pad, pad); return len + pad; } int main(void) { uint8_t key[16] = {0}; uint8_t iv[16] = {0}; uint8_t buf[4096 + 16]; FILE *fin = fopen("plain.bin", "rb"); FILE *fout = fopen("cipher.bin", "wb"); if (!fin || !fout) return 1; SM4_KEY sk; sm4_set_encrypt_key(&sk, key); uint8_t prev[16]; memcpy(prev, iv, 16); size_t n; while ((n = fread(buf, 1, 4096, fin)) > 0) { /* 最后一块要判断是否文件末尾，这里用 feof 简化演示 */ if (n < 4096 && feof(fin)) { n = pkcs7_pad(buf, n); } else if (n % 16 != 0) { /* 非末尾块不是 16 的倍数说明读缓冲设置有问题 */ fclose(fin); fclose(fout); return 2; } for (size_t off = 0; off < n; off += 16) { uint8_t blk[16]; for (int i = 0; i < 16; i++) blk[i] = buf[off + i] ^ prev[i]; sm4_encrypt(&sk, blk, buf + off); memcpy(prev, buf + off, 16); } fwrite(buf, 1, n, fout); } fclose(fin); fclose(fout); return 0; }

这段代码的边界在“最后一块”判断：fread返回小于缓冲区大小不一定到文件末尾，必须结合feof。pkcs7_pad要求缓冲区后面至少留 16 字节，否则越界。key和iv这里全零只是为了演示，生产环境必须用随机密钥和随机 IV。完整性校验建议在密文后追加 HMAC-SM3，解密前先验 HMAC，再解密，避免先解密后验签带来的填充攻击面。

注意：SM4-CBC 只保证机密性，不保证完整性。不要用“解密成功”判断数据没被改过，填充正确也可能是伪造的。

5. Windows 集成避坑：DLL 找不到、ABI 不匹配和字符集翻车

5.1 常见问题排查：从现象到根因的 4 条记录

现象一：开发机跑得好好的，拷到测试机弹“找不到 gmssl.dll”。原因通常不是 DLL 没拷，而是拷错目录或位数不对。Windows 先找 exe 同目录，再找系统目录和 PATH；如果测试机 PATH 里有一个旧版同名 DLL，会先命中旧版。解决方式是把gmssl.dll固定放 exe 同目录，发布前用dumpbin /dependents列出依赖，再用 PowerShell 扫一遍发布目录里每个 DLL 的机器类型。不要靠“我明明复制了”来判断，文件存在和加载成功是两件事。

现象二：编译报一堆LNK2019未解析外部符号。原因常见三种：头文件版本和 lib 不匹配、C++ 工程 include 了 C 头文件但没加extern "C"、链接时库顺序不对。解决时先看头文件里函数声明有没有被#ifdef __cplusplus extern "C" {包住；没有就自己在 include 外层加。再确认gmssl.lib的位数和工具链一致。C++ 工程里把 C 接口单独放一个.c文件编译，比在.cpp里直接 include 更稳。

现象三：SM2 验签一直失败，签名长度每次不一样。原因多半是签名输出编码不一致：一端输出 DER，另一端按 64 字节 r||s 解析；或者用户 ID 不一致，Z 值不同。解决时先把siglen打出来，DER 通常在 70 到 72 字节附近波动，固定 r||s 就是 64 字节。再确认双方 ID 是否都用了约定值。联调阶段可以让对端用同一段摘要做一次“只验签不验业务”的测试，把算法问题和业务问题拆开。

现象四：中文路径下命令行工具读文件失败，换英文路径就好。原因是main拿到的是 ANSI 参数，资源包内部用窄字符 fopen，遇到 GBK/UTF-8 路径就找不到文件。解决方式是在自己的封装层统一转宽字符，用_wfopen打开文件；或者交付前把工作目录限制为英文路径。不要在前端把路径转成 UTF-8 就以为万事大吉，Windows 的窄字符 API 还涉及当前代码页。字符集问题没有玄学，只有“哪一层做了转换、转换有没有失败”。

5.2 发布前自检清单：依赖扫描、路径加固和版本锁定

发布前我会做三件事：依赖扫描、路径加固、版本锁定。依赖扫描看 exe 到底加载哪些 DLL；路径加固看安装目录有没有空格、中文、超长路径；版本锁定是把include、lib、dll的哈希记下来，避免测试环境和生产环境混用不同构建。下面这段 PowerShell 只做依赖和哈希记录，不修改文件。

# 1) 查看主程序依赖，重点确认 gmssl.dll 和运行库 dumpbin /dependents .\release\app.exe # 2) 记录发布目录内 DLL 的 SHA256，便于比对测试机与生产机 Get-ChildItem .\release -Filter *.dll | ForEach-Object { $h = Get-FileHash $_.FullName -Algorithm SHA256 "{0} {1}" -f $h.Hash, $_.Name } # 3) 检查路径中是否含空格或非 ASCII 字符 $p = (Resolve-Path .\release).Path if ($p -match '[^\x00-\x7F]' -or $p -match ' ') { Write-Host "路径含空格或非 ASCII 字符，建议调整" }

dumpbin的输出要和发布目录里的 DLL 对得上，缺哪个补哪个。哈希记录不是形式主义，测试机出现过“同名不同版”的 DLL，最后就是靠哈希对出来的。路径检查也不是矫情，某些旧版运行时对中文路径支持不好，提前把安装目录固定成C:\ProgramData\YourApp\这种纯英文路径，能省掉很多售后问题。

6. 进阶验证与交付技巧：用交叉测试把国密链路钉死

6.1 用已知向量做 SM3/SM4 回归：别只看“能跑”

SM3 用"abc"的固定输出做回归，SM4 用标准 key/plain 的固定密文做单块验证。每次换资源包、换编译参数、换运行库，都先跑这两条。SM4 标准向量里 key 和明文都是0123456789abcdeffedcba9876543210，单块密文是681edf34d206965e86b3e94f536e4246。对不上就先查字节序和十六进制解析，不要直接怀疑算法。

6.2 签名互验与证书链检查：把 SM2 的坑提前暴露

SM2 不要只做“自己签自己验”。让 A 进程生成密钥、B 进程导入公钥验签，能暴露 PEM 解析、公钥前缀、ID 不一致的问题。证书链场景再往前一步：确认证书里的公钥算法、签名算法、曲线参数都能被当前包识别。验签失败时先看siglen和公钥长度，再看 ID，最后看摘要是不是同一段字节。

6.3 交付包瘦身与可复现构建：只留运行时必需文件

交付目录只放app.exe、gmssl.dll、必要的运行库和配置，头文件和 lib 留在开发环境。每次构建记录资源包哈希、编译命令、运行库版本，下次换机器能复现。我吃过一次亏：测试机上的 DLL 是旧构建，签名结果和开发机不一致，查了两天才发现是文件被覆盖。从那以后我每次发版都强制走一遍依赖扫描和哈希比对，不再靠记忆判断。如果你手头正好有这份 Windows 版资源包，先把gmssl.exe help和 SM3 已知向量跑通，再按目录结构对一遍，基本就能判断它适不适合你的工程。希望帮到你。

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