我一直在使用+[NSURL fileURLWithPath:]，因为它很方便，但是在分析中我发现这是瓶颈的源头，因为它在调用+[NSURL fileURLWithPath:isDirectory:](或等效的Core Foundation)之前查询文件系统:
如果可能的话，我想避免这种开销。但是我并不总是提前知道我要构建的URL是否是目录。例如，可以给我一个路径，或者给我一个目录以及其中的项目名称(未知类型)。我的问题是，即使事实证明可能不正确，也始终将NO传递给isDirectory可以吗？
特别是，我要确保这不会弄乱-[NSURL getResourceValue:forKey:error:]和NSFileManager。
一些基本测试并未显示此优化有任何不良后果，但这并不意味着没有任何优化。我尚不清楚为什么NSURL首先关心isDirectory。查看CFURL source，该代码似乎试图确保目录路径始终以斜杠结尾。但是，除了出于显示目的之外，我不清楚为什么这对文件系统路径很重要。 (使用NSString表示路径时，这绝不是问题。)+[NSURL fileURLWithPath:isDirectory:]的文档说isDir是:
的确，如果我使用-[NSURL initWithString:relativeToURL:]，则新的URL不包括baseURL的最后一个组成部分，除非它是使用YES为isDirectory创建的。但是，我认为我从未调用过这种方法，并且似乎该系统不需要代表我这样做(对于上述用例)。我注意到，如果有必要，-[NSURL URLByAppendingPathComponent:]会插入一个斜杠，而不是假设IS_DIRECTORY标志是正确的。因此，除了创建相对URL外，此标志还重要吗？即使我愿意，在一般情况下似乎也始终无法传递正确的值。文件系统总是可以从我下面变出来。如果我使用+[NSURL fileURLWithPath:]，则系统也无法始终确定它，因为该路径可能尚未在文件系统中存在。
最佳答案
如果您传递NO并始终创建非目录URL，那么对于使用URL访问文件系统的所有例程(例如-getResourceValue:forKey:error:或NSFileManager)来说，这都是绝对好的。
对于file URL，仅当您随后要根据URL解析路径时，尾部的斜杠才真正变得很重要。即此代码段:
NSURL *baseURL = [NSURL fileURLWithPath:path isDirectory:YES];
NSURL *result = [NSURL URLWithString:@"relative/path" relativeToURL:baseURL];
会对此产生不同的结果:
NSURL *baseURL = [NSURL fileURLWithPath:path isDirectory:NO];
NSURL *result = [NSURL URLWithString:@"relative/path" relativeToURL:baseURL];
实际上，处理
file URL的相对字符串/路径往往不是那么普遍。远程URL需要它更多(当然，这取决于您的应用程序!)关于macos - isDirectory参数是否为+ [NSURL fileURLWithPath :isDirectory:] need to be correct?，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/18665370/