为何在golang中，切片和映射之间的行为表现不一致？

在 Go 语言中，切片和映射在行为上表现不一致。切片元素可寻址，而映射元素不可寻址。这是因为切片可以表示为数组的地址，而映射使用哈希算法存储键值对，其地址随着键值对的改变而改变。因此，支持映射元素的可寻址性会增加二进制大小并导致哈希算法频繁变化，从而影响性能。

type s struct {
    e int
}

func main() {
    a := []s{{1}}
    a[0].e = 2

    b := map[int]s{0: {1}}
    b[0].e = 2 // error
}

a[0] 可寻址，但 b[0] 不可寻址。

我知道第一个 0 是一个索引，第二个 0 是一个键。

为什么golang要这样实现？还有进一步考虑吗？

我已经在 github.com/golang/go/src/runtime 中阅读了 map 的源代码，如果 maxkeysize 和 maxvaluesize 足够小，则映射结构已经支持 indirectkey 和 indirectvalue 。

type maptype struct {
    ...
    keysize       uint8  // size of key slot
    indirectkey   bool   // store ptr to key instead of key itself
    valuesize     uint8  // size of value slot
    indirectvalue bool   // store ptr to value instead of value itself
    ...
}

我认为如果 golang 设计者想要这种语法，现在就很容易了。

当然indirectkey indirectvalue可能会花费更多的资源，gc也需要做更多的工作。

那么性能是支持这一点的唯一原因吗？

或者还有其他考虑吗？

在我看来，支持这样的语法很有价值。

解决方案

据我所知，

这是因为a[0]可以替换为数组的地址。

同样，a[1] 可以替换为 a[0]+(keySize*1)。

但是，如果映射不能这样做，哈希算法会根据您的键、值对及其数量而随时更改。

它们也会不时地重新排列。

需要进行具体的计算才能得到value的地址。

数组或切片很容易寻址，但对于映射来说，就像多个函数调用或结构查找......

如果你想用任何需要计算的东西来代替它，那么二进制大小将会增加几个数量级，而且哈希算法可能会不时发生变化。

好了，本文到此结束，带大家了解了《为何在golang中，切片和映射之间的行为表现不一致？》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多Golang知识！