核心问题是大文件一次性加载内存导致OOM，应改用流式加解密；RSA仅用于加密AES密钥，AES每次需新IV，密钥须安全生成并独立管理。
核心问题不在“是否复用 Cipher 对象”，而在于**错误地将整个文件或大块数据一次性加载进内存再调用 doFinal()**。Cipher 本身是轻量对象，复用它并不能缓解内存溢出；真正挤爆堆空间的是原始字节数组（如 FileUtils.readFileToByteArray()）和加密后密文数组的双重驻留。
避免一次性加载全量数据
这是最直接有效的解决路径。无论 Java、C#、Python 还是 JavaScript，都应放弃“读全文件 → 加密 → 写全文件”这种简单粗暴模式。
- Java：改用
CipherInputStream/CipherOutputStream包装文件流，边读边加/解密，内存占用稳定在几 KB～几十 KB - C#：使用
CryptoStream套接FileStream，配合Aes.Create()实例，不生成中间byte[] - Python（pycryptodome）：用
encryptor.update()分块处理，最后encryptor.finalize()，避免encrypt()一次性吞入全部明文 - JavaScript（Web Crypto）：对
ArrayBuffer分片（如每 128KB），逐片调用encrypt()，拼接结果
严格区分 AES 和 RSA 的使用边界
RSA 不该出现在大批量数据加解密流程中。它的角色只应是“加密 AES 密钥”——一个固定长度（如 32 字节）的短数据。若你在批量操作中让 RSA 处理任意长度输入，就已偏离安全实践。
- 发现代码里有
RSA.encrypt(data)且data.length > 256？立刻重构为混合模式 - 确保每次 AES 加密都配对生成新 IV（16 字节随机值），并和密文一起存储/传输，而非硬编码或复用
- 密钥管理必须独立：AES 密钥由安全随机生成，RSA 公钥仅用于加密该密钥，私钥离线保管
控制 JVM 或运行时内存行为（辅助手段）
这不是根本解法，但在过渡期或调试阶段可降低崩溃频率：
- Java 启动参数增加
-Xms512m -Xmx2g，避免频繁 GC 同时又不过度抢占系统资源 - C# 中设置
GCSettings.LargeObjectHeapCompactionMode = GCLargeObjectHeapCompactionMode.CompactOnce，减少大数组碎片 - PHP 调整
memory_limit=512M并启用opcache，但务必同步改用fopen()+fread($handle, 8192)流式读取
验证与监控关键指标
上线前确认三项是否达标，否则仍可能在高并发下触发 OOM：
- 加密单个文件过程中，JVM 堆内最大存活对象是否始终 ≤ 1MB？可用 VisualVM 或 JFR 抓取快照验证
- 密钥派生是否避开
SecureRandom(strKey.getBytes())这类弱熵源？应使用 PBKDF2/HKDF+盐值 - 解密失败时是否抛出明确异常（如
BadPaddingException）而非静默返回乱码？这是 IV 或密钥错位的典型信号
