Go で非ポインタの「interface{}」パラメータを指定した「json.Unmarshal」が予期しない結果を引き起こすのはなぜですか?

インターフェース{} タイプの誤解: 複雑さを明らかにする

Go では、インターフェース{} タイプは柔軟性と複雑さの両方を提供します。ただし、不可解な例で示すように、その性質を誤解すると、予期しない結果が生じる可能性があります。

非ポインタ型をインターフェース パラメータとして関数に渡し、それに json.Unmarshal を使用しようとすると、結果は驚くべきものになる可能性があります。以下の例は、この動作を示しています。

package main

import (
    "encoding/json"
    "fmt"
)

func test(i interface{}) {
    j := []byte(`{ "foo": "bar" }`)
    fmt.Printf("%T\n", i)
    fmt.Printf("%T\n", &i)
    json.Unmarshal(j, &i)
    fmt.Printf("%T\n", i)
}

type Test struct {
    Foo string
}

func main() {
    test(Test{})
}

出力:

main.Test
*interface {}
map[string]interface {}

謎の解明

混乱はインターフェイスの性質に起因します{}。これは単なる型のないコンテナではなく、(値、型) ペアのラッパーです。インターフェイスは具体的な値とその型への参照を保存します。

json.Unmarshal は入力としてインターフェイスの値を受け取るため、i を直接渡すことができます。{} (&i と同様に) そのアドレスを取得しようとすることは不要です。

ポインターとインターフェイス

ただし、i にポインター以外の値が含まれている場合、json.Unmarshal はチャレンジ。パッケージは非ポインタにアンマーシャリングできないため、interface{} 型の新しい値を作成します。これにより、タイプを選択できます。デフォルトは、map[string]interface{} です。

正しいシナリオ

ポインタ シナリオの場合、引数として &i を渡します。 json.Unmarshal がポインタを逆参照して *Test 値を含むインターフェース値を見つけるため、機能します。{}ポインターにより、アンマーシャリングが正しい型に行われることが保証されます。

結論

これらの混乱を避けるために、インターフェイスへのポインターの使用は控えてください。代わりに、インターフェイス内にポインタを「配置」し、それらを直接渡します。インターフェースとポインタの間の相互作用を理解することで、開発者は予期しない結果を回避し、Go の型システムを効果的に活用できます。

以上がGo で非ポインタの「interface{}」パラメータを指定した「json.Unmarshal」が予期しない結果を引き起こすのはなぜですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。