AES_cbc_encrypt解密常出乱码，因IV被原地修改、无填充处理且输入校验缺失；应改用EVP_DecryptInit_ex系列，其自动管理IV复制、PKCS#7填充、密钥调度及错误检查，确保跨语言稳定互操作。
直接用 AES_cbc_encrypt 做解密，大概率会得到乱码或解密失败——不是算法错了，而是 IV 被函数内部改写了，且填充没对齐、密钥长度没配对、API 层级选错。真正能稳定跨语言互操作的解法，是放弃低级 API，改用 EVP_DecryptInit_ex 系列。
为什么 AES_cbc_encrypt 解密常出乱码
这个函数在 CBC 模式下会原地修改传入的 ivec 参数：执行一次加密后，ivec 变成最后一个密文块；执行一次解密后，ivec 又变成倒数第二个密文块。如果你复用同一个 iv 数组做多次加解密，或者没在调用前重置它，解密输出就会错位。
更隐蔽的问题是：它不处理填充。你必须自己实现 PKCS#7 填充并确保解密后正确截掉——而不同语言对“填充字节是否允许全 0”“末尾是否可能被截断”等细节判断逻辑不一致，导致 Python 或 Java 解出来正常，C++ 却开头多几个乱码字节。
-
AES_cbc_encrypt是纯算法块函数，不封装模式逻辑、不校验输入、不管理内存 - 它要求明文/密文长度严格为 16 字节倍数，但真实数据几乎从不满足
- IV 必须和加密时完全一致（包括字节顺序、是否含 BOM），且不能被其他函数污染
EVP_DecryptInit_ex 解密的最小可靠流程
OpenSSL 的 EVP 接口把填充、IV 复制、密钥调度、错误检查全包进去了，只要参数填对，基本不会因底层细节翻车。关键三步：
立即学习“C++免费学习笔记（深入）”；
- 调用
EVP_DecryptInit_ex(ctx, EVP_aes_256_cbc(), nullptr, key, iv)初始化上下文，key和iv必须是 32 字节和 16 字节原始字节数组（不是字符串） - 用
EVP_DecryptUpdate处理密文主体，输出缓冲区要预留len + AES_BLOCK_SIZE空间 - 必须调用
EVP_DecryptFinal_ex—— 它负责去掉 PKCS#7 填充并返回真实明文长度；漏掉这步，输出里就带着填充字节
示例片段（省略错误检查，仅示意主干）：
EVP_CIPHER_CTX* ctx = EVP_CIPHER_CTX_new(); EVP_DecryptInit_ex(ctx, EVP_aes_256_cbc(), nullptr, key, iv); int len; EVP_DecryptUpdate(ctx, plaintext, &len, ciphertext, ciphertext_len); int final_len; EVP_DecryptFinal_ex(ctx, plaintext + len, &final_len); // 真实明文长度 = len + final_len
密钥、IV 和密文格式的硬性约束
很多解密失败根本不是代码问题，而是数据格式没对齐：
-
key长度必须匹配算法：AES-256 要 32 字节，不能传 32 字符的字符串（含 '\0' 就只剩 31 字节） -
iv必须恰好 16 字节；如果从 Base64 解码来，确认解码后长度是 16，不是 17（常见于结尾换行或空格） - 密文如果是 Base64 编码，必须完整解码后再喂给 EVP；不能把 Base64 字符串直接当二进制传
- 加密端若用了 AES-128-CBC，解密端就不能用
EVP_aes_256_cbc()，否则EVP_DecryptInit_ex返回 0 且不报具体原因
最容易被忽略的初始化与清理动作
OpenSSL 的 EVP 上下文不是一次性对象。每次解密前必须调用 EVP_DecryptInit_ex（不能只调一次然后反复用），否则残留状态会导致后续解密错乱。同样，EVP_CIPHER_CTX_free 必须调用，否则内存泄漏不说，在 Windows 下还可能引发 DLL 卸载异常。
另外，OpenSSL 3.0+ 默认禁用 legacy 算法，如果密钥是用旧版 OpenSSL 生成的（比如通过 openssl enc -aes-256-cbc 命令），可能需要显式调用 OSSL_PROVIDER_load(nullptr, "legacy") 才能加载对应 provider。
