加密必须在filestream.write前完成，使用cryptostream实现原子化加解密；密钥派生用rfc2898derivebytes，iv每次随机生成并随密文存储；优先选aesgcm（.net6+），兼容旧版则用aescbc+hmac；密钥不得硬编码，内存中及时清零；所有变更须带版本号以保证向后兼容。
加密必须在写入磁盘前完成，不能依赖文件系统层
Windows 的 EFS 或 BitLocker 是透明加解密，对应用不可见，无法满足“客户端到存储全程可控”的需求。你得在 FileStream.Write 之前就把明文变成密文——否则任何中间环节（缓存、页交换、临时文件）都可能泄露原始数据。
常见错误是先写入临时 FileStream，再读取加密后另存：这会在磁盘/内存中短暂留下明文副本。正确做法是用 CryptoStream 套在 FileStream 上，让加密和写入原子发生。
- 始终用
CryptoStreamMode.Write+FileStream构造加密流，不要分两步 - 密钥派生必须用
Rfc2898DeriveBytes（PBKDF2），别手写哈希迭代 - IV 必须每次随机生成，并和密文一起持久化（比如前 16 字节），不能硬编码或复用
- 别用
DES或RC2，.NET 6+ 默认推荐AesGcm（需SymmetricAlgorithm.CreateAead），若需兼容旧版本则用AesCbc+ HMAC 校验
客户端加密后，服务端不能碰明文，但要能校验完整性
如果服务端需要做文件去重、大小检查、格式识别等操作，又不能解密，就得靠加密前的元数据。比如上传前计算并上传 SHA256（明文哈希），服务端只存这个哈希值用于比对；或者把文件名、MIME 类型、尺寸等非敏感字段单独明文传输，和密文分开存储。
容易踩的坑是把加密后的字节流直接当“指纹”用——AesCbc 每次 IV 不同，同一文件加密结果完全不同，根本没法比对。
- 服务端收到的密文必须原样落盘，禁止任何形式的解包、重编码、base64 转义后再存（除非你明确设计了该层封装）
- 若需支持断点续传，加密必须按块进行（如每 1MB 加密一次），且每块 IV 独立生成并附带在块头里
- 不要在服务端用
File.Move或File.Copy处理密文文件——某些 .NET 版本会触发缓冲区复制，导致明文短暂驻留内存
AesGcm 和 AesCbc 的选择不是性能问题，而是安全契约差异
AesGcm 自带认证（AEAD），解密失败时抛 CryptographicException，且错误信息不泄露密文结构；AesCbc 需手动加 HMACSHA256，验证失败后还要自己丢弃已读的明文缓冲区，否则可能引发填充预言攻击（Padding Oracle）。
但 AesGcm 在 .NET 5 才稳定支持，.NET Core 3.1 及更早版本调用 CreateAead 会抛 NotSupportedException。所以实际选型要看运行环境。
- .NET 6+ 项目优先用
AesGcm，初始化时传入 12 字节随机nonce（不是 IV） - 跨平台部署时注意：Linux 上某些 OpenSSL 后端对
AesGcmnonce 长度校验更严，固定用 12 字节最稳妥 - 若必须用
AesCbc，HMAC 必须计算在密文上（不是明文），且验证通过后才允许解密——顺序反了就失去意义
密钥管理不是代码问题，而是部署时的硬约束
客户端加密密钥绝不能写死在代码里，也不能存在 config 文件中。用户密码经 Rfc2898DeriveBytes 派生出的密钥，只能在内存中短时存在（比如一个上传任务期间），任务结束立即清零 byte[]（用 Array.Clear，别只设 null）。
服务端更麻烦：它不持有用户密钥，但需要安全地存储每个用户的加密参数（如 salt、加密算法标识、密钥派生轮数）。这些参数本身不敏感，但必须和用户账户强绑定，且不能被批量导出。
- 客户端不要用
ProtectedData（DPAPI）保护密钥——它依赖当前 Windows 用户上下文，换机器/账号就失效 - 服务端存储加密参数时，字段名避免含
key、secret等关键词，防止被扫描工具误报 - 所有密钥派生必须指定足够轮数（
iterationCount >= 100_000），尤其在客户端 CPU 较弱时，宁可牺牲一点速度也要防暴力
最常被忽略的一点：加密流程一旦上线，就再也无法回退。哪怕只是改个 IV 生成方式，历史文件就全变砖。任何变更都必须带版本号（比如写进密文头部前 4 字节），解密逻辑永远向后兼容。
