大文件加密不能一次性加载是因为内存不足，必须用evp_encryptupdate分块处理，并仅在eof后调用evp_encryptfinal_ex补pkcs#7填充；块大小建议16kb–64kb，iv需写入密文开头，解密时须严格匹配iv、填充和密钥派生参数。
大文件加密为什么不能直接用 EVP_EncryptInit_ex 一次性加载？
因为内存扛不住。OpenSSL 的 EVP_EncryptInit_ex、EVP_EncryptUpdate 本身支持流式处理，但很多人误以为必须把整个文件读进内存再加密——结果 2GB 文件直接 OOM。真正的问题不在 API 不支持，而在没按块（chunk）调用 EVP_EncryptUpdate，且忽略了 padding 和 final 处理的边界条件。
- 明文长度不是 16 字节整数倍时，
EVP_EncryptFinal_ex才补 PKCS#7 padding；若手动分块却在最后一块调用了EVP_EncryptFinal_ex，会导致重复 padding 或解密失败 - 块大小建议设为 16KB–64KB（即 16384–65536 字节），太小增加 syscall 开销，太大无益于内存控制
- 必须确保每次
EVP_EncryptUpdate的输出缓冲区足够大：输出长度 ≤ 输入长度 + 16（AES-CBC 最大 padding）
如何正确用 AES-256-CBC 流式加密文件？
核心是循环读取、加密、写入三步闭环，且只在 EOF 后调一次 EVP_EncryptFinal_ex。别碰 EVP_CIPHER_CTX_set_padding —— 默认开启 PKCS#7，关了反而要自己算 padding。
- 初始化时用
EVP_EncryptInit_ex(ctx, EVP_aes_256_cbc(), nullptr, key, iv)，key 和 iv 必须是 32 字节和 16 字节，不能靠字符串字面量硬编码（易截断） - 每次
fread(buf, 1, chunk_size, in_fp)后，用EVP_EncryptUpdate(ctx, out_buf, &out_len, buf, read_len)加密，out_len是实际写出字节数 - 仅当
fread返回 0（即 EOF）且read_len == 0时，才调EVP_EncryptFinal_ex(ctx, out_buf + out_len, &final_len)补 padding - 记得把 IV 写在密文开头（16 字节），解密端才能读取——这是常见遗漏点
EVP_EncryptFinal_ex 返回 0 的常见原因
不是算法错，几乎全是上下文状态或内存问题。最常踩的坑是：在非 EOF 时调了它，或者输出缓冲区不够大。
- 缓冲区空间不足：比如传入 16 字节缓冲区，但
EVP_EncryptFinal_ex需要最多 16 字节 padding，导致写越界返回 0 - 提前调用：某次
EVP_EncryptUpdate刚好把输入凑成整块（如 65536 字节），有人误以为“已对齐”就调 final，结果后续还有数据，解密时会多出一整块乱码 - ctx 被复用但没重置：同一个
EVP_CIPHER_CTX*用于多个文件，忘了调EVP_EncryptInit_ex重置状态，内部计数器错乱
解密端必须严格匹配的三个细节
加密看着跑通，解密失败十有八九栽在这三点上。
- IV 必须从密文前 16 字节读取，而不是用加密时的原始 IV 变量——文件落地后字节序/对齐可能变化
- 解密时同样要流式调用
EVP_DecryptUpdate，但EVP_DecryptFinal_ex才负责去掉 padding；如果密文末尾被截断（如网络传输丢包），它会返回 0 并清空输出缓冲区 - 密钥派生方式必须一致：如果加密时用
EVP_BytesToKey从 password 生成 key/iv，解密时也得用完全相同的 salt、迭代次数和 digest（如EVP_sha256()），差一个参数就全错
流式加解密的麻烦不在代码行数，而在边界判断稍有偏差就会导致整个文件无法还原。尤其注意最后一次 fread 返回值和 EVP_EncryptFinal_ex 的触发时机——这里没有“差不多”，只有字节级精确。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
