OpenSSL加载PEM私钥失败主因是密钥加密未传密码或格式非标准PKCS#8，应优先用PEM_read_bio_PKCS8_PRIV_KEY_INFO并校验BIO位置、BOM及PEM边界；公钥需EVP_PKEY_get1_RSA提取RSA结构；Windows中文路径须转UTF-8后用BIO_new_mem_buf。
OpenSSL加载PEM私钥时提示PEM_read_bio_PrivateKey返回NULL
多数情况下不是文件路径错，而是密钥被加密（带DEK-Info头）但没传密码，或格式根本不是标准PEM——比如开头是-----BEGIN RSA PRIVATE KEY-----而非-----BEGIN PRIVATE KEY-----。OpenSSL 1.1.1+默认只认PKCS#8格式，老式PKCS#1需显式指定类型。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 先用
openssl pkcs8 -in key.pem -text -noout确认格式；若报错unable to load Private Key，大概率是密码保护或格式不兼容 - 加载时优先用
PEM_read_bio_PKCS8_PRIV_KEY_INFO，它能自动识别PKCS#8和部分PKCS#1；失败后再 fallback 到PEM_read_bio_RSAPrivateKey - 密码回调函数必须返回
int且不能为负值；常见错误是回调里直接return 0（表示取消），应返回密码长度
C++中用BIO_new_file读取PEM后立即调用PEM_read_bio_*失败
典型现象：BIO*创建成功，但PEM_read_bio_PrivateKey返回nullptr，ERR_get_error()给出PEM routines:PEM_read_bio:no start line。根本原因是BIO未重置读取位置，或文件含BOM/空行干扰。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
BIO_new_mem_buf替代BIO_new_file更可控：先用std::ifstream读完整文件到std::string，再传入BIO_new_mem_buf(data.c_str(), data.size()) - 手动跳过UTF-8 BOM：
if (data.starts_with("\xEF\xBB\xBF")) data.erase(0, 3); - 确保PEM块边界严格：开头必须是
-----BEGIN（注意空格），结尾-----END后必须紧跟换行，末尾不能有多余空格
从PEM加载公钥时PEM_read_bio_PUBKEY解析出EVP_PKEY但无法用于EVP_SealInit
问题不在读取阶段，而在后续使用——EVP_PKEY虽包含公钥，但EVP_SealInit要求密钥类型明确为RSA，而PEM_read_bio_PUBKEY返回的可能是泛型结构。直接传入会触发digital envelope routines:EVP_SealInit:wrong public key type。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 加载后强制提取RSA结构：
RSA* rsa = EVP_PKEY_get1_RSA(pkey);，检查返回值是否非空 - 若需通用处理，用
EVP_PKEY_id(pkey)判断类型：if (EVP_PKEY_id(pkey) != EVP_PKEY_RSA)则拒绝 - 注意内存管理：
EVP_PKEY_get1_RSA会增加引用计数，用完需RSA_free(rsa)，否则泄漏
Windows下读取PEM密钥时中文路径导致BIO_new_file失败
BIO_new_file底层调用C标准库fopen，在Windows上不支持UTF-8路径（即使编译器启用了UTF-8源码）。表现为返回nullptr且errno为ENOENT，但文件明明存在。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 绝对不要传宽字符路径给
BIO_new_file；改用std::wifstream读取文件内容，转为UTF-8std::string，再喂给BIO_new_mem_buf - 转换示例：
std::wstring_convert<:codecvt_utf8>> conv; std::string utf8 = conv.to_bytes(wpath);</:codecvt_utf8>（C++11，注意std::wstring_convert已弃用，生产环境建议用WideCharToMultiByte） - Linux/macOS无此问题，但统一用内存加载可避免平台差异
真正麻烦的是密钥密码交互——终端回显控制、信号中断处理、密码缓存策略，这些比文件读取本身更易出错。
