go - 在一个简单的、不返回的、非 panic 的函数中使用 defer 有什么好处吗？

Question

通过标准库，我看到很多类似于以下的函数:

// src/database/sql/sql.go
func (dc *driverConn) removeOpenStmt(ds *driverStmt) {
    dc.Lock()
    defer dc.Unlock()
    delete(dc.openStmt, ds)
}
...

func (db *DB) addDep(x finalCloser, dep interface{}) {
    //println(fmt.Sprintf("addDep(%T %p, %T %p)", x, x, dep, dep))
    db.mu.Lock()
    defer db.mu.Unlock()
    db.addDepLocked(x, dep)
}
// src/expvar/expvar.go
func (v *Map) addKey(key string) {
    v.keysMu.Lock()
    defer v.keysMu.Unlock()
    v.keys = append(v.keys, key)
    sort.Strings(v.keys)
}
// etc...

即:没有返回值的简单函数，大概没有办法 panic ，但仍在推迟解锁其互斥体。据我了解，defer 的开销已得到改进(并且可能仍在改进过程中)，但话虽这么说:是否有任何理由包含 defer 这样的函数？难道这些类型的延迟最终不会减慢高流量功能吗？

Answer 1

始终在函数顶部延迟诸如 Mutex.Unlock() 和 WaitGroup.Done() 之类的操作，使调试和维护更容易，因为您会立即看到那些件得到正确处理，因此您知道这些重要件已得到处理，并且可以快速转移到其他问题。

这在 3 行函数中没什么大不了的，但是看起来一致的代码通常也更容易阅读。然后，随着代码的增长，您不必担心添加可能会导致 panic 的表达式，或复杂的早期返回逻辑，因为预先存在的延迟将始终正常工作。