ProtectedData 不能用于加密文件路径，它加密的是数据块且绑定用户或机器，加密后二进制字节非合法路径字符串；应加密文件内容而非路径，推荐使用 AesGcm 并妥善管理密钥。
Windows 上用 ProtectedData 做本地文件路径加密不靠谱
直接说结论：ProtectedData 不能用于加密文件路径本身，它加密的是数据块，且绑定用户登录会话或机器密钥。你试图“加密路径字符串”再拼进 File.OpenRead，结果要么解密失败，要么路径非法——因为加密后是二进制字节，不是合法路径字符。
真正该加密的，是文件内容；路径只是定位器，应保持可读、可管理。强行加密路径只会让日志、调试、备份全乱套。
- 路径加密混淆 ≠ 安全：攻击者拿到磁盘镜像后，只要能执行同用户进程，
ProtectedData.Unprotect立刻解密 -
Directory.GetFiles、Path.Combine这类 API 都要求输入是合法 UTF-16 字符串，加密后的byte[]转成 Base64 后虽“看起来像字符串”，但长度爆炸、含斜杠/加号，极易触发ArgumentException或路径遍历误判 - 跨机器、跨用户迁移文件时，
ProtectedData加密的内容基本不可恢复
文件静止态加密：用 AesGcm 加密内容，别碰路径
静止态（at rest）加密，核心是让文件内容即使被复制走也无法解密。.NET 5+ 推荐用 AesGcm——它自带认证，防篡改，比手搓 Aes.Create().CreateEncryptor() 更安全。
关键点不是“怎么藏路径”，而是“怎么让加密密钥不硬编码、不存明文”：
- 密钥必须来自外部：用 Windows DPAPI（
ProtectedData）加密主密钥，再把加密后的主密钥存配置文件；或由 Azure Key Vault / HashiCorp Vault 提供运行时密钥 - 每次加密生成新
nonce（12 字节），和密文一起写入文件头（前 12 字节），解密时原样读取 - 不要复用
nonce：同一密钥下重复nonce= 密文可被破解 - 示例片段（简化）：
var key = GetKeyFromVault(); // 返回 32 字节 key var gcm = new AesGcm(key); var nonce = new byte[12]; RandomNumberGenerator.Fill(nonce); var ciphertext = new byte[data.Length + 16]; // 16 字节 tag gcm.Encrypt(nonce, data, ciphertext, out _);
传输中加密：HTTPS 或 TLS 就够了，别自己实现文件流加密
如果文件通过网络传输（比如上传到 Web API），加密责任不在 C# 文件 IO 层，而在传输协议层。自己在 FileStream 上套一层 AES，反而可能破坏 HTTP 分块、断点续传、代理缓存等机制。
正确做法是：
- 服务端用 HTTPS（TLS 1.2+），客户端用
HttpClient直接发原始FileStream，由 TLS 底层加密整个 TCP 流 - 若必须走 HTTP（如内网无 TLS），则用
Application-Level Encryption：先用AesGcm加密文件内容，再 POST 到 /upload —— 此时服务端需配套解密逻辑，且密钥协商必须独立于文件流（比如 JWT Header 带加密后的密钥 ID） - 避免在
NetworkStream上手动包装CryptoStream：容易卡死、缓冲区错位，且 .NET 的CryptoStream不支持异步流式加密（WriteAsync可能阻塞）
路径本身要“可控”，不是“不可见”
真正需要保护的，从来不是路径字符串，而是路径所指向的访问权限。Windows ACL 和 .NET 的 File.SetAccessControl 才是正解。
例如，敏感文件放 C:\ProgramData\MyApp\Secrets\，然后：
- 用
DirectorySecurity移除 Users 组默认继承权限，只保留 SYSTEM 和指定服务账户 - 禁用共享，关闭 SMB 签名弱策略
- 日志里记录所有
File.Open失败事件（配合 Windows 审计策略），而不是靠路径“看不出名堂”来蒙混 - 路径中避免硬编码敏感信息：
user_12345.dat比alice_pswd_backup.enc更安全——前者无法反推身份，后者一目了然
最常被忽略的一点：加密密钥的生命周期管理比算法选择重要十倍。一个被遗忘在 appsettings.json 里的 AES 密钥字符串，比用 DES 加密的文件更危险。
