根本原因是GCM模式强制验证认证标签（auth_tag），漏存或未传入16字节tag会导致解密失败、乱码或authentication failed；加密输出必须包含ciphertext+auth_tag+iv三部分，推荐iv开头、tag结尾、中间密文，并用std::vector<uint8_t>存储二进制数据。
用 AES-256-GCM 加密文件时，为什么加密后读不出原文？
常见现象是解密后得到乱码、空数据或 std::runtime_error: authentication failed。根本原因不是密钥错了，而是 GCM 模式强制要求验证标签（authentication tag）——它必须和密文一起保存，并在解密时原样传入。很多新手只写入密文，漏掉 16 字节的 tag。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 加密输出必须包含三部分：
ciphertext+auth_tag+iv（顺序可自定，但需固定） - 推荐把
iv（12 字节）放在开头，auth_tag（16 字节）放在末尾，中间是密文，这样解密时可直接切片 - 别用
std::string存二进制数据；用std::vector<uint8_t>或裸uint8_t*，避免 '\0' 截断 - OpenSSL 的
EVP_EncryptFinal_ex可能输出额外填充字节，但 GCM 模式下实际无填充，所以EVP_EncryptUpdate已输出全部密文
std::filesystem::copy_file 覆盖原文件前，如何确保加密已成功写入磁盘？
直接覆盖风险极高：若加密中途崩溃或写入未刷盘，原文件就永久丢失。不能依赖 std::ofstream::close()，它不保证落盘。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 先将加密结果写入临时文件，如
myfile.dat.encrypted.tmp - 调用
fflush()+fsync()（Linux/macOS）或FlushFileBuffers()（Windows）确保数据写入磁盘 - 再用
std::filesystem::rename()原子替换原文件（POSIX 保证 rename 是原子的） - 最后删除旧备份（如有），不要用
copy_file(..., copy_options::overwrite)直接覆盖
密钥从哪来？硬编码、环境变量还是用户口令派生？
硬编码密钥等于没加密；环境变量在 ps/top 中可见；口令派生是唯一合理选择，但容易错用 std::hash 或简单迭代。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
PKCS5_PBKDF2_HMAC（OpenSSL）或crypto::pbkdf2_hmac（libsodium），迭代次数 ≥ 1000000 - 盐值（salt）必须随机生成、长度 ≥ 16 字节，并和加密文件一起存储（例如放在 IV 前面）
- 别自己实现口令哈希逻辑；更别用
std::md5（不存在）或std::sha256（C++23 才有且不带 salt） - 如果项目允许依赖，优先选 libsodium：它的
crypto_secretstreamAPI 封装了 AEAD + 密钥派生 + 流式加密，出错率低得多
为什么小文件（
不是 bug，是 GCM 模式和文件头设计共同导致的。AES 块大小是 16 字节，但 GCM 不需要填充；真正膨胀的是你加进去的元数据。
典型结构（示例）：
12 bytes IV 16 bytes salt 16 bytes auth_tag + ciphertext (≈ original size) = 至少 +44 bytes
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 对极小文件（如配置 JSON），考虑改用
ChaCha20-Poly1305（同样 AEAD，但 IV 更短，可压到 8 字节） - 如果必须压缩后再加密，注意：先压缩再加密 —— 反过来会因加密消除冗余而使压缩失效
- 不要为省几字节去掉 salt 或 auth_tag；安全边界一旦妥协，整个加密形同虚设
最易被忽略的一点：没有校验解密后的文件完整性（比如解密出错却静默返回空内容）。应在解密函数末尾 assert tag 验证成功，并对返回的明文做长度合理性检查（如比原始文件大 10 倍就报错）。
