可通过继承FilterInputStream重写read方法实现流式加解密：加密时读原始流→加密→返回；解密时读密文流→解密→返回明文；需注意模式选择（推荐CFB/OFB/GCM）、IV处理、缓冲优化及异常透明性，优先使用CipherInputStream等成熟实现。
可以通过继承 FilterInputStream 并重写其核心读取方法（如 read()、read(byte[])、read(byte[], int, int)），在数据从底层流读出后、返回给调用方前插入加解密逻辑，从而实现透明的流式加解密。
加密读取：在 read() 返回前加密原始字节
注意：严格来说，“读取时加密”通常指对**写入目标**的数据加密，但若需在读取源流时“边读边加密输出”，应将 FilterInputStream 视为一个“加密包装器”——它从原始流读数据，加密后再提供给上层。此时实际是“读-加密-返回”，而非修改源流内容。
- 在构造函数中接收原始
InputStream和加密器（如Cipher实例，需已初始化为ENCRYPT_MODE） - 重写
read()：调用in.read()获取单字节 → 转为长度为 1 的 byte 数组 → 用cipher.update()加密 → 返回加密后的首字节（需缓冲剩余字节，因加密可能改变长度，如 AES 块加密需填充） - 更实用的是重写
read(byte[] b, int off, int len)：先从底层流读满len字节（或尽可能多），再整块加密，写入目标数组。注意处理cipher.doFinal()在末尾触发填充和结束逻辑 - 务必在
close()中调用底层流的close()，并清理敏感资源（如清空密钥数组）
解密读取：在 read() 返回前解密已加密字节
这是更常见的场景：你有一个加密过的文件流，希望像读普通流一样透明解密使用。
- 构造时传入加密源流和已初始化为
DECRYPT_MODE的Cipher - 重写
read(byte[] b, int off, int len)：先从底层流读一批密文（建议按加密块大小对齐，如 AES 为 16 字节倍数），再用cipher.update()解密；对最后一块调用cipher.doFinal()处理填充（如 PKCS5/PKCS7） - 需内部维护解密缓冲区（
ByteArrayOutputStream或ByteBuffer），因为密文长度 ≠ 明文长度，一次底层读可能产出多段明文，需缓存供后续read()调用消费 - 避免在每次单字节
read()中都调用cipher.update()，性能极差；应以块为单位批量处理
关键细节与避坑点
流式加解密不是简单套公式，必须考虑密码学语义和流特性：
-
模式选择：优先用支持流式处理的模式，如
Cipher.getInstance("AES/CFB/NoPadding")或"AES/OFB/NoPadding"；避免 ECB（不安全）、CBC（需 IV 且需处理首块）——若用 CBC，IV 必须随密文一起存储/传输，且解密时第一个update()需传入 IV -
IV 与认证：仅加密不验证易受篡改。生产环境推荐 AEAD 模式（如
AES/GCM/NoPadding），但 GCM 的doFinal()会校验 tag，需确保完整读取密文（包括末尾的 tag 字节），否则抛AEADBadTagException -
缓冲与阻塞：
FilterInputStream默认不缓冲，若底层流慢（如网络流），应在内部加BufferedInputStream包装，或自己实现缓冲逻辑，减少加解密调用频次 -
异常透明性：加解密失败（如密钥错误、tag 校验失败）应抛出检查型异常（如
IOException子类），而非静默吞掉，方便上层感知
简化实践建议
除非有特殊定制需求（如混合压缩+加密、自定义协议头），直接使用成熟库更稳妥：
- Java 自带
CipherInputStream/CipherOutputStream已完成上述逻辑，可直接 new 使用（注意其默认行为：CBC 模式 + PKCS5 填充，且 IV 从密文头读取） - Bouncy Castle 提供更多算法和模式支持，如
BufferedBlockCipher用于手动控制块处理 - 若需更高层抽象，Apache Commons Crypto 或 Google Tink 封装了密钥管理、AEAD、密钥轮换等企业级能力
