evp_verifyfinal返回0的根本原因是签名前未使用与签名时完全一致的摘要算法和填充方式；例如服务端用sha256 with rsa-pkcs1-v1_5签名，客户端却用evp_sha1()初始化上下文，必然失败。
用 OpenSSL 的 EVP_VerifyFinal 校验 RSA 签名时为何总返回 0？
根本原因是签名前未使用与签名时完全一致的摘要算法和填充方式。比如服务端用 SHA256 with RSA-PKCS1-v1_5 签名，而客户端调用 EVP_VerifyFinal 前却用 EVP_sha1() 初始化上下文，必然失败。
实操要点：
- 必须用
EVP_get_digestbyname("sha256")获取摘要方法，且与签名方严格一致 - 公钥加载必须成功：检查
PEM_read_bio_PUBKEY返回值，空指针会导致后续全盘静默失败 -
EVP_VerifyInit_ex的第三个参数（engine）传nullptr即可，非必要不指定 - 签名数据是 DER 编码的 ASN.1 结构（不是原始哈希值），需原样传入
EVP_VerifyUpdate后的EVP_VerifyFinal
如何从 PEM 文件安全加载公钥并避免内存泄漏？
直接用 PEM_read_bio_PUBKEY 是标准做法，但容易忽略 BIO 的生命周期和错误分支的清理。
关键细节：
- 用
BIO_new_mem_buf创建 BIO，传入 const char* 指针和长度，**不要传入以 \0 结尾的字符串长度**（否则会截断末尾换行） - 校验返回的
EVP_PKEY*是否为nullptr，若为空，ERR_print_errors_fp(stderr)能立刻看到 "no start line" 或 "bad base64 decode" - 必须配对调用
BIO_free和EVP_PKEY_free，漏掉任一都会导致内存泄漏 - 公钥格式必须是
-----BEGIN PUBLIC KEY-----（PKIX），不是-----BEGIN RSA PUBLIC KEY-----（PKCS#1），后者需用PEM_read_bio_RSAPublicKey+EVP_PKEY_assign_RSA
下载文件后怎么算 SHA256 并喂给 OpenSSL 验证流程？
不能把整个文件读进内存再哈希——大文件（如 500MB 安装包）会 OOM。得流式计算。
推荐做法：
- 打开文件用
std::ifstream以std::ios::binary模式，分 8KB 缓冲区循环读取 - 每次读到数据后调用
EVP_DigestUpdate(&md_ctx, buf, len)，别忘了检查返回值是否为 1 - 最终调用
EVP_DigestFinal_ex(&md_ctx, digest, &digest_len)得到 32 字节digest - 注意：这个
digest是中间结果，**不能直接当签名用**；验证时仍要把原始文件内容喂给EVP_VerifyUpdate，签名值单独传给EVP_VerifyFinal
为什么用 openssl dgst -verify 命令能过，C++ 代码却失败？
最常见的是签名文件被文本编辑器“悄悄”转了换行符。比如 Windows 记事本保存的 .sig 文件末尾多了 \r\n，导致 Base64 解码失败，signature_len 比预期少 1 字节——EVP_VerifyFinal 就直接返回 0，不报具体原因。
排查建议：
- 用
xxd -p signature.bin | tr -d '\n'看原始十六进制，确认长度是否为 256（RSA-2048）或 512（RSA-4096） - 签名文件必须是纯 Base64（无空格、无换行、无 BOM），可用
base64 -d sig.b64 > sig.bin验证能否无错解码 - C++ 中用
BIO_new_mem_buf加载签名时，传入的长度必须是解码后二进制长度，不是 Base64 字符串长度 - 如果服务端用
openssl pkeyutl -sign生成签名，客户端必须用EVP_PKEY_CTX_set_rsa_padding显式设为RSA_PKCS1_PSS_PADDING或RSA_PKCS1_PADDING，否则默认行为不一致
验证逻辑本身不复杂，但每个环节都卡在“看似正常实则错一位”的细节上——尤其是 Base64 解码长度、摘要算法匹配、公钥格式类型这三点，漏查一个就白忙半小时。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
