為什麼從映射列印指向結構的 Go 指標有時會顯示位址而不是結構的值？

理解 Go 指針的細微差別

在 Go 中，掌握指針的微妙之處對於有效編程至關重要。本文深入研究了一個特定場景，其中儲存在映射中並作為指標列印的值會產生意外結果。

問題：揭開謎團

Go 程式使用保存鍵值對的對應（模型），其中一個包含指定用於GORM First() 函數的結構值（測試）。當嘗試從映射中檢索結構並將其列印為指標時，會出現令人費解的行為。雖然 GORM 函數需要一個結構體，但列印操作產生的輸出看起來只是一個位址。

解決方案：揭開謎底

關鍵在於深入研究 fmt 套件預設格式的複雜性。當列印值而不指定格式時，fmt.Printf() 使用基於值類型的預設規則。在最初的範例中，test1 的類型為 Test，並作為指向列印函數的指標傳遞。根據預設格式，指向結構體的指標表示為 &{field0 field1 ...}，解釋了當欄位 Test 初始化為「a」時 &{a} 的出現。

但是，第二個例子涉及微妙的差異。由於映射的類型宣告 (map[string]interface{})，從 Models 映射檢索到的值 (test2) 的類型為 interface{}。當嘗試列印指向 test2 的指標時，該值本質上被包裝在一個附加的 interface{} 值中，從而產生 *interface{} 類型。 *interface{} 值的預設格式規定列印位址，因此觀察到的十六進位位址值輸出。

解決困境：更優雅的方法

有效從 test2 中提取所需的結構，可以使用類型斷言。這涉及將 interface{} 值明確轉換為預期類型，在本例中為 Test。透過這樣做，test2 值在類型上與 test1 相同，從而在列印時產生一致的輸出。

或者，更最佳化的解決方案是將指向 Test 值的指標直接儲存在模型映射中，從而無需類型斷言或中間變數賦值。這確保了映射中的 interface{} 值本質上是指向 Test 的指針，可以直接使用或傳輸。

理解 Go 中指標的行為和預設格式對於了解 Go 開發的細微差別至關重要環境。透過掌握這些概念，程式設計師可以編寫優雅且高效的程式碼，充分利用 Go 功能的潛力。

以上是為什麼從映射列印指向結構的 Go 指標有時會顯示位址而不是結構的值？的詳細內容。更多資訊請關注PHP中文網其他相關文章！