解密文件必须严格匹配加密时的算法、密钥和模式，否则易得乱码或崩溃；需确认原始加密逻辑，注意IV、填充方式、二进制读写、密钥管理及数据完整性校验。
解密文件内容必须和加密时用同一算法、同一密钥、同一模式，否则大概率得到乱码或崩溃
解密前必须确认加密方式
直接调用 decrypt() 函数却没搞清原始加密逻辑，是新手最常踩的坑。比如：
- 用
XOR加密的文件，不能拿AES的解密函数去处理 - 用替换表（如码本
"qwertyuiopasdfghjklzxcvbnm"）加密的文本，解密必须逆向查表，不是简单异或 - DES/AES 类算法依赖
IV（初始化向量），如果加密时没保存或硬编码了 IV，解密就会失败
建议先检查原始加密代码里调用了哪个函数、传了什么参数，尤其注意 encrypt() 和 decrypt() 是否成对设计——很多示例代码里两个函数共用同一套置换逻辑，只是方向相反。
二进制读写必须开启 std::ios::binary
用 std::ifstream 读加密文件时漏掉 binary 模式，会导致 Windows 下遇到 \r\n 被悄悄转成 \n，解密后数据错位。常见错误写法：std::ifstream in("cipher.bin")；正确写法：std::ifstream in("cipher.bin", std::ios::binary)。
立即学习“C++免费学习笔记（深入）”；
- 输出文件同样要用
std::ofstream out("plain.txt", std::ios::binary) - 缓冲区读取推荐固定大小（如
char buf[4096]），避免一次性加载大文件导致内存溢出 - 务必检查
in.gcount()返回的实际读取字节数，而不是盲目假设读满缓冲区
密钥和状态不能硬编码在代码里
很多教学代码把密钥写死在 decrypt() 函数里，比如 const char key[] = "mysecret123"，这既不安全也不灵活。实际使用时：
- 密钥应从外部输入（命令行参数、环境变量或用户交互），避免泄露到二进制或日志中
- 若加密时用了盐值（salt）或 KDF 衍生密钥，解密时必须复用相同的 salt 和迭代次数
- DES/AES 等算法的子密钥生成过程不可逆，
generateSubKeys()必须用和加密时完全相同的原始密钥重新执行一遍
解密后要验证数据完整性
解密成功不等于结果正确。常见现象：解密函数没报错，但输出文件打不开或显示乱码。原因可能是：
- 密钥错一位、IV 长度不对、填充方式（PKCS#7 vs ZeroPadding）不匹配
- 加密时用了 Base64 编码再存文件，解密前忘了先
base64_decode() - 文件末尾有额外字节（比如日志写入污染了加密流）
最轻量的验证方式：对已知明文（如开头几个字节）做哈希比对；更稳妥的做法是在加密时附带 HMAC，解密后校验签名。
真正麻烦的从来不是写 decrypt() 函数，而是确认“当初是怎么加密的”。加密逻辑一旦模糊，解密就变成猜谜——尤其是跨团队、跨时间维护的项目，文档缺失时，往往得靠逆向分析密文特征来反推算法。
