用 File.GetAccessControl
检查文件 ACL 是否包含当前用户读写权限
直接读取文件的访问控制列表（ACL），比尝试读写再捕获异常更可靠，尤其适合预判操作是否可行。但注意：ACL 只反映 NTFS 权限，对 FAT32、网络共享或符号链接可能不准确。
关键步骤：
File.GetAccessControl(path)获取
FileSecurity对象，若路径不存在会抛出
FileNotFoundException，需先用
File.Exists或
Directory.Exists判断 调用
GetAccessRules(true, true, typeof(NTAccount))获取所有继承/非继承的用户/组规则 遍历规则，用
WindowsIdentity.GetCurrent().Name匹配
IdentityReference.Value，检查
FileSystemRights是否含
Read和
Write注意权限是累加的——用户所属多个组的权限需合并判断，不能只看单条规则
用 File.Open
尝试打开再捕获 UnauthorizedAccessException
最简单粗暴但实用的方法，适用于“只要能干活就行”的场景。它绕过了 ACL 解析的复杂性，真实模拟后续操作行为。
典型写法：
try {
using (var fs = File.Open(path, FileMode.Open, FileAccess.ReadWrite, FileShare.None))
{
// 成功打开即说明有读写权
return true;
}
}
catch (UnauthorizedAccessException) {
return false;
}
catch (IOException ex) when (ex.Message.Contains("The process cannot access the file")) {
// 文件被其他进程独占占用，不是权限问题
return false;
}
注意：
File.Open会触发实际 I/O，如果文件很大或在慢速存储上，会有轻微开销；且某些防病毒软件可能拦截该调用并误报。
检查 Directory.GetAccessControl
对父目录的写权限
创建新文件或重命名时，真正起作用的往往是父目录的
Write权限（例如
Modify或
CreateFiles），而非目标文件本身。很多开发者只查文件 ACL，结果在
File.WriteAllText时失败。
正确做法：
对目标路径调用Path.GetDirectoryName(path)得到父目录 用
Directory.GetAccessControl(dirPath)获取目录安全对象 检查规则中是否存在当前用户或其所属组，且
FileSystemRights包含
CreateFiles（新建）或
DeleteSubdirectoriesAndFiles（删除/重命名） 特别注意：若路径是根目录（如
C:\），系统策略常默认拒绝普通用户写入，即使 ACL 显示允许
UAC 和管理员提权状态会影响实际权限判断
即使代码跑在管理员组内，若未以“管理员身份运行”，Windows 会通过 UAC 过滤掉高权限令牌，导致
GetAccessControl返回的权限和实际运行时不符。
验证是否真正拥有完整管理员令牌：
var identity = WindowsIdentity.GetCurrent(); var principal = new WindowsPrincipal(identity); bool isElevated = principal.IsInRole(WindowsBuiltInRole.Administrator);
如果
isElevated为
false，即使 ACL 显示允许，
File.Create仍可能失败。此时应提示用户右键选择“以管理员身份运行”，而不是硬编码降级处理逻辑。
权限检查不是一劳永逸的事——文件可能被其他进程锁定、组策略动态更新、或路径指向重定向位置（如 OneDrive 同步文件夹），这些都会让静态检查失效。真正在意健壮性，就得把检查和操作尽量靠近，甚至接受“先试后错”。
