是否有理由使用 (FileManager)fileExistsAtPath:isDirectory: over (URL).hasDirectoryPath？答案

【问题标题】：is there a reason to use (FileManager)fileExistsAtPath:isDirectory: over (URL).hasDirectoryPath?是否有理由使用 (FileManager)fileExistsAtPath:isDirectory: over (URL).hasDirectoryPath？
【发布时间】：2017-10-17 02:15:30
【问题描述】：

(FileManager)fileExistsAtPath:isDirectory: 和(URL).hasDirectoryPath 之间的实际区别是什么？

我正在关注一些教程，他们首先使用 FileManager 方法，但后来似乎一直使用 URL 方法。在我看来，URL 方法似乎更简洁，更容易记住。是否有任何理由改用 FileManager 方法？（如果答案是是，请提供示例）

【问题讨论】：

啊哈！如果您想将可用性答案作为合格答案，我会将其标记为答案。
这两个API有非常大的区别；这不仅仅是可用性。我写了一个新答案。

标签： objective-c swift

【解决方案1】：

与公认的答案相反，不同之处不仅在于可用性。 FileManager API 实际上是访问磁盘上URL 指向的文件，看它是否是目录，而hasDirectoryPath 不是；它只检查URL的路径末尾是否有斜杠（/），表示该路径指向一个目录。您可以通过制作一个应用程序并在文件活动工具中运行它来验证这一点；使用FileManager，您将在目录中看到lstat64，而使用hasDirectoryPath，您不会。

这有一些影响：

hasDirectoryPath 显然会执行得更快，因为它不访问磁盘。
但是，如果URL 的路径在尾部斜杠的存在方面不正确，hasDirectoryPath 可能会给出不正确的结果。例如：

URL(string: "file:///usr/bin")!.hasDirectoryPath // evaluates to false URL(string: "file:///usr/bin/")!.hasDirectoryPath // evaluates to true
最后，hasDirectoryPath 可以在非file: URL 上工作，例如http: URL，而FileManager 显然不能。

话虽如此，当您需要通过文件系统进行检查时，最好使用基于URL 的机制而不是FileManager 中基于路径的机制：

let isDir = (try? self.resourceValues(forKeys: [.isDirectoryKey]))?.isDirectory ?? false

【讨论】：