指针有很多好处，可以想象没有它们的编码，让我们说这并不令人愉快。但是他们确实有缺点，其中之一（至少对我来说）可能是他们可能引起混乱，甚至可能谨慎使用代码。我认为，当事情不按预期工作时，我们都会经历过，并且在调试会议之后发现指针导致了意外的行为。但是毕竟，决定是否通过（或一般使用）指针对我来说并不容易。因此，我决定向人们学习和学习比我更聪明，经验丰富的人。希望分享这些发现可能也会对您很有趣。

本文在其宝贵的文章中受到**Hossein Nazari *的重大启发，标题为“是否在通过Gocast上发表的structs'时使用指针）。*

原始作者所做的主要推论之一是：

将默认设置设置为不使用指针，除非您知道它的字段将要更改。

通过价值与参考

• Go按价值通过所有内容。甚至指针将其传递到函数时也会被复制，但副本仍然代表相同的基础内存，因此我们能够更改基础值。

首先，让我们看看一些围绕指针的细节。一个有趣的article强调了Go 是 by-value，但在某些时候听起来不像情况。有原始类型，例如int，string，字节，符文，布尔被认为是值类型，而指针类型为参考。但是，某些类型的性质有些不同，如文章所说：

但是，映射，切片和频道都是 *或 *包含 *参考的特殊类型。

但是，这些类型的有趣之处在于，它们都指向其他一些基本数据，即使您通过任意函数中的值（看似）通过它们来传递它们，也会更改其在功能中的内容也会改变其原始值。举个例子：

    package main

    import "fmt"

    func changeKey(m map[string]string) {
        m["key"] = "new_value"
    }

    func main() {
        m := map[string]string{"key": "value"}
        fmt.Println(m) // map[key: value]
        changeKey(m)
        fmt.Println(m) // map[key: new_value]
    }

因此，这些地图似乎是参考文献，尽管实际上它们不是。看看这个示例：

    package main 

    import "fmt"

    func new(m map[string]string) {
        m = make(map[string]string)
    }

    func main() {
        var m map[string]string
        new(m)
        fmt.Println(m == nil) // true
    }

如果MAP M是C ++样式参考变量，则M为MAIN声明，而在Neww中声明的M将在内存中占据相同的存储位置。但是，由于newhas内部对M内部的分配对M中M值没有影响，因此我们可以看到地图不是参考变量。

地图参考是记忆中包含各种字段的内存中映射标头结构（类型HMAP）的指针，包括单元格和其他一些内容。

复制地图或将其传递为值并不是复制下面的hashmap - 它仅将指针复制到标头结构。因此，复制地图参考只是为您提供对内存中同一基础地图的多次参考。是映射参考是逐价传递的，而不是地图的内容

最终结果也被描述为here：

首先，从技术上讲，GO只能通过逐个价值。将指针传递给对象时，您会按值传递指针，而不是通过引用传递对象。区别是微妙的，但偶尔有意义。例如，您可以覆盖对呼叫者没有影响的指针值，而不是将其覆盖并覆盖其指向的内存。

表现

使用指针的主要问题之一是性能。看来，使用指针作为提高代码的整体性能和记忆效率的一种方式并不总是正确的。

Mario Macías备份了适当的基准测试，提出了一个有趣的观点，即返回结构与指针：

尽管复制了一个字段的结构比将指针复制到同一结构较慢，但如果我们考虑 Escape Analysis 特殊性，返回结构值可能比返回指针更快。

返回的结构允许编译器检测到创建的数据不能逃脱函数范围并决定在堆栈中分配内存，在该堆栈中，分配和交易点非常便宜，如果与Heap中的内存进行管理。

。

此外，这个article还指出，为了证明分享指针指向结构的合理性，它应该特别大（您可能会问多大？我不确定，也许几百个字节？）及其生命周期应该很大。还有另一个benchmark表明您很少需要通过其指针共享结构。

事实证明，与指针相比，只有极大的结构才能引起性能较慢。
如果我选择使用指针，则变量本身应在整个持续时间内保持有价值的目的。

由于堆的堆积，垃圾收集器会不时地形成短暂的暂停（平均几毫秒）来清理。由于我们谈论的是堆栈和堆，因此值得注意的是，访问堆栈的速度特别快，如描述here：

堆栈更快，因为访问模式使从中分配和划分内存变得琐碎（指针/整数简单地增加或减少），而堆的分配或交易分配或交易的簿记更为复杂。同样，堆栈中的每个字节往往很频繁地重复使用，这意味着它倾向于将其映射到处理器的缓存，从而使其非常快。堆的另一个性能是，堆主要是全球资源，通常必须是多线程安全的，即每个分配和交易都必须与其他所有其他分配和交易。堆在程序中访问。

那么，这与我们如何？好吧，事实证明，我们使用函数的返回值或输入参数（即决定是否使用指针）可能会导致分配。 James Kirk在article中彻底而精美地描述了这个过程：

我们可以从中推断出的一般规则是，共享堆栈的指针会导致分配，而在堆栈下共享点并不是。

我们将在以下部分中看到有关堆栈和堆的更多信息。

至少对我来说，我多次看到的主要事情之一是，如果一个团队希望发展并改善他们的许多服务，项目和整体代码的加时性，那么这对优先考虑代码的可读性。写一些惯用性并且可以很容易地推论的东西似乎是一种更成功的方法，而不是试图以代码为代价而实现最微小的优化，这是不可读的混乱。在Golang中，通常编写惯用和可读的代码似乎非常重要和价值。威廉·肯尼迪（William Kennedy）描述了这一指数和可能的性能权衡的想法：

我被问到何时以及何时不使用指针的情况。大多数人遇到的问题是，他们试图根据自己认为的绩效权衡做出这一决定。因此，问题是，您可能会根据您对绩效的毫无根据的想法做出编码决策。根据代码惯用，简单，可读和合理的代码做出编码决策。

后来补充说，通常，如果我们将实施分组为原始数据值或要更改的原始数据值，那么与指针共享更改的数据是明智的：

如果您从标准库中查看更多代码，您将看到结构类型是如何作为原始数据值（例如内置类型）实现的，或者将其实现为需要与指针共享而从未复制的值。给定结构类型的工厂功能将为您提供有关如何实现类型的很好的线索。
通常，除非实现了像原始数据值的行为一样，除非实现结构类型，否则共享结构类型值。

。

以及：

如果您仍然不确定，这是另一种思考方式。将每个结构都视为具有性质的。如果结构的性质不应更改，例如时间，颜色或坐标，则将结构作为原始数据值实现。如果结构的性质可以更改，即使它不在您的程序中，它也不是原始的数据值，应实现以与指针共享。不创建具有自然双重性的结构。

顺便说一句，我不确定我是否能完全理解最后一句话。自然的双重性对我来说似乎不是一个明确的事情。老实说，到目前为止，我看到的大多数结构都具有不断变化的性质，而这些结构也具有自己的一致和不变的内在状态。为了为您提供一个例子，请考虑一个结构从起源到目的地的途中解释车辆（如果这个示例证明是半烘烤而不是真的，我很抱歉，这只是一个例子）：

    package main

    type Point struct {
        Lat float64
        Long float64
    }

    type Vehicle struct {
        id string
        Origin Point
        Destination Point
        GasolineLeft float64
    }

我并不是说他错了，一点都不说，我所说的是，这种自然的双重性是可以在这里和那里观察到的，这很好（您可以争辩说，上面的设计可以以一种可能与ID或其他物体一起存储在某个地方的方式更改，但是您明白了）。我自己对这篇文章的看法是为将要稍微改变的结构使用指针。

和参考类型（例如，地图，切片，木，接口和函数值）仅在极少数情况下与指针共享，如果您不确定，只需使用指针即可。

参考类型是切片，地图，通道，接口和功能值。这些值包含一个标头值，该值通过指针和其他元数据引用基础数据结构。我们很少与指针共享参考类型值，因为标题值设计为复制。标题值已经包含一个指针，该指针默认情况下为我们共享基础数据结构。
如果您从标准库中查看更多代码，您将看到在大多数情况下未与指针共享参考类型中的值。由于参考类型包含一个标题值，其目的是共享基本数据结构，因此不需要与指针共享这些值。已经有一个指针。
通常，除非您实现非符号类型的功能，否则不要与指针共享参考类型值。

堆栈与堆

我们发现，总体上分享堆栈的指针会导致内存分配。让我们深入研究。

本节的灵感来自Jacob Walker，在他们的视频中。

有两种记忆， stack 和 heap ，并且使用GO，我们有多个堆栈（即每个Goroutine的堆栈），以及一个基本上的堆容纳其他不在堆栈中的所有内容。

    package main

    func main() {
        n := 4
        n2 := square(n)
        println(n2)
    }

    func square(x int) int {
      return x * x
    }

    package main

    func main() {
        n := 4
        inc(&n)
        println(n)
    }

    func inc(x *int) {
        *x++
    }

    package main

    func main() {
        n := answer()
        println(*n/2)
    }

    func answer() *int {
        x := 42
        return &x
    }

    go help build
          usage: go build [-o output] [build flags] [packages]
          ...
          -gcflags '[pattern=]arg list'
                 arguments to pass on each go tool compile invocation.

    go tool compile -h
            usage: compile [options] file.go...
            ...
            -l disable inlining
            ...
            -m print optimization decisions


    # Example 1
    go build -gcflags "-m -l" example1.go
    # no output, since inlining is disabled

    # Example 2
    go build -gcflags "-m -l" example2.go
    ./example2.go:9:10: x does not escape

    # Example 3
    go build -gcflags "-m -l" example3.go
    ./example3.go:9:2: moved to heap: x

    # Example 1
    go build -gcflags "-m -l" example1.go
    ./example1.go:8:13: ... argument does not escape
    ./example1.go:8:14: n2 escapes to heap

    # Example 2
    go build -gcflags "-m -l" example2.go
    ./example2.go:11:10: x does not escape
    ./example2.go:8:13: ... argument does not escape
    ./example2.go:8:14: n escapes to heap

    # Example 3
    go build -gcflags "-m -l" example3.go
    ./example3.go:11:2: moved to heap: x
    ./example3.go:7:13: ... argument does not escape
    ./example3.go:7:17: *n / 2 escapes to heap