我不确定这是否是一个纯粹的stackoverflow相关问题。它与一般设计实践有关。由于我想不出其他相关的堆栈交换网站，请将其张贴在这里。
在将异步调用转换为同步调用的一般设计实践中，我们使用超时并等待结果。虽然从响应性的角度来看，这可能不是一个好的做法，但它肯定会使实现更容易。
我见过很多这样的实现，经常注意到开发人员倾向于给出一个非常小的超时值。我可以理解，当人们这样做的时候，他们可能心中需要一个响应系统。但我看到的许多应用程序都是数据关键型的，数据丢失非常严重。因此，最好多等待并尝试获取尽可能多的数据，而不是提前超时并向用户发出错误消息。现在，服务器无法提供数据或客户端无法访问服务器等情况很少见。在这种情况下，我预计这样的等待会有很大的超时时间。毕竟，这些超时并不意味着等待一定会持续到给定的超时值；超时值只是一个上限。所以，我一直主张更高的价值观。但我看到越来越多的地方使用低值，现在我很困惑这种做法中是否真的有其他我不理解的地方。
所以，我的问题是：除了需要响应来实现很小的等待超时之外，还有什么争论吗？
一如既往，正确的决策取决于实际数据。超时时间应与成功完成操作所需的时间成比例。
例如，发送UDP消息可能需要1-50毫秒，因此100毫秒的超时是合理的，但通过有线复制文件可能需要几分钟或更长时间，因此100微秒的超时是可笑的。
短时间和长时间暂停都有利弊，所以这是一种权衡。较长的超时会为相同的工作量使用更多的资源（任务、线程、内存等），而如您所述，较短的超时可能会导致数据丢失。
总之，您需要设置一个听起来合理的可配置超时，然后弄清楚是在生产中超时了太多操作还是以其他方式超时，并进行相应的校准。