os.Stat(path string) (os.FileInfo, error)函数（尝试）是否打开位于path的文件，或者是否涉及任何欺骗，以便它不需要？
此外，多次打开/关闭文件的性能损失是什么（没有读/写，我知道这些是慢的），而不是只做一次？它是硬盘绑定的吗？操作系统有什么不同吗？
答案 0 :(得分：4)
documentation并未真正解释您为什么需要FileInfo或如何检索它。我怀疑他们认为大多数读者会从名称中认识到它是Unix调用stat的跨平台抽象，并且已经意识到这意味着什么。这对于无数其他语言来说并不是独一无二的。标准库在文档中具有类似命名的函数和类似的假设。 （例如，请参阅Python。）
stat函数的要点是获取有关文件的元数据（大小，创建时间等）而无需打开它。这有两个重要原因：
而且，正如您在文档中看到的那样，os.Stat在大多数平台上实现为stat或fstatat。 1
因此，如果你想获得一个文件的大小，os.Stat要比打开文件，寻找结束，获得当前位置快得多。或者甚至只是打开文件并关闭它。但它仍然没有自由。
对于大多数Unix文件系统，它通过读取inode，一个包含有关文件的所有关键信息的单个磁盘块来工作，并且通常优化inode分配。 （它还需要至少读取一个目录，因为您按名称指定了文件，但是对于性能很重要的常见情况，它会被缓存，扫描整个目录或树。）
肯定存在平台差异。像往常一样，最大的， 2 介于Windows和其他所有人之间。的Windows＆＃39; NTFS文件系统在目录条目中缓存大部分但不是全部相同的信息，因此如果您只想要这些信息，则甚至不需要转到（相当于）一个inode，而且它不需要。更快。但如果你想要一切，那就慢了。像find这样的工具都是关于搜索目录树的工具，必须针对这些差异进行优化，但对于大多数程序来说，这不是一个问题;只需致电stat。或者，在Go中，os.Stat。
<子> 1。您感到困惑的fillFileStatFromSys函数只是将stat返回的结构中的信息重新组织为Go想要呈现的格式，因此您不必处理相当于笨拙的C宏的问题。和遗留时间戳格式等。
<子> 2。从历史上看，有些平台没有像stat这样的远程，并且为了模拟它，你真的必须打开和关闭文件。但我不认为Go可以在任何平台上运行。