Directory.Exists() 仅判断路径是否存在且为目录，不检查访问权限；返回 true 不代表可读写，需结合异常捕获或实际操作验证权限，并注意长路径、UNC、符号链接及跨平台路径拼接问题。
Directory.Exists() 是最直接的判断方式，但要注意它不检查权限
调用 Directory.Exists() 是 C# 中判断文件夹是否存在的标准做法，它底层通过 Windows API（如 FindFirstFile）或 Unix 系统调用（如 stat）查询路径是否存在且为目录。返回 true 仅表示路径存在且是目录类型，不保证当前进程有读取权限。
- 如果路径存在但无访问权限（如 NTFS 权限拒绝、Linux 上
dr-x------），Directory.Exists()仍返回true - 若路径是符号链接且指向不存在的目标，Windows 下通常返回
false；Linux/macOS 行为取决于挂载选项和stat是否跟随链接 - 注意不要对空字符串或
null调用，会抛出ArgumentException或ArgumentNullException
为什么有时 Directory.Exists() 返回 false，但路径明明“看得见”？
常见于长路径、UNC 路径、重解析点或沙盒环境。.NET 默认启用长路径支持（≥19041 的 Windows 10/11），但若未在 app.config 或 runtimeconfig.json 中启用，超过 260 字符的路径会静默失败并返回 false。
- 检查项目是否配置了
<EnableLongPaths>true</EnableLongPaths>（SDK 风格项目）或<AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=false;Switch.System.IO.BlockLongPaths=false" /> - UNC 路径如
\servershare older需确保网络可达且凭据有效；Directory.Exists()不做网络探测，只尝试访问 - 在容器或受限环境中（如 Docker + non-root 用户），即使路径存在，也可能因挂载方式或用户命名空间导致
stat失败而返回false
需要权限验证时，不能只靠 Directory.Exists()
当业务逻辑依赖“可访问”而非“存在”，比如要遍历子项或创建文件，必须额外验证权限。单纯 Directory.Exists() 无法替代实际操作前的试探性访问。
- 推荐做法：捕获
UnauthorizedAccessException和DirectoryNotFoundException，区分处理——前者说明存在但不可读，后者才是真不存在 - 若需提前判断可读性，可用
new DirectoryInfo(path).Attributes并检查是否含FileAttributes.ReadOnly，但这不等价于权限；更可靠的是尝试Directory.GetDirectories(path)并捕获异常 - 避免用
FileIOPermission（已过时且不适用于 .NET Core+），它在现代运行时中被忽略
跨平台路径拼接错误常导致误判
手动拼接路径字符串（如 "C:\data\" + folderName）极易引发斜杠方向、重复分隔符或非法字符问题，最终传给 Directory.Exists() 的路径根本无效。
- 永远使用
Path.Combine()拼接路径：Path.Combine(baseDir, subFolder) - 传入前先用
Path.GetFullPath()归一化，它能展开..、处理盘符、统一斜杠方向 - 注意
Path.Combine("C:\", "a", "b")返回C:，但Path.Combine("C:\", "\a\b")返回（丢失盘符），这是常见低级错误
路径存在性判断看似简单，真正难的是厘清“存在”的定义边界：是文件系统层面的目录节点，还是进程上下文中有权触及的有效入口。多数线上问题不是函数用错，而是没想清楚你到底想确认什么。
