aes加解密时密钥和iv必须严格一致，iv应前置存储于加密文件中，密钥须安全传入；推荐aes-256+cbc+pkcs7，使用cryptostream流式处理避免内存溢出；严禁文本编码写入二进制密文。
AES加密文件内容时，密钥和IV必须一致才能解密
用 AesCryptoServiceProvider 或 Aes.Create() 加密文件时，加密和解密用的密钥（Key）与初始向量（IV）必须完全相同。常见错误是每次加密都新生成随机 IV，但没保存或没传给解密方，导致解密失败并抛出 CryptographicException: The input data is not a complete block 或类似错误。
实操建议：
- 把
IV作为前缀写入加密后文件（例如前16字节），解密时先读取再截取；密钥不建议硬编码，应通过安全方式传入（如环境变量、密钥管理服务） -
KeySize推荐设为256（即32字节），对应 AES-256；若用字符串生成密钥，务必用Rfc2898DeriveBytes（PBKDF2）派生，别直接Encoding.UTF8.GetBytes() - 加密模式固定用
CipherMode.CBC，填充方式用PaddingMode.PKCS7（.NET 默认，兼容性最好）
完整文件加解密要处理流式读写，避免内存溢出
直接 File.ReadAllBytes() 读大文件会把整个文件加载进内存，1GB 文件就占1GB托管堆——不仅慢，还可能触发 OutOfMemoryException。正确做法是用 CryptoStream 套接 FileStream，边读边加/解密。
示例关键逻辑（加密）：
using var aes = Aes.Create(); aes.Key = key; aes.IV = iv; // iv 已预先生成并保存 using var encryptor = aes.CreateEncryptor(); using var fsIn = new FileStream(inputPath, FileMode.Open); using var fsOut = new FileStream(outputPath, FileMode.Create); using var cs = new CryptoStream(fsOut, encryptor, CryptoStreamMode.Write); fsIn.CopyTo(cs); // 自动分块处理，无需手动缓冲
解密同理，但注意：解密前必须确保输入流可定位（CanSeek == true），否则 CryptoStream 可能读不到完整数据。
解密失败常见原因：文件头被误删、编码混淆、流未关闭
如果加密文件开头存了 IV，解密时忘了跳过这16字节，就会把 IV 当作密文一部分解，结果全是乱码。另外，用 StreamWriter 写加密后文件（而非二进制流）会导致编码损坏，因为 AES 输出是任意字节，不是有效 UTF-8。
排查要点：
- 用十六进制编辑器（如 HxD）打开加密文件，确认前16字节是否为预期
IV值 - 检查是否用了
File.WriteAllText()或StreamWriter处理加密数据——必须全程用FileStream+BinaryWriter（或直接Write()字节数组） - 确保所有
Dispose()或Close()调用到位，尤其是CryptoStream—— 它内部有缓冲，未刷新会导致末尾数据丢失
.NET 6+ 推荐用 AesGcm 实现带认证的加密
如果需要防篡改（比如配置文件不能被悄悄修改），AesCryptoServiceProvider 的 CBC 模式不提供完整性校验。.NET 6 起内置 AesGcm，一步完成加密+认证，但要注意：AesGcm 需要额外 16 字节认证标签（Tag），且 Nonce（类似 IV）必须唯一、不可重复使用。
关键差异：
-
Nonce长度固定为 12 字节；Tag固定为 16 字节，需和密文一起存储 - 加密输出 = 密文 + Tag；解密时必须同时提供密文、Tag、Nonce，缺一不可
- 不支持流式处理，只能一次性加密整个明文块（适合中小文件；大文件仍得自己分块）
实际中，AES-CBC 仍是多数场景的务实选择，除非你明确需要加密+认证一体化。
IV 和密钥管理、流处理边界、二进制安全写入——这几个点漏掉任何一个，加密看起来“跑通”了，实际根本不可用。
