必须用 CipherInputStream 是因为它自动处理 AES 的块对齐、PKCS5 填充补全和异常传播，而手动操作字节数组易破坏填充结构导致解密失败。
用 AES 加密文件时为什么必须用 CipherInputStream 而不是直接读字节数组？
因为 AES 是分组密码，底层依赖填充（如 PKCS5Padding）和模式（如 CBC），直接操作字节数组容易破坏最后一块的填充结构，导致解密失败。Java 的 CipherInputStream 会自动处理块对齐、填充补全和异常传播，而手动分块调用 cipher.update() + cipher.doFinal() 容易漏掉边界逻辑。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 加密大文件务必用
CipherInputStream包裹FileInputStream，再通过IOUtils.copy()或循环read()写入CipherOutputStream - 密钥长度必须为
128、192或256位；若用字符串生成密钥，需经MessageDigest摘要（如SHA-256）截取前 16 字节，否则InvalidKeyException -
IV必须随机生成且随密文一起保存（通常前置 16 字节），不能复用，否则相同明文会产生相同密文，丧失语义安全性
如何安全地生成和保存 SecretKeySpec 与 IvParameterSpec？
硬编码密钥或写死 IV 等同于没加密。真实场景中，密钥不应出现在代码或配置文件里，IV 更不能固定。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 用
SecureRandom生成IV：byte[] iv = new byte[16]; new SecureRandom().nextBytes(iv); - 加密时把
IV写在密文开头（如先写 16 字节IV，再写密文），解密时先读出前 16 字节构造IvParameterSpec - 密钥建议由用户口令派生：用
PBEKeySpec+SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256")，迭代次数 ≥ 65536 - 避免用
String.getBytes()直接转密钥——编码不明确，不同平台结果可能不同；应显式指定StandardCharsets.UTF_8
解密失败报 BadPaddingException 的常见原因有哪些？
这个异常几乎总是意味着密文被篡改、IV 不匹配、密钥错误，或加解密参数不一致，而不是“padding 本身有问题”。
排查要点：
- 确认加密和解密用的是同一套参数：算法/模式/填充三者必须完全一致，例如
"AES/CBC/PKCS5Padding"，少一个斜杠或拼错字母都会触发该异常 - 检查
IV是否被截断或误读——比如解密时只读了 15 字节，或用了加密时未保存的随机IV - 验证密钥是否经过相同摘要处理（如都用
SHA-256取前 16 字节），尤其注意加解密两端的字符编码是否统一 - 如果密文是从 Base64 解码而来，确认没有丢掉末尾的
=或混入空格换行
为什么不能用 FileWriter / BufferedWriter 处理加密后的二进制数据？
因为这些是字符流，会尝试按默认编码（如 UTF-8）解释字节，而加密输出是纯二进制，包含非法码点，导致数据损坏或静默截断。
必须全程使用字节流：
- 加密：用
FileInputStream→CipherInputStream→FileOutputStream - 解密：用
FileInputStream→ 手动跳过 IV →CipherInputStream→FileOutputStream - 若需 Base64 编码传输，也应在加密完成后对整个密文字节数组做
Base64.getEncoder().encode()，而不是边读边编码
真正麻烦的从来不是调用哪个 API，而是 IV 怎么存、密钥怎么来、错误怎么判——这些细节一旦错一点，解密就彻底失败，还很难定位。
