Encrypt 和 Decrypt 方法抛出“拒绝访问”是因为 EFS 依赖当前用户 NTFS 卷上的默认证书与私钥；路径非 NTFS、无解密密钥、非交互式上下文或策略限制均会导致异常。
为什么 Encrypt 和 Decrypt 方法在某些文件上直接抛出“拒绝访问”？
因为 EFS 加密本质上依赖当前用户证书和私钥，且仅对 NTFS 卷上的文件/目录生效。调用 File.Encrypt 时，如果目标路径不在 NTFS 分区、文件已加密但当前用户无解密密钥、或进程未以该用户身份运行（如服务账户、跨用户会话），就会触发 UnauthorizedAccessException。特别注意：.NET 的 File.Encrypt 和 File.Decrypt 是对 Windows API EncryptFile/DecryptFile 的封装，不支持自定义证书或密码——它只使用当前登录用户的默认 EFS 证书。
如何确认文件是否已被 EFS 加密？
不能只靠属性面板或 File.GetAttributes 返回的 Encrypted 标志——该标志可能被误设或滞后。最可靠方式是调用 Win32 API GetFileInformationByHandleEx 获取 FILE_ATTRIBUTE_ENCRYPTED，或用 PowerShell 辅助验证：
Get-Item "C:\path\to\file.txt" | ForEach-Object { $_.Attributes -band [System.IO.FileAttributes]::Encrypted }在 C# 中，建议先尝试读取文件元数据并捕获异常，再结合以下逻辑判断：
- 确保路径存在且为 NTFS：
DriveInfo.GetDrives().First(d => path.StartsWith(d.RootDirectory.FullName)).DriveFormat == "NTFS" - 检查
File.GetAttributes(path)是否包含FileAttributes.Encrypted - 若需 100% 确认，P/Invoke
BackupRead或解析 $EFS 属性流（极少见，通常没必要）
加密失败时，哪些权限和配置必须检查？
EFS 不是纯代码逻辑，它深度绑定系统策略和用户状态。以下任一条件不满足都会导致静默失败或异常：
- 当前用户必须拥有 EFS 证书：运行
certmgr.msc→ 查看「个人」→ 「证书」下是否存在 “Encryption” 用途的证书；若无，需运行cipher /k生成 - 目标文件不能位于系统保护目录（如
C:\Windows、C:\Program Files），否则会被策略拦截 - 文件不能是只读、隐藏或系统属性（
File.SetAttributes清除后再试） - 若在域环境中，确认组策略未禁用 EFS（
Computer Configuration → Windows Settings → Security Settings → Public Key Policies → Encrypting File System）
能否在非交互式上下文（如 Windows Service）中使用 EFS 加密？
不能安全使用。Windows Service 默认以 LocalSystem 或网络服务账户运行，这些账户没有加载用户证书私钥的上下文，调用 File.Encrypt 会失败或生成无法解密的密文。即使模拟用户令牌（LogonUser + WindowsIdentity.Impersonate），也无法保证其证书私钥在服务会话中可用（私钥通常受 DPAPI 保护，绑定交互式登录会话）。真实场景中，应避免在服务中直接操作 EFS；如需后台加密，改用 AES 等托管加密，并妥善保管密钥。
真正容易被忽略的是：EFS 加密后的文件，一旦用户证书私钥丢失（例如重装系统未导出证书），文件将永久不可恢复——它不像密码加密那样可暴力穷举。所有自动化脚本若涉及 EFS，必须前置校验证书备份状态。
