我正在使用這個驅(qū)動程序：https : //github.com/denisenkom/go-mssqldb并且在使用 Azure SQL 數(shù)據(jù)庫標(biāo)準(zhǔn) S3 級別的生產(chǎn)中，我們得到了太多 ErrBadconn -driver: Bad connection返回。我怎樣才能防止或至少優(yōu)雅地處理它。這里有一些代碼來展示事情是如何設(shè)置的。一個典型的數(shù)據(jù)庫函數(shù)調(diào)用包 dalvar db *sql.DBtype Database struct{}func (d Database) Open() {    newDB, err := sql.Open("mssql", os.Getenv("dbconnestion"))    if err != nil {        panic(err)    }    err = newDB.Ping()    if err != nil {        panic(err)    }    db = newDB}func (d Database) Close() {    db.Close()}// ... in another filefunc (e *Entities) Add(entity Entity) (int64, error) {    stmt, err := db.Prepare("INSERT INTO Entities VALUES(?, ?)")    if err != nil {        return -1, err    }    defer stmt.Close()    result, err := stmt.Exec(entity.Field1, entity.Field2)    if err != nil {        return -1, err    }    return result.LastInsertId()}簡而言之，該dal包在多個 Azure Web 應(yīng)用程序和命令行 Go 應(yīng)用程序之間共享。我看不到一種模式，即那些頻繁且隨機發(fā)生的錯誤。我們正在使用 Bugsnag 來記錄我們所有應(yīng)用程序的錯誤。為了完成，有時會達到我們的標(biāo)準(zhǔn) S3 限制 200 個并發(fā)連接。我在訪問數(shù)據(jù)庫的包上的所有地方都進行了三重檢查，確保所有內(nèi)容sql.Rows都已關(guān)閉，所有db.Prepare語句都已關(guān)閉。作為示例，典型的查詢函數(shù)如下所示：該readEntity基本上只做Scan上的字段。我認(rèn)為這與代碼無關(guān)，單元測試在本地運行良好。有時在運行后僅部署到 Azure 一次，驅(qū)動程序：錯誤連接開始非常頻繁地出現(xiàn)。我已運行此查詢以嘗試查看此問題中的建議：Azure SQL server max pool size was connected 錯誤select * from sys.dm_exeC_requests但我不確定在這里我應(yīng)該注意什么。我做過/確定過的事情。正如建議的那樣，database/sql應(yīng)該處理連接池，因此為數(shù)據(jù)庫連接設(shè)置一個全局變量應(yīng)該沒問題。確保sql.Rows和db.Prepare聲明在任何地方都是關(guān)閉的。將 Azure SQL 級別提高到 S3。我正在使用的 sql 驅(qū)動程序存在問題，如果它們空閑超過 2 分鐘，則 Azure SQL 使數(shù)據(jù)庫連接處于錯誤狀態(tài)。 https://github.com/denisenkom/go-mssqldb/issues/81database/sql處理連接池的方式是否與 Azure SQL 數(shù)據(jù)庫的管理方式不兼容。有沒有辦法優(yōu)雅地處理這個問題？我知道 C#/Entity Framework 有一個針對 Azure SQL 的連接彈性/重試邏輯，是不是出于類似的原因？我如何實現(xiàn)這一點而不必在我的錯誤處理中到處傳遞？我的意思是我不想清楚地做這樣的事情：if err == sql.ErrBadConn {  // close and re-open the global db object  // retry}這當(dāng)然不是我唯一的選擇嗎？任何幫助將非常受歡迎。謝謝