File.Exists()仅判断文件存在性，对目录返回false；应改用Directory.Exists()检查目录；统一判断需用File.GetAttributes()；注意路径合法性、权限限制及跨平台兼容性。
File.Exists() 判断的是文件，不是目录
很多人用 File.Exists() 检查一个路径，结果返回 false，但路径明明“看着存在”——大概率是因为那是个文件夹。这个方法只认「带扩展名的完整文件路径」，对目录直接返回 false，哪怕目录真实存在。
实操建议：
- 检查路径是否为文件：用
File.Exists(path) - 检查路径是否为目录：改用
Directory.Exists(path) - 想统一判断「路径是否存在且可访问」：先用
File.GetAttributes(path)，再判断异常或属性是否包含FileAttributes.Directory
示例：
string path = @"C: empconfig.json";<br>if (File.Exists(path)) { /* 是文件且存在 */ }<br>else if (Directory.Exists(path)) { /* 是目录且存在 */ }<br>else { /* 不存在，或无权限访问 */ }
路径字符串里有空格或特殊字符时，File.Exists() 不会报错但可能返回 false
这不是 bug，是设计行为。File.Exists() 遇到非法字符（如 <、>、|）、未转义的 Unicode 控制符，或超出 Windows 路径长度限制（MAX_PATH=260），会静默返回 false，不抛异常。
常见错误现象：拼接路径后调用 File.Exists() 返回 false，但手动在资源管理器里能打开——往往因为路径含中文、全角符号，或开头多了空格。
实操建议：
- 用
Path.GetInvalidPathChars()和Path.GetInvalidFileNameChars()扫描输入字符串 - 用
Path.IsPathRooted(path)确保不是相对路径导致查找位置偏移 - 长路径前加
\?前缀（仅 Windows）：如@"\?C: erylongpath ile.txt"，绕过 MAX_PATH 限制
权限不足时 File.Exists() 返回 false，不是 true/false 逻辑失效
这是最容易被当成“函数不准”的地方。如果当前进程没有读取目标目录的权限（比如系统目录、其他用户 profile 下的文件），File.Exists() 一律返回 false，而不是抛 UnauthorizedAccessException。它不区分“不存在”和“看不见”。
使用场景：部署在受限账户下的服务程序，检查配置文件时总失败，但本地管理员运行就正常。
实操建议：
- 不要依赖
File.Exists()的返回值做权限决策 - 真要确认可访问性，直接尝试
new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.Read)并捕获异常 - 若只需“存在即读”，推荐用
try/catch包裹打开操作，比先查再开更可靠（避免竞态条件）
跨平台项目别硬写 Windows 路径分隔符
在 .NET Core / .NET 5+ 上，File.Exists(@"C: emplog.txt") 在 Linux/macOS 下永远返回 false，因为 不是合法路径分隔符，而且驱动器盘符语义不存在。
性能影响不大，但兼容性直接崩。尤其 CI/CD 流水线跑在 Linux 容器里时，本地测试通过的代码突然挂掉。
实操建议：
- 所有路径拼接用
Path.Combine("folder", "file.txt")，它自动选对分隔符 - 避免硬编码
"\"或"/"；Path.AltDirectorySeparatorChar和Path.DirectorySeparatorChar可读但别手动拼 - 测试时在目标平台跑一遍，别只信 Windows 本地结果
容易被忽略的地方：File.Exists() 的行为本身没毛病，问题几乎都出在路径构造、权限上下文、平台假设这三块。查不到，先盯住路径字符串本身——打印出来，看有没有隐藏字符、空格、BOM、盘符残留。
