go beego框架問題怎么解決

這篇文章主要介紹了go beego框架問題怎么解決的相關(guān)知識，內(nèi)容詳細易懂，操作簡單快捷，具有一定借鑒價值，相信大家閱讀完這篇go beego框架問題怎么解決文章都會有所收獲，下面我們一起來看看吧。

最近在項目中遇到了一個很奇怪的問題：在整改日志規(guī)范時，為了避免影響現(xiàn)有的代碼結(jié)構(gòu)以及改動盡可能小的前提下，在調(diào)用記日志的SDK處將某一個字段值首字母改為大寫，代碼示例如下：

fmt.Println("--------SayHello begin------------")
  //項目中這里的a實際是作為參數(shù)傳入,只是可能為空串,不為空串,這樣寫肯定沒問題
  a := ""
  b := strings.ToUpper(a[:1]) + a[1:]
  fmt.Println("b is ", b)
  fmt.Println("--------SayHello end------------")

  this.Ctx.Output.Body(this.Ctx.Input.RequestBody)

項目中這里的a變量其實是作為參數(shù)傳入，只是可能為空串。a變量不為空串時，這樣寫肯定沒問題。但是當(dāng)為空串時，即""時，就會出問題，在java中，運行的時候肯定會報一個“數(shù)組下表越界”的異常。小強將工程編譯后生成二進制文件，放到服務(wù)器上跑，測試修改后的日志是否符合規(guī)范，驗了一遍，沒有問題，然后就將代碼提交了。

之后版本出來測試時發(fā)現(xiàn)，有個奇怪的現(xiàn)象：接口不返回任何東西，狀態(tài)碼依然是 200 OK。這讓小強很納悶兒，還好，我們的小強經(jīng)驗豐富，還是解決過大bug的人，然后就根據(jù)接口走了一遍代碼流程，眉頭一皺，就知道問題所在了。原來就是a變量有時候傳進來是空字符串，導(dǎo)致出現(xiàn)了slice下標越界的panic，說干就干，小強趕緊做了空串的判斷邏輯，重新驗了一把，問題就解決了。

原來問題是這樣，項目中使用的beego版本是1.6.1版。

查到了beego的錯誤處理流程：beego通過beego.App.Server.Handler處理所有的HTTP請求，在beego.Run()函數(shù)中，這個Handler就被設(shè)置為app.Handlers，可以參見beego1.6.1版本app.go的第95行：

app.Server.Handler = app.Handlers

而app在一開始就被初始化，可以看app.go中的init()函數(shù)，其中調(diào)用了NewApp()函數(shù)：

// NewApp returns a new beego application.
func NewApp() *App {
  cr := NewControllerRegister()
  app := &App{Handlers: cr, Server: &http.Server{}}
  return app
}

可以看出，把cr賦值給Handler，其實cr是ControllerRegister類型，ControllerRegister類型實現(xiàn)了http.Handler接口，具體實現(xiàn)可以看router.go的第600行ServeHTTP方法。該方法中（第612行）有如下語句：

defer p.recoverPanic(context)

出現(xiàn)異常會執(zhí)行recoverPanic方法，該方法中（第864行）有這樣的代碼段：

if BConfig.RunMode == DEV {
        showErr(err, context, stack)
}

showErr函數(shù)中會對錯誤進行模板渲染，而項目早在現(xiàn)網(wǎng)中投入使用，RunMode為prod，而非dev，所以recover()后不會有錯誤提示。

當(dāng)RunMode為prod時：

當(dāng)RunMode為prod時：

dev模式好歹會返回錯誤信息：slice bounds out of range

prod模式?jīng)]有任何提示。下標越界這種問題看似簡單，但是真正遇到了有時候也會摸不著頭腦。

關(guān)于“go beego框架問題怎么解決”這篇文章的內(nèi)容就介紹到這里，感謝各位的閱讀！相信大家對“go beego框架問題怎么解決”知識都有一定的了解，大家如果還想學(xué)習(xí)更多知識，歡迎關(guān)注億速云行業(yè)資訊頻道。