大文件加密必须流式分块处理以避免OOM和系统卡顿；需确保分块大小为加密块长整数倍、正确填充与去填充、用gcount()校验读取字节数、分离I/O与计算并用环形缓冲区异步处理、每块独立nonce及完整性校验。
大文件加密为什么不能一次性读入内存
因为会触发 OOM（std::bad_alloc）或严重拖慢系统响应。1GB 文件在 32 位进程里根本无法 new 出足够缓冲区；64 位下虽能分配，但阻塞主线程、占用大量物理内存，影响其他任务。流式分块是唯一可行路径——每次只处理几 MB，边读边加/解密，再写入目标文件。
std::ifstream + std::ofstream 如何安全分块读写
关键不是“怎么读”，而是“怎么避免边界截断破坏加密块完整性”。AES-CBC 等模式要求数据长度是块大小（如 16 字节）整数倍；GCM 则需完整 AAD 和 nonce 配合。常见错误是直接用 read(buf, 4096) 导致最后一块不足 16 字节，加密失败或解密校验失败。
- 固定分块大小必须是加密算法块长的整数倍（如 AES-128：16 字节 → 推荐 65536 字节即 4096×16）
- 最后一块需填充（PKCS#7），且填充信息必须随加密数据一同持久化（否则解密端无法去填充）
- 使用
std::ifstream::gcount()获取真实读取字节数，而非假设每次都满块 - 务必检查
rdstate()，区分eofbit和failbit—— 后者意味着读取异常（如磁盘 I/O 错误），不能继续加密
如何用 std::async 实现真正异步加解密而不阻塞 I/O
很多人以为把 encrypt_chunk() 丢进 std::async 就算异步，结果发现文件读写仍卡住。问题在于：I/O 本身是同步阻塞的，std::async 只并发了 CPU 密集部分，没解决读/写瓶颈。正确做法是分离三阶段：读 → 加密/解密 → 写，并用环形缓冲区衔接。
- 用两个
std::vector<uint8_t></uint8_t>缓冲区（A/B），一个被线程池加密时，另一个由主线程继续读文件 - 加密任务返回
std::future<:vector>></:vector>，写线程等待其就绪后落盘，避免竞争 - 不要对每个块都调用
std::async：开销太大。改用固定大小线程池（如boost::asio::thread_pool或 C++20std::jthread+ 任务队列） - nonce 必须每块唯一且可复现：推荐用初始随机 nonce + 块序号派生（如
HMAC-SHA256(nonce, "chunk_" + std::to_string(i))），解密时按序还原
解密时如何验证完整性并安全报错
单纯解密失败（如 GCM tag 校验不通过）不能只抛 std::runtime_error，必须明确区分：是密钥错误？文件被篡改？还是传输损坏？否则用户无法判断该重试还是换密钥。
立即学习“C++免费学习笔记（深入）”；
- 在加密端，将原始文件 SHA-256 写入末尾 32 字节（加密前计算，加密后追加），解密后重新计算已解密数据哈希并比对
- GCM 模式下，解密函数（如 OpenSSL 的
EVP_DecryptFinal_ex）返回 0 表示 tag 不匹配，此时应返回特定错误码（如-1），而非让程序崩溃 - 不要用明文路径或文件名生成 IV —— 这会让相同文件产生相同密文，泄露文件重复性
- 如果解密中途出错，已写入的目标文件必须立即
unlink()，防止残留半成品
最易被忽略的是块间状态隔离：每个加密块的 nonce、tag、填充逻辑必须完全独立，不能复用上一块的上下文。哪怕只差一个字节，也会导致整个文件无法恢复。
