最可靠方式是用 DirectoryInfo.GetAccessControl() 查询 NTFS ACL：先验证路径存在且为目录，再检查允许的 FileSystemRights.Write/Modify/FullControl 规则，捕获 UnauthorizedAccessException 和 SecurityException。
用 DirectoryInfo + GetAccessControl() 判断写入权限最可靠
windows acl 权限不是靠“尝试创建文件”这种副作用操作来判断的，尤其在生产环境里，file.create() 或 directory.createdirectory() 会留下临时文件、触发杀软扫描、甚至干扰其他进程。真正安全的做法是查 ntfs 访问控制列表（acl）本身。
关键点：必须用 DirectoryInfo 而不是 Directory 静态类，因为只有实例方法能调用 GetAccessControl()；且需捕获 UnauthorizedAccessException 和 SecurityException —— 某些路径（如 C:Windows）连读取 ACL 的权限都没有，直接抛异常。
- 先检查路径是否存在且是目录：
if (!dirInfo.Exists || !dirInfo.Attributes.HasFlag(FileAttributes.Directory)) - 调用
dirInfo.GetAccessControl(AccessControlSections.Access)，不是Owner或Group - 遍历
AuthorizationRuleCollection，找FileSystemRights.Write或更宽泛的Modify/FullControl，同时注意AccessControlType.Allow且未被同名规则Deny覆盖 - 别忘了当前线程运行身份（如 IIS 应用池账户）才是实际生效的主体，不是开发机上的登录用户
try/catch 创建空文件测写入？只适合简单场景
如果只是本地工具脚本、开发机调试，或者目标路径明确是用户文档目录这类宽松位置，用 File.Create() 加 try/catch 是最快验证方式。但它本质是“行为试探”，不是权限查询，结果有滞后性和副作用。
常见翻车点：IOException 不等于没权限（可能是磁盘满、文件正被占用），UnauthorizedAccessException 才是权限问题，但某些网络驱动器或 OneDrive 同步目录会抛 NotSupportedException 或静默失败。
- 务必指定
FileOptions.DeleteOnClose，避免残留空文件：using var _ = File.Create(path, 1, FileOptions.DeleteOnClose); - 测试路径末尾加个随机子目录（如
test_write_abc123），避免污染原路径 - 不要用
File.WriteAllText()—— 它内部会先尝试创建再写入，异常堆栈更模糊 - .NET 6+ 可用
FileSystemAclExtensions（需引用System.IO.FileSystem.AccessControl），但底层仍是 ACL 查询，不是替代方案
跨平台（Linux/macOS）下不能依赖 ACL 判断
.NET 的 GetAccessControl() 在非 Windows 系统上直接抛 PlatformNotSupportedException。Linux/macOS 权限模型基于 POSIX mode bits（rwx），不支持细粒度的“写入”独立判定 —— Write 权限隐含在目录的 x（执行/进入）和 w（写）位组合里。
此时唯一靠谱做法是模拟真实写入行为，但要比 Windows 场景更谨慎：POSIX 下“有写权限”只表示能创建/删除文件，不保证磁盘空间或配额充足。
- 用
Directory.GetFileSystemEntries()测试读权限（排除UnauthorizedAccessException） - 再用
File.Create(Path.Combine(testPath, ".perm_test"))尝试创建并立即Delete() - 捕获
IOException、UnauthorizedAccessException、DirectoryNotFoundException，三者都算失败 - 别用
stat命令 P/Invoke —— .NET 已有File.GetAttributes()，但返回的FileAttributes.ReadOnly对目录无效
为什么 Directory.Exists() 返回 true 不代表能写入
Directory.Exists() 只检查路径存在性和可读性（即能否列出目录内容），完全不触碰写权限。常见误解是“能看见就能写”，但在域环境、NTFS 继承策略、或启用了“仅允许列出内容”的共享权限时，读和写是彻底分离的。
典型错误现场：ASP.NET Core 站点部署后，日志目录 App_Data/Logs 存在且能浏览，但应用池账户没被赋予 Modify 权限，导致日志写入静默失败，只在 Windows 事件查看器里留一条 ACL 拒绝记录。
- 永远不要把
Exists当作写入前提，它只是前置条件之一 - 若路径是 UNC 共享（
\servershare），还要额外确认 SMB 共享级权限（Share Permissions）和 NTFS 文件系统权限（NTFS Permissions）都放行 - 用
Process Monitor（Sysinternals）抓CreateFile操作，看失败时的Desired Access字段是否含GENERIC_WRITE，这是最准的验证手段
权限判断这件事，从来不是“有没有”，而是“对谁、在什么上下文、走哪条权限继承链”。跳过 ACL 直接试写，省下的那几行代码，后期花在排查“为什么有时行有时不行”上的时间，至少多十倍。
