延迟不仅用于清理 - 好还是坏的做法？

Question

Go 中通常使用延迟执行代码来清理资源。它并不常见，但defer也经常用于执行常规业务逻辑。就像执行的最后一步一样，无论函数在哪一点命中return关键字。

在Go 博客页面上，我们可以发现“ defer 语句将函数调用推送到列表中。保存的调用列表在周围函数返回后执行。Defer 通常用于简化执行各种清理操作的函数。 ”

他们确实提到了清理，但没有提到常规代码执行。显然，它可以执行任意代码，不必进行清理。但这是最佳实践吗？社区是否就这方面的惯例或最佳实践达成一致？

Answer 1

Go编译器不知道什么代码是清理代码。因此，如果推迟清理代码有效，那么显然推迟任何非清理代码也同样有效。延迟函数有一些开销，显然必须管理调用堆栈，但如果它使您的代码更安全和/或更易于阅读，那就去做吧。在返回之前使用它执行任何操作都是完全可以的，甚至可以修改返回的值，甚至在发生恐慌的情况下也是如此。您应该记住的一件事：即使代码发生恐慌（这对于清理代码来说是可取的），延迟函数也会运行，否则这将不是正常的执行流程。因此，与不使用 defer 相比，使用 defer 会有所不同。

Answer 2

让我们非常具体地了解 Go 延迟操作当前（Go 1.14 之前）添加的开销。从 Go 1.13 开始，大多数延迟操作大约需要 35ns（从 Go 1.12 中的大约 50ns 减少）。相比之下，直接调用大约需要 6ns。这种差距激励工程师从热代码路径中消除延迟操作，这会占用更多生产任务的时间，导致代码的可维护性较差（例如，如果稍后引入恐慌，“优化”将不再正确），并且使人们泄气当某种语言特性是问题的适当解决方案时，不要使用它。提案：通过内联代码实现低成本延迟，并使用额外的 funcdata 来管理紧急情况