您是否知道在打开和发送文件之前检查文件是否存在任何严重的性能问题？其上下文是一个通过 ASP 页面动态提供文件的 Web 应用程序。我被告知没有检查文件是否存在，因为数据库存储了这些信息并且不应该是错误的。当然，有时由于多种原因是错误的，所以我们最终不会发回任何东西，让用户不满意。
我的直觉是检查文件是否存在是如此便宜，以至于您不必担心，但有人告诉我不然。如果有帮助的话，我们的存储解决方案是一个非常强大的解决方案（不仅仅是 Web 服务器上的 IDE 驱动器）。我的问题基本上是：我的直觉正确吗？
谢谢！
注意：这些文件永远不会被删除。他们必须出问题才能失踪，但这每周会发生几次。另外，我想检查文件是否存在的原因是因为我可以返回磁盘上的备用资产，所以我希望能够在一个地方拥有该逻辑，而不是处理捕获异常并处理在那种情况下。
即使您在尝试提供它之前检查它是否存在，它也可能在检查和您提供它之间被删除。
这里的问题是，如果您无法提供文件，您什么也不会发回。尝试提供不存在的文件应该引发异常（或您平台上的任何等价物） - 您应该通过返回适当的“抱歉，我们找不到您的文件”错误页面来处理该异常。
如果文件不存在是特殊情况（正如你所说的数据库总是正确的），你不应该检查它。
如果它不在那里，你会得到一个异常并相应地处理它。这似乎是你所说的系统工作的方式，我会这样处理。
还有一点要注意，如果您说打开时文件不存在只是什么都不返回，那么这告诉我您的异常处理存在设计缺陷，并且您的较低级别没有将异常冒泡到足以正确处理的程度这样您就可以将错误消息传达回客户端。
通过适当的异常处理/冒泡，您返回备用资产应该没有问题。重新考虑您的异常处理，而不是重新设计系统应该工作的方式。
只要您不使用某种非常奇怪的存储方案，您就不应该遇到任何严重的性能问题。
我不知道这种方法有任何主要的性能问题，但是在打开文件之前检查文件是否存在可能会产生意想不到的结果（另一个进程可以在检查和打开文件之间删除文件）。
我真的不知道这是一个便宜还是昂贵的任务，但是，考虑到不检查文件的存在可能会导致对客户的不愉快响应，我会说它并不昂贵。
我确实有一些网络应用程序可以在其中检查文件是否存在并且运行良好。
您是重定向到文件，还是通过代码读取和提供文件内容？
如果是第一个，如果文件由于某种原因不存在会发生什么？标准 404 错误，还是您有专门的错误页面？这种情况可以接受吗？
如果是后者，只需打开文件并适当地处理异常。
与数据库或内存中的读取相比，文件 IO 的成本通常很高，但在寻找系统崩溃或未处理的异常时，我已经听过太多次“数据库存储信息，因此它不应该出错”的老话。因此，除非您的性能要求异常高，否则我会检查是否存在并优雅地恢复。
如果不检查文件会导致用户感到困惑和/或没有给他们所需的东西，或者至少显示一条指示问题的错误消息 - 那么成本是多少都没有关系。
应用程序需要检查。
性能方面应该基本上没有影响。这里最慢的部分是去磁盘读取文件头，但如果你要加载文件，无论如何你都必须这样做，任何体面的存储系统（几乎过去几十年的任何一个）都会缓存从检查中读取的内容，以便在您实际打开文件时读取的部分速度要快得多。话虽如此，我同意 mattlant 的观点，即如果通常预期文件存在，最好捕获文件不存在异常并正确处理它。
如果您要在之后立即打开它，那么检查它的存在基本上是免费的。
尝试打开文件，然后流式传输。有这种可能吗？这样，如果您无法打开并流式传输它，那么您将无法发送它并且可以采取适当的错误处理。