为什么 RijndaelManaged
在高并发下会成为瓶颈
它不是线程安全的，每次调用
CreateEncryptor()或
CreateDecryptor()都会内部新建状态对象，且其默认实现使用同步锁保护静态资源（如填充模式、密钥调度缓存）。在千级 QPS 场景下，大量短生命周期实例频繁争抢锁，
Monitor.Enter开销会明显抬高 CPU 和延迟。 不要复用同一个
RijndaelManaged实例跨线程调用 —— 会抛
CryptographicException: The object is not in the correct state不要在循环中反复
new RijndaelManaged()并手动
Dispose()—— GC 压力大，且构造成本固定约 0.1–0.3ms .NET Core 3.0+ 中已标记为过时，
RijndaelManaged不再推荐用于新项目
用 AesGcm
替代时要注意哪些参数陷阱
AesGcm是硬件加速友好的 AEAD 算法，但它的 API 设计对并发不友好：必须为每次加密生成唯一
nonce（通常 12 字节），且不能重复；解密时需原样传入同一
nonce+ 认证标签（16 字节）。若用
RandomNumberGenerator同步生成 nonce，极易成为新瓶颈。 避免在加密逻辑里调用
RandomNumberGenerator.GetBytes(nonce)—— 它是同步锁保护的全局 RNG 改用预分配
Span<byte></byte>+
RandomNumberGenerator.Fill()（.NET 6+）或分片 counter-based nonce（如每线程维护递增 long，转为 big-endian 12 字节）
AesGcm.Encrypt()输出包含密文 + tag，务必把 tag 追加到结果末尾；解密前必须严格切分最后 16 字节作为 tag，否则抛
CryptographicException: Authentication failed
MemoryPool<byte></byte>
能否真正降低 GC 压力
能，但仅当你的加密数据长度相对固定（如统一 256–2048 字节）且 QPS > 500 时才值得引入。如果每次加密输出长度波动大，或者用
ArrayPool<byte>.Shared</byte>未控制租借大小，反而可能因碎片导致内存浪费或 fallback 到 new byte[]。 优先用
MemoryPool<byte>.Shared.Rent(int minBufferSize)</byte>，而非
ArrayPool<byte>.Shared.Rent()</byte>—— 前者支持超大 buffer（>85KB），后者只管小对象堆 解密后立即
pool.Return(buffer, clearArray: true)，避免敏感数据残留内存 别在
using var output = pool.Rent(...)外部捕获
output.Memory引用 —— Return 后该内存可能被复用，引发脏读
var pool = MemoryPool<byte>.Shared;
var input = Encoding.UTF8.GetBytes("secret data");
var nonce = stackalloc byte[12];
// 使用线程本地 counter 构造 nonce，非 Random
Unsafe.WriteUnaligned(ref nonce[4], ThreadLocalCounter.Next());
<p>var outputBuffer = pool.Rent(input.Length + 16); // 密文 + tag
try
{
var gcm = AesGcm.Create();
gcm.Encrypt(
nonce,
input,
outputBuffer.Memory.Span[..input.Length],
outputBuffer.Memory.Span[input.Length..],
associatedData: default);
}
finally
{
pool.Return(outputBuffer, clearArray: true);
}高并发加解密真正的复杂点不在算法选型，而在于 nonce 管理方式 和 buffer 生命周期边界。这两个地方一旦和线程模型耦合错位，轻则性能抖动，重则数据损坏或内存泄露。
